Re: [Exim] forged HELO/EHLO addresses

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Chris Edwards
Data:  
Para: Exim users list
Assunto: Re: [Exim] forged HELO/EHLO addresses
| Btw., observant readers will have noticed that our recipe doesn't
| accept the "[ipaddress]" notation, even though it's technically legal.
| IMHO that's an obsolete usage, and we've never seen a bona fide MTA
| using it when offering is mail, although we've seen quite a proportion
| of attempts that could be seen to be spam.


Some MUAs submit this way - may need to allow this format from local nets
and/or authenticated users.


| On the other hand, something like "HELO 11.22.33.44" would slip past
| the above recipe unchallenged. But if they present our own IP address
| (a rather common spammer trick, though I'm not sure what they hope to
| gain by it), we reject it in a separate recipe. Hmmm: I suppose we
| could really reject anything that looks like nothing more than a
| dotted IP address, as not conforming to the requirements of the RFC -
| what does the team think?


I sometimes see genuine mail with this style of HELO, and hence award spam
points rather than blocking outright.

But isn't 11.22.33.44 a syntactically legal domain name anyway ?



| Hmmm, interesting: a quick look at the current log shows that a
| substantial proportion of the requests that we've rejected recently on
| the grounds of their HELO domain have been attempts to bounce to a
| non-existent address in one of our domains. The addresses all have a
| plausible user name plus a random two-letter suffix, with or without
| an underscore, e.g major_dukes_qw or amy_henleyfp etc. I've mentioned
| this pattern before in a different context, it's presumably extruded
| by some prolific ratware? So I think these calls are coming from
| spam-targets who are either trying callout with us to check the
| counterfeited sender address, or attempting to bounce the spam to its
| supposed sender - from the log, one can't tell which.


I'm not quite understand this. If spam-targets are sending callouts or
bounces, then shurely the HELOs should be fine ?

( assuming most spam goes to targets like yahoo, aol which normally emit
legal outgoing HELOs )