Hello backscatterers (:-), [email protected] (Jason Barbier), 2014.03.03 (Mon) 18:47 (CET): > So reading this also this type of spam bounce has a common name, its called > backscattering (https://en.wikipedia.org/wiki/Backscatter_%28email%29).
as I read this (thanks for the link) there is no real solution to the problem. Under "Reducing the problem" it says: Checking bounce recipients Mail servers sending email bounce messages can use a range of measures to judge whether a return address has been forged. Which "range of measures" is this referring to?! What I want to stress is that this discussion is about working around a problem some mail providers pose. Where is this going to end? I have a nationwide mail provider here in austria that throttles inbound mail after some number of messages. Could we work around this as well, please? BTW, the proposed workaround of bouncing without content is not suggested in the above link. Bye, Marcus > There is actually a blacklist for this and quite a few companies use it, as > well as greylisting software will check for it. We for sure want to make > sure that we are able to turn off backscatter and have it off by default. > Honestly users should beable to turn this on and off based on the direction > of the mail. internally it is useful to have it spit back the message, > headers, and the raw error that the MTA returned. Externally we should just > spit back at most headers but honestly what is internal and external needs > to be set by the user since there is no good way to determine this on its > own and the MTA honestly should handle this all as part of doing the bounce. > It makes no sense to make a filter or have a second function handle it since > we already have a function to handle bounces. > > > On 03/03/14 09:16, Jason A. Donenfeld wrote: > >Hi folks, > > > >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. > > > >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. > > > >Thus, I propose a configuration flag for not adding bodies to bounce > >messages. > > > >Thanks > >Jason > > > > > -- > You received this mail because you are subscribed to [email protected] > To unsubscribe, send a mail to: [email protected] > > > !DSPAM:5314c03b8723225549481! > -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
