On Sun, 10 Apr 2005, Michael J. Tubby B.Sc. (Hons) wrote:
> Analysing our logs we find that we reject HELO/EHLO from:
>
> a) 'bare' IP addresses, eg.
>
> HELO 1.2.3.4
We certainly reject such HELO strings which match our own IP address,
of which there are still considerable numbers, and I'm not aware of
any cases where the attempt was bona fide. I don't recall seeing
other "bare" IP addresses - would it be worth rejecting those in
general from remote MTAs? Maybe I'll take a look.
By the way, I'm talking in this note about mail offerings from remote
MTAs (mail submission by our own users is very different, I'm not
covering that here).
[...]
> d) senders that say HELO from a non FQDN, like:
>
> HELO MAILSERVER
> HELO OEMCOMPUTER
>
> the latter being a well known virus.
We reject HELO strings of (case insensitive) oemcomputer,
oemcomputer.com, oemcomputer.org and oemcomputer.net, all of which
have been seen in considerable numbers in recent times, and none of
which were bona fide.
(However, the string "@oemcomputer" (sometimes in uppercase) seems
to be quite prevalent in message-ids of otherwise-bona-fide mail.)
For a while recently, HELO strings of exactly "addr.com" were quite
prevalent, and we were rejecting those too, though they've faded out
now. Even addr.com themselves do not use that HELO string (they use
something like addrNN.addr.com for the various values of NN, although
I see that practically all the transactions we get offered from
addr.com are attempts to send us non-delivery reports for mail
allegedly from addresses in our domains which do not send mail, i.e
"collateral bounces", which we refuse).
Another pattern which was very prevalent around the turn of the year
was a ridiculously long HELO string containing repeated dots, e.g
inadequacy..g.c.rr.comyyhmail.comflytecrew.comultrapostman.comyyhmail.comkinki-k232.78.134.163
We blocked these merely on the match with \.\. , but they seem to have
stopped now.
> Our approach to handling email from public internet sites/addresses has
> changed to one of "how quickly can we find a reason to not let this
> email in"
It seems however that you have different operational criteria. We need
to minimise the number of false positives, rather than to have excuses
- no matter how well-supported technically - ready for why we rejected
them.
For the most part, I'm glad to say that we can usually find some
criterion which optimises the rejection of abusive mail while limiting
the damage to bona fide senders, but I have to say that several of the
criteria you are using would be unacceptable in our situation.
Even our rejection of header syntax errors leads to instances of
inconvenience and embarrassment, mostly in dealing with senders who
are otherwise bona fide but are using MS crapware - which (as already
mentioned in a recent thread) not only creates syntactically defective
headers, but also fails to return our complete error diagnosis to the
sender and to their mail support staff - instead tells them lies about
what has happened[1]. Sure, we have a complete technical
justification for rejecting the item, but when this comes up, they are
certain to whine at us that we're the only one of their many
correspondents who are being so fastidious. And in many of these
cases we also get whined at by our users who wanted to receive this
mail. So it's a difficult line to tread.
best regards
[1] In the case in point, their MS software claimed to them that
"There was a SMTP communication problem with the recipient's email
server". Nope, there was no "SMTP communication problem" - we
returned the 550 rejection exactly as planned and for just cause -
SMTP was working as designed. The problems were entirely in their own
software, not on the SMTP communication channel. Problem 1 for
letting the user transmit defective headers in the first place, and
problem 2 for failing to report our diagnosis properly. So I think
I'm justified in rating their claim of "SMTP communication problem" as
a lie.
