[Mailman-Developers] before next release: disable backscatter in default installation

[Ian Eiloart]

--On 31 March 2008 09:26:08 -0700 Mark Sapiro <mark at msapiro.net> wrote:

> Ian Eiloart wrote:
>> [snip]
>
> Here's the problem. I receive a message for board at example.net which is
> aliased to a few other addresses including user at 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 at 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