[Maybe OT] - RFC compliance checking at session

[Rick Cooper]

  _____  

From: mailscanner-bounces at lists.mailscanner.info
[mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf Of Hostmaster
Sent: Friday, February 29, 2008 10:06 AM
To: MailScanner discussion
Subject: [Maybe OT] - RFC compliance checking at session



Hi All,

I would like to illicit some opinions from you other MailScanner using
MX-administrators. I know that there was some discussion on list some time
ago regarding session checking, particularly HELO/EHLO checking, and its
compliance against RFC 821, as clarified and updated in 2821. 

 

<rant>

We use Exim for both inbound and outbound message handling around
MailScanner, and on the inbound, some quite complex ACL's to validate the
session to try and cut down the amount of spam our users get. The first
check we run is to ensure that the HELO/EHLO is an FQDN. We don't then
validate if this FQDN can be resolved, or even if it is valid, it just has
to be host.domain.tld, and this significantly cuts the number of RBL lookups
we do. This hasn't caused us any problems with rejecting valid mail until
now.

 

One of our users complained that they were no longer receiving a newsletter
they signed up for. I managed to find it in the exim reject logs, and sure
enough, it was failing the host checking - the EHLO it sends is
"(server3549)", and exim declines the session with a 550 - permanent reject
for policy reasons. 

 

Now comes the fun part. That 550 is not enough for the sender - it ignores
it and constantly retries the send, treating it more like a 450, but not
following any normal MTA retry period I can establish. That would be enough
for me to leave them blocked, but checking further, the IP for that host has
no RDNS, also a big no-no in my opinion for a valid mail server, and the IP
does not accept return SMTP - indicating that it's probably a web server and
not an MTA itself.  I even took the liberty of doing an IPWhois, phoning the
helpdesk of the company responsible for the IP (only because they are UK
based the same as us) and pointing the problem out, only to be met with
"yeah, we know about that, it'll be fixed sometime next year when we put a
new server in", even after I pointed out that they wouldn't be getting
successful deliveries to organisations such as AOL (RDNS is a must) and
BT/Yahoo (whose policies are incredibly strict)!

</rant>

 

So what do you guys think? Am I just being particularly awkward on a Friday
afternoon and should I spend my time re-working our config to work around an
organisation who is blatantly ignorant of common mail server practise, or
just tell my user that the sending organisation needs to get their act
together?
[Rick Cooper] 

 

I also enforce a proper helo name. I just went through this with a rather
large insurance company that switched mail servers and the new server was
incorrectlu configured so it helo'd with something like boogabooga.internal
(I don't remember the host name part). The smart ass mail admin said "what
if that host doesn't have a FQDN" and I replied dotted quad in square
brackets according to the RFCs... bud.

 

I come across this now and then and I always try and contact the sender's
responsible party to clear it up, it wrong, it breaks SPF, it breaks RFCs
and it's VERY common to see unqualified names coming from BOTS, virus and
spam. I bet if you look though your logs you will see most hosts that helo
with a non FQDN or .internal/.local/.localdomain are mostly dynamic DSL or
cable hosts. I dump a ton of them everyday.

 

I also run Exim and I have a !hosts = /ListOfDickHeadsIHaveToAccept before
each compliance check condition. For instance a Zurich subsidiary that
helo'd as something_stupid.local, no RDNS, they did about everything but
spit on the RFCs and we had to have thier mail. I put them in the list,
inform the maintainers and remove them after 90 days and see what happens.
The file can be just a flat text file in the format of

 

10.10.10.10 # Remove in April

10.10.10.1 # Remove In May

 

They do not, of course, get a pass around virus, attachment, etc checking,
just compliance checks.

 

Rick


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20080229/855e5d8c/attachment.html