On Thu, Mar 24, 2005 at 05:47:30PM -0800, Fred Viles wrote:
> | I mean. Errors give collateral spam too, even when they are generated
> | at smtp time.
>
> Only if the offending message was offered by a relay MTA, then it
> will generate a DSN that could be collateral spam. But that would be
> its fault for accepting the message for relay in the first place, not
> your's for rejecting an unwanted message.
But there is very little in current Internet practice which would allow it
to do otherwise. It could do a callback to verify that the return address
exists, but that doesn't help associate it with the submitter of the
message.
ISPs would have to:
1. Require their customers to use SMTP AUTH when going through smarthosts;
2. Maintain a database which ties each authenticated ID to a list of
allowed return addresses for that customer; taking into account the
various permutations of VERP/SRS/SES/BATV they may be using.
The cost (of adding database access to the smarthosts, of migrating the
existing customer base, and of ongoing maintenance of the database) is high;
and the benefit does not accrue to the ISP but to other people on the
Internet. So of course no-one does it.
There is one potential benefit that could accrue to the ISP though. At the
moment, if an 0wned machine manages to locate the ISP's smarthost and spews
spam through it, the smarthost output consists of mixed good messages and
spam. The smarthost is likely to be blacklisted by IP address, and
collateral damage is done to the ISP's other customers.
However, if the ISP's customers were using SMTP AUTH, and the recipient
supported the AUTH extension, then messages could be tagged with that
information:
MAIL FROM:<president@???> AUTH=ispam@???
Clearly this is useless if the SMTP sender belongs to a spammer, since they
can put whatever they like in the AUTH parameter, and so you'd still have to
blacklist the machine by IP address only.
However, it would allow recipient blacklists to be set up on a combination
of IP address and authenticated sender, for those cases where:
- it's an ISP smarthost, which has not been compromised
- the ISP does not allow an unlimited signup for fresh SMTP AUTH accounts
In fact, it doesn't need the AUTH extension; the information could be stuck
in Sender: or another header. But then you'd need to accept the DATA portion
of the message to check it.
However, as far as I know, there is no existing blacklist mechanism which
can look up a tuple of <IP address, AUTH ID>. So until such a thing exists,
there is little incentive to make clients AUTHenticate themselves when
sending mail.
Regards,
Brian.
