
--On 31 March 2008 09:26:08 -0700 Mark Sapiro <mark@msapiro.net> wrote:
Ian Eiloart wrote:
[snip]
Here's the problem. I receive a message for board@example.net which is aliased to a few other addresses including user@example.com. The MTA (Postfix in my case) accepts the message to board and resends it to the aliased recipients. example.com has a very agressive content filter which rejects messages after receiving the DATA. so Postfix's delivery to user@example.com is sometimes not accepted by example.com so Postfix returns a DSN. Sometimes the sender was legitimate, sometimes (probably more often) not.
So what do I do practically in this case. Calling out to verify the recipient won't help because the recipient is valid.
So, these are mail aliases that aren't managed by Mailman? Well, you could turn them into Mailman lists - albeit lists of one. Mailman would alter the return-path, and the rejection message would go to a list manager - perhaps the domain owner - instead of an innocent third party.
Also, you could perhaps arrange that Postfix only bounces into domains that publish SPF records, and only when you get an positive SPF response. Actually, I'm veering towards the notion that we should be creating a climate where the only sensible way to avoid collateral spam is to publish SPF records.
I can arrange for the DSN to pass through MailScanner on the way out and possibly create rules to conditionally drop it, but what should the rules be, and is it really a problem at all? Note for example, that yesterday I did not accept 29985 messages for unknown users and greylisted 5684 more and sent no DSNs. This is somewhat typical except I probably average 2 or 3 DSNs per day.
Should I be worried?
That depends on the nature of your customers. But, you should also be concerned about the possibility of one day being flooded by DNS generating mail. At the current rate, it's a small problem [but a part of a larger problem], but what you have might be regarded as a vulnerability.
-- Ian Eiloart IT Services, University of Sussex x3148