Re: [exim] Alterating / Intercepting bounce messages

Marc Perkel wrote:

| When I pass the message on to the target server - if the message bounces
| there - sy due to an invalid address - then the bounce is returned

...to an innocent person unlucky enough to have their details forged.


| What I'm considering
| is altering the return path so the bounce comes back to my server - I do
| something with it - and then I restor the original return address and
| send it on.
|
| This allows me to inspect what fails to deliver for statistical reasons
| looking for new spam fighting tricks.

You'd be better spending your time teaching the MX to reject invalid
addresses in the first place. And, convincing others to do the same would
be an excellent spam fighting trick.


And John W. Baxter wrote:

| Look into SRS (which is what was supposed to fix the forwarding problem for
| SPF). You encode the original return path into a verifiable return path you
| generate...when the bounce comes you verify that the purported target
| address of the bounce came from your server and if so extract the original
| return path part.

I think you've lost me there. Once the MX has accepted a mail to an
unknown user, then it's too late to do anything useful and the old dilemma
applies. Silently drop the mail (breaking reliability) ? Or spam the
forged sender with a bounce ? The former (drop) is more acceptable as it
only impacts oneself and one's own correspondents, not the whole of the
net.

There is no way to solve this with SRS or any other rewritting.

Of course, the solution is to teach the MX which addresses are valid. As
has been stated, recipient callout is often an easy way to do this. Other
solutions include live lookups (e.g LDAP) or some sort of import of a
user table (rsync, ftp etc). This may seem like hard work. But in this
day+age it's work that needs to be done.

There are plenty of MX operators who are not averse to hard work
themselves, but seem to be too "polite" to ask their downstream mailer
operators/customers to do whatever is required from their end. Many of
those large outsourced "mail scanning" companies fall into this category.
Their traditional business model revolves around customers having to do
nothing other than change MX records. Sadly this is no longer valid.
Customers will need to do the (modest) work required to supply the user
table. I'm sorry to bring the bad news (hardly news). We have the
spammers to thank for that.


--
Chris Edwards, Glasgow University Computing Service