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)?<br>
<br><div class="gmail_quote">On Fri, Feb 29, 2008 at 10:05 AM, Hostmaster <<a href="mailto:Hostmaster@computerservicecentre.com">Hostmaster@computerservicecentre.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-GB">
<div>
<p>Hi All,</p>
<p>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. </p>
<p> </p>
<p><rant></p>
<p>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.</p>
<p> </p>
<p>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. </p>
<p> </p>
<p>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)!</p>
<p></rant></p>
<p> </p>
<p>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?</p>
<p><span style="font-size: 10pt;">Best Regards,</span><span style="font-size: 12pt;"> </span><span style="font-size: 12pt;"></span></p>
<p><span style="font-size: 10pt;">Richard Garner (A+,
N+, AMBCS, MOS-O)</span><span style="font-size: 12pt;">
</span><span style="font-size: 12pt;"></span></p>
</div>
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.<br>
<p></p>
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.<br>
<p></p>
Any views or opinions presented are solely those of the author and do not necessarily represent those of Computer Service Centre.<br>
</div>
<br>--<br>
MailScanner mailing list<br>
<a href="mailto:mailscanner@lists.mailscanner.info">mailscanner@lists.mailscanner.info</a><br>
<a href="http://lists.mailscanner.info/mailman/listinfo/mailscanner" target="_blank">http://lists.mailscanner.info/mailman/listinfo/mailscanner</a><br>
<br>
Before posting, read <a href="http://wiki.mailscanner.info/posting" target="_blank">http://wiki.mailscanner.info/posting</a><br>
<br>
Support MailScanner development - buy the book off the website!<br>
<br></blockquote></div><br>