[Maybe OT] - RFC compliance checking at session

[Glenn Steen]

On 29/02/2008, Hostmaster <Hostmaster at computerservicecentre.com> wrote:
>
>
>
>
> 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.
>
Not to mention 1123... Which cares for HELO, while 2821 caters for EHLO...:-).

>
>
> <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.
>
Sensible. Exactly what every mail admin on the planet should do.

>
>
> 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.
>
A clear violation. Your user lose, unless pressure to get _them_ to
fix it is successfully applied... Think "Sopranos"....:-D
Kidding aside, it is NOT your problem. If anything it is a thing
between your user and the idiots operating the list in question...
Your job is to make that crystal clear to the user. And that it is not
an option to whitelist. If you do, where do you stop!? Acception
viruses gratuitously? No. Just say no. There is no leeway on this, as
one can have with other things in the RFCs, they can have no benefit
from their broken system, so they shouldn't be excused.

>
>
> 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 MTghostscript-dvipdf-8.60-55.2mdv2008.0.i586.rpmA 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 they add error after error, then shrug it off (I applaud your
tenacity, doing all that work... The user isn't your CEO, by any
chance? Even a CEO need hear a "no, it's not how things are best done,
not even close" from time to time:-).... They get what they deserve.
I had a similar incident a week or so back, where the press secretary
(a C<something> position with a lot of clout in our organization) got
charged for a "leadership network seminar" she supposedly had been
invited to (it's a "pay if you don't opt out" kind of thing. Gah), but
that had been rejected since they EHLO'd as "bertil".... Well, after
pointing out that they were in violation of email standards, and that
there was no chance in <insert favorite purgatory place> I was going
to do silly hoops to let them through... *she* took a contact
demanding (and getting) a refund, as well as a promise (from the
non-tech contact, with a certain amount of clout) that they  would fix
it ASAP.

Morale of the story? Well:
- Don't give in.
- Make the user make a formal complaint to the *business* side of
things. It is MUCH more effective, since they (unlike the tech you
talked to) usually have a clearer view of where the beans are coming
from.

> </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?

Don't change a thing. Tell your user that they (the list owners, not
the user:-) are idiots, and back it up with log snippets and RFC
references (if needed). If possible, advice your user to shop
elsewhere for that list content... and if you have a business
relationship with them, tell your user to shop elsewhere, period. If
they can't get a simple thing like this right (after being poked),
what else do they get wrong?;-)

> Best Regards,
>
Do a double-dash-space here, like
-- 
... and everything below will be trimmed by smart MUAs (or MUA users:-)
> Richard Garner (A+, N+, AMBCS, MOS-O)
... as is, I'll just (snip) away...:-)

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