On Mon, Mar 03, 2014 at 06:16:03PM +0100, Jason A. Donenfeld wrote:
> Hi folks,
> 

Hi,

> Spammers have an easy trick against OpenSMTPD: they send a message
> that bounces for some reason (say, it's forwarded to another MTA that
> rejects it on on the basis of it being spam), and the bounce message
> then contains the original spam message. Egress spam filters on
> various hosting networks -- such as OVH -- then will spot that bounce
> message as spam, and block the IP on the basis of it being the
> spammer.
> 

I understand the issue but the way you're presenting it makes it look
like everyone is affected and can be abused by spammers, I'd like to
clarify that this "easy trick" requires you to have a specific setup
that involves both redirect and a brain dead host like OVH that will
blindly blacklist your IP with badly written filters.

In other words, despite my very common and simple setup that involves
no spam filter and nothing more than opensmtpd itself, you can't use
this "easy trick" against me.

That being said, I agree this is a real issue and we will have to find
a proper fix for it.


> The solution is obvious, and other MTAs have incorporated this: for
> networks with egress filters like this, opensmtpd should have a
> configuration option to only send headers, not bodies, in bounce
> messages. This has the additional benefit too of lowering bandwidth
> usage.
>
> For the same reason that mask-source was added as a config flag, not
> sending bodies in bounce messages should also be added as a config
> flag: opensmtpd generates this data in a very unstructured way (random
> text in a message body that's then queued like other messages), and
> then ships it off. It would be wasteful implement this as a filter
> using the filter api, which would parse an unstructured format, and
> remove bits of data based on a buggy heuristic, when opensmtpd is the
> one adding it in the first place. The obvious solution is to simply
> add a flag so that this information doesn't get added in the first
> place.
>

makes sense, what do you suggest ?
where would the knob be introduced, with what semantic ?


> Thus, I propose a configuration flag for not adding bodies to bounce messages.
> 


-- 
Gilles Chehade

https://www.poolp.org                                          @poolpOrg

-- 
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]

Reply via email to