On Mon, Mar 3, 2014 at 8:17 PM, Gilles Chehade <[email protected]> wrote: > 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.
You don't need a redirect to make the MTA generate a bounce message. There are lots of ways to send a message to opensmtpd and make it bounce. Connect via StartTLS, send the bouncable spam, then receive the bounce on plain text 25, and moronic OVH filters will blacklist the IP. > That being said, I agree this is a real issue and we will have to find > a proper fix for it. Cool. > makes sense, what do you suggest ? > where would the knob be introduced, with what semantic ? OpenSMTPD will generate bounces in lots of contexts. It doesn't make sense, for example, to add the flag to "accept", since if you accept mail for @poolp.org, but ploop.org also points to the same IP, and someone sends a message to [email protected], opensmtpd will generate a bounce. This bounce doesn't exist in the context of that 'accept' line, so it wouldn't really make sense to have the control there. OTOH, all messages necessarily go through a "listen" line, and exist in that context, so I think a flag would make more sense there. listen on lo ... [absence of no-bounce-bodies] listen on eth0 ... no-bounce-bodies or, to be 'safe' by default (which is arguably better): listen on lo ... bounce-bodies listen on eth ... [absence of bounce-bodies] Put this way, it would mean that when a local user queues up a message and sends it, and that message bounces, that local user receives the full body in his bounce. And contrarily, when an external host connects to send a message that bounces, the body is not sent, to prevent against this backscatter problem. Or, maybe that's much too complex, and breaks with the pattern introduced by "bounce-warn", which is a global config option. This would probably be much easier to grok. This would look like: listen on eth0... listen on lo... accept for ... bounce-warn 3m bounce-parts headers body or bounce-parts headers or bounce-parts body Even better, the two bounce options could be unified into one line with simpler grammer: bounce warn-wait 3d with-body with-headers Or something similar. -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
