[Maybe OT] - RFC compliance checking at session

[mikea]

On Sat, Mar 01, 2008 at 08:14:55AM +0000, Jason Ede wrote:

> What do ppl tend to do about MTA's that don't seem to understand
> temporary reject codes (such as 450) for stuff like greylisting?
> We've one client that uses our spam filtering and it seems to be
> only 1 that complains that people seem unable to email them. The one
> rejection email that I've had sent through (only 1 ever been sent
> despite repeated requests for NDRs to work out why the email isn't
> getting through) indicated that their ISP tried once to deliver
> email and then bounced it right back to sender if it got any form of
> response from our server. As far as I understand that's in direct
> contradiction of the RFCs. I thought if it was a 5XX or the like
> then it should return to sender but a 4XX code should always be
> retried at least a few times for a period of upto 5 days.
>
> I really like greylisting as it cuts down our server load by a
> factor of 2 or more and makes it possible not to need more servers,
> but it's getting the boss to understand that we can't keep just
> adding exception after exception for people and their bad ISP's as
> we don't know where they will be mailing from beforehand...

I (reluctantly) exempt the sending IPs from greylisting. Similarly, 
I've had to exclude some senders from greet-pause screening, because
they're needed, even though they connect-and-blast. I hate it, but the
mail is mission-related and the addressees tell me they need it. 

I've had to mark some senders and some receivers as "don't use TLS", 
too, because they don't do TLS correctly. Some of them are companies 
that do commercial mail screening, and it's very interesting that our
TLS won't interoperate with theirs but will work with 99.995% of the 
world. 

Summary: processing mail is a job full of exception-handling.

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin