[Maybe OT] - RFC compliance checking at session

[Glenn Steen]

On 29/02/2008, Richard Frovarp <richard.frovarp at sendit.nodak.edu> wrote:
> 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.
>
No it's not.
Go read 1123 and 2821, and the thread I and Matt Kettler had a while
back on that very subject. Quite an easy check, and effective.
If one want's to play it safe, use the chack in conjunction with
greylisting (as a greylist criteria), to sort of both have and eat the
cake (wonder if I got that right...:-).

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se