[Maybe OT] - RFC compliance checking at session

[Richard Frovarp]

Rick Cooper wrote:
>
>     ------------------------------------------------------------------------
>     *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
>

I thought that rejecting on helo alone was against the RFCs.