[Maybe OT] - RFC compliance checking at session

[Glenn Steen]

On 29/02/2008, Rick Cooper <rcooper at dwford.com> wrote:
>
>
>   > -----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.
>
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.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se