Re: High volume mail handling architecture
On Fri, Sep 10, 2004 at 09:49:27AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote:
> Herre is what happens: A spammer uses my email address as the sender address
> in spam frequently.
> So, I sometimes suddenly have 2000 new mails in my inbox :-(
> So, that's my plea to everybody with big mail installations: make your
> frontend machines aware of what mail they are supposed to accept, so that
> you never need to bounce. (Ok, some cases will still bounce: disk full,
> procmail script errors etc., but these are a very small proportion.) And
> the other plea is, of course, get rid of qmail and other products which
> accept all mail by default.
As far as my experience goes, pleas or complaints against other people
doesn't help much if you want to see something changed. Better help
yourself.
I suggest to instruct your mail user agent to make use of the
(apparently almost forgotten) fact that the sender's addresses in the
envelope and in the header can be different. Most today's mail transfer
agents should support address extensions.
If your address is used as envelope sender in unsolicited mail, it's
your public one. Use a non-public address as envelope sender of mail
you send, and simply change it in case it gets abused; only bouncers
should send mail to this address, and they usually do within two weeks.
Now you can configure your MTA to outright reject delivery notifications
solely based on the information in the envelope.
$ mconnect a.mx.smarden.org
220 smarden.org ESMTP
mail from:<>
250 Sender accepted.
rcpt to:<pape@smarden.org>
553 This address cannot get bounces, either you are not bouncing to the envelope sender, or the envelope of the mail you bounce is forged.
quit
221 Good bye.
$
I'm doing this for about ten months now, and don't see most of the
unwanted delivery notifications, including delivery confirmation
requests for unsolicited mail with forged envelope.
Regards, Gerrit.
--
Open projects at http://smarden.org/pape/.
Reply to: