background: I maintain my mailing lists "by hand", which is to say that I read
subscription requests personally and use shell scripts to add/delete people
from lists. part of what the "add2list" script does is run a verification
program to make sure the subscriber address is valid - that program parses
the address, looks up the MX records, and tries to verify the recipient via
SMTP using HELO/MAIL/RCPT/RSET/QUIT.
increasingly I'm seeing something like the following:
MAIL FROM:<>
572 Bounces are blocked due to system abuse by spammers
MAIL FROM:<MAILER-DAEMON(_at_)cs(_dot_)utk(_dot_)edu>
250 Sender OK
(several years ago, I modified the verification program to try MAILER-DAEMON
if <> wasn't accepted. but only recently has this practice become widespread)
to me this seems completely shortsighted brain damaged.
first of all, it doesn't do anything to deter spam, it only keeps the
site that the spammer puts in the return address from realizing that the
spammer has used the site in that way.
second, it prevents legitimate error messages from being returned to senders.
third, it encourages mailers to send bounces with some other return address
than <>, and thus encourages bounce loops.
is there anything that can be done to discourage this practice, or provide
better countermeasures?
for instance,
- could a mailer count the number of bounces sent to each
address, and reject bounces over so many per period of time (day? hour?)?
e.g.
MAIL FROM:<>
<<< 250 OK
RCPT TO:<joe(_at_)example(_dot_)com>
<<< 4xx Too many bounces sent to this address, try again later
- one complaint seems to be that the volume of bounces gets so large that it
overwhelms the mail system. (shouldn't the mail system throttle its input?)
perhaps mailers could perform RED on bounces?
MAIL FROM:<>
<<< 4xx-we've processed too many bounces in the last hour, and this threatens to
<<< 4xx-block other kinds of messages. so for now we're only accepting a small
<<< 4xx percentage of the bounces we receive. please try again later.
- seems like per-recipient quotas, if enforced at SMTP time, would also help.
Keith