[Maybe OT] - RFC compliance checking at session

Rick Cooper rcooper at dwford.com
Fri Feb 29 21:36:43 GMT 2008


 > -----Original Message-----
 > From: mailscanner-bounces at lists.mailscanner.info 
 > [mailto:mailscanner-bounces at lists.mailscanner.info] On 
 > Behalf Of Richard Frovarp
 > Sent: Friday, February 29, 2008 3:49 PM
 > To: MailScanner discussion
 > Subject: Re: [Maybe OT] - RFC compliance checking at session
 > Rick Cooper wrote:
 > >
 > >     
 > -------------------------------------------------------------
 > -----------
 > >     *From:* mailscanner-bounces at lists.mailscanner.info
 > >     [mailto:mailscanner-bounces at lists.mailscanner.info] 
 > *On Behalf Of
 > >     *Hostmaster
 > >     *Sent:* Friday, February 29, 2008 10:06 AM
 > >     *To:* MailScanner discussion
 > >     *Subject:* [Maybe OT] - RFC compliance checking at session
 > >     I also run Exim and I have a !hosts =
 > >     /ListOfDickHeadsIHaveToAccept before each compliance check
 > >     condition. For instance a Zurich subsidiary that helo'd as
 > >     something_stupid.local, no RDNS, they did about everything but
 > >     spit on the RFCs and we had to have thier mail. I put 
 > them in the
 > >     list, inform the maintainers and remove them after 90 
 > days and see
 > >     what happens. The file can be just a flat text file in 
 > the format of
 > >
 > > # Remove in April
 > >
 > > # Remove In May
 > >
 > >     They do not, of course, get a pass around virus, 
 > attachment, etc
 > >     checking, just compliance checks.
 > >
 > >     Rick
 > >
 > I thought that rejecting on helo alone was against the RFCs.
I admit that rejecting on helo alone is a violation and I thought about it
long and hard before implementing. RFC 821 was written in, I believe, 1984
and the world has changed. In 1984 spam was a nasty kind of meat (except of
course in Hawaii where it's primo food). 821 clearly states a MUST ensure
the domain parameter is a valid principle domain name for the client host.
It then states the receiver MUST NOT refuse if the helo validation fails and
then has a note that the helo argument must still have a valid domain syntax
otherwise a 501 error is to be sent. And of course later RFCs state that if
a host doesn't have a valid FQDN the dotted quad IP should be sent inside
square brackets in the form of [xxx.xxx.xxx.xxx]. 

That is just to obtuse and in today's world it doesn't make sense. RFC 821
even states the suggested procedure to use when a helo is invalid is to
insert a note in the message header and gives the received header as an
example. Now according to RFC 821 if I am MX mail.somedomain.com and I
reside at IP and a host residing at helos as
mail.somedomain.com I should accept the message even though this is
*clearly* an attempt to circumvent security... I just don't buy that. In
fact if you helo as any host from any domain under our company control and
your IP places you outside any of the associated IPS I will drop the session
right there as well. So yes, I am sorry to say that is one RFC section I
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.


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the MailScanner mailing list