Re: High volume mail handling architecture
On Fri, Oct 08, 2004 at 10:07:15AM +0100, John Hedges wrote:
> On Fri, Sep 10, 2004 at 05:34:07PM +0000, Gerrit Pape wrote:
> > 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, 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.
> Sorry to reopen such an old thread. I'd saved this mail for reference as
> I too get a lot of bounces for spam with forged mail headers. A fresh
> run of spam that some wanker has initiated in my name has made my inbox
> unbearable this last few days so I need to do something about it.
It's not because of forged headers but forged envelopes, your address is
used as envelope sender in SMTP (MAIL FROM:<john@example.org>). It's
the envelope sender address where delivery notifications, such as
bounces, are sent; and those delivery notifications usually have an
empty envelope sender (MAIL FROM:<>). Replies and followups are sent to
an address specified in the headers of the mail (From: John
<john@example.org>, or Reply-To:), and have a non-empty envelope sender.
If john starts to send all his mails with the envelope sender address
<john-notice@example.org> and still uses the same headers, communication
with the recipients will not change, but delivery notification will go
to <john-notice@example.org>. His public, well known, unchangeable mail
address <john@example.org> now no longer receives delivery notification
for mail john himself has sent; he now can safely reject or disregard
mails sent with an empty envelope sender to the envelope recipient
<john@example.org>, solely based on the envelope information, without
looking at the headers or the body of the mail.
> Would it be possible for you, Gerrit, to expand a little on your setup?
My personal setup is done with the qconfirm package, specifically, I
send mails through the qconfirm-inject program which adjusts the
envelope sender, and so requests bounces to go to a different address
than my public one. This is qmail specific, and you need shell access
to the mail server.
> I currently use fetchmail to get my mail from a catchall mailbox at my
> ISP. Can I use the envelope sender trick in this case as I can't see an
> easy way to differentiate between bounces and normal email once the
> messages reach my box?
Most of the bounces are sent with an empty envelope sender (<>), I'm not
sure whether fetchmail preserves the envelope information, it might get
lost; look for Return-Path:. Although it might work with your setup,
sorting out the bounces better should be done on the mail exchanger I
think.
Regards, Gerrit.
--
Open projects at http://smarden.org/pape/.
Reply to: