[Maybe OT] - RFC compliance checking at session
glenn.steen at gmail.com
Fri Feb 29 21:40:06 GMT 2008
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...:-).
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
More information about the MailScanner