[Maybe OT] - RFC compliance checking at session

[Jason Ede]

> -----Original Message-----
> From: mailscanner-bounces at lists.mailscanner.info [mailto:mailscanner-
> bounces at lists.mailscanner.info] On Behalf Of Rick Cooper
> Sent: 01 March 2008 00:55
> To: 'MailScanner discussion'
> Subject: RE: [Maybe OT] - RFC compliance checking at session
>
>
>
>  > -----Original Message-----
>  > From: mailscanner-bounces at lists.mailscanner.info
>  > [mailto:mailscanner-bounces at lists.mailscanner.info] On
>  > Behalf Of Glenn Steen
>  > Sent: Friday, February 29, 2008 5:21 PM
>  > To: MailScanner discussion
>  > Subject: Re: [Maybe OT] - RFC compliance checking at session
>  >
> [...]
>  > >  will violate. But if I can validate any part of the helo,
>  > I will accept the
>  > >  message. But sans RDNS, heloing as BILLS_ROOM.local is
>  > getting the door
>  > >  slammed for sure. You give a proper helo, have something
>  > like proper DNS and
>  > >  even if you are a host on comcast's dynamic pool you will
>  > get past the helo,
>  > >  probably won't get very far past it but you will get past it.
>  > >
>  > Mostly truee for 1123 too...
>  > Since I get a good effect from the strict part, I don't do the rdns
>  > valitation... When the srtictness checks stop being effective I
> might
>  > start looking at it, but by then... there might be a new RFC
>  > outdating
>  > both 2821 and 1123 (and 821, which is already superseded) that
>  > actually tell us that we MUST validate the domain.... No, wait, that
>  > ust be another beverage-induced fever-dream;-D.
>  >
>
>
> The whole chain of supersession get's tiresome in and of it's self. I
> would
> swear that I had read a 821 superssion that changed the wording of the
> MUST
> not refuse to SHOULD not refuse.... But I hadn't the time to look it
> up.
> Anyway you look at it local policy MUST always win. God wouldn't it be
> nice
> to go back to the days when that hoax about just reading an email and
> getting a virus was still just a hoax (thank you Bill Gates)?
>
> Rick
>

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...

Jason