[Maybe OT] - RFC compliance checking at session
richard.frovarp at sendit.nodak.edu
Fri Feb 29 20:48:50 GMT 2008
Rick Cooper wrote:
> *From:* mailscanner-bounces at lists.mailscanner.info
> [mailto:mailscanner-bounces at lists.mailscanner.info] *On Behalf Of
> *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.
> 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)!
> 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.
I thought that rejecting on helo alone was against the RFCs.
More information about the MailScanner