[Maybe OT] - RFC compliance checking at session

Douglas Ward dward at nccumc.org
Fri Feb 29 16:51:27 GMT 2008


I believe that the problem is on their end, not yours.  You have to follow
the RFC's.  If they choose not to then you simply can't communicate.  I have
had this problem a very few times.  Each time I was able to resolve it by
asking the end user to subscribe a different e-mail address.  If they could
receive it then problem solved.  If no one else would accept the message
then it reinforced my point.  Perhaps a whitelist (last resort)?

On Fri, Feb 29, 2008 at 10:05 AM, 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.
>
>
>
> <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?
>
> Best Regards,
>
> Richard Garner (A+, N+, AMBCS, MOS-O)
>  All E-Mail communications are monitored in addition to being content
> checked for malicious codes or viruses. The success of scanning products is
> not guaranteed, therefore the recipient(s) should carry out any checks that
> they believe to be appropriate in this respect.
>
> This message (including any attachments and/or related materials) is
> confidential to and is the property of Computer Service Centre, unless
> otherwise noted. If you are not the intended recipient, you should delete
> this message and are hereby notified that any disclosure, copying, or
> distribution of this message, or the taking of any action based on it, is
> strictly prohibited.
>
> Any views or opinions presented are solely those of the author and do not
> necessarily represent those of Computer Service Centre.
>
> --
> MailScanner mailing list
> mailscanner at lists.mailscanner.info
> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>
> Before posting, read http://wiki.mailscanner.info/posting
>
> Support MailScanner development - buy the book off the website!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20080229/42d85f33/attachment.html


More information about the MailScanner mailing list