[Maybe OT] - RFC compliance checking at session

[Rick Cooper]

 > -----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
 > >
 > >     10.10.10.10 # Remove in April
 > >
 > >     10.10.10.1 # 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 10.10.10.1 and a host residing at 10.9.1.1 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.

Rick


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