[Mimedefang] OT: New Sendmail spam block

[James Ebright]

>From RFC2821:

4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument field contains the fully-qualified domain name
   of the SMTP client if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see section
   4.1.3), optionally followed by information that will help to identify
   the client system. 

Looks to me that the keyword SHOULD means you do not have to if you have a
good reason not to. However, your system probably does have a meaningful
domain name and a FQDN in DNS.... just your MTA (Norton gateway) is not doing
the correct thing and probably needs to be behind a real MTA, thus, I do think
that your MTA is just as "non compliant" as theirs is, if not more so.

However looks like section 4.1.4 still has this text:

   An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.

Which leads me to believe that in order to be fully compliant, you can not
disallow a message solely due to the HELO/EHLO that was given.

In the examples we have laid out in previous messages we took the HELO and
rejected the message based not soley on the HELO but also due to the fact that
the HELO/EHLOs were attempted header forgeries of our own known systems, or a
literal in the wrong format (e.g. no brackets) in an attempted forgery or
obfuscation. Either of which I think would satisfy the RFCs MUST NOT.

Now I did notice MD using filter_recipient(sender, et al) and using return
('REJECT', "BOGUS HELO $helo blah blah blah....") will issue a 550 5.7.1
reject from the milter in the filter_recipient stage (I wait until filter
recipient as I need to skip filtering my abuse addresses, and a few other
things) which is not the 500, 501, or 502 reject as specified with a MUST in
the RFC, but.. mine is not in response to the HELO parameter either but to the
RCPT TO: command and at this point I have looked at the sender, the recipient,
a list of allowed HELOs from certain IPs (e.g. my mail servers), the format of
the HELO/EHLO (the literal) and in my case user authentication, accessdb hash
table lookups on blackholed relays (in our case we delay checks thus need to
look at this inside the milter to be 100% effective), and so on, so as you
see, it is no where near based solely on the HELO/EHLO. Also, I have extensive
logged evidence that 550 rejects are what these messages actually do deserve;
all bare literals I have logged either ended up as user unkowns or
tagged/rejected as spam... _ALL_ of them. I think I am fully satisfying the
RFC in this regard as well.

So, while I think it may be a little draconian and that they are going to have
numerous issues with poorly coded MTAs... I think they are probably not in
violation of the RFC if they are doing any checking at all in conjunction with
the HELO/EHLO checks and not just pattern matching it and rejecting it. Now I
think the code we have posted that catches the bare literals is probably in
violation, in of itself... but since its implementation in MD still accepts
the bogus HELO and actually does not issue a reject until after the RCPT TO:
command (or MAIL FROM: if you run yours in filter_sender) I think we are still
in compliance with the RFC as well.

Anyway, still sifting some of this.. maybe I will change my mind but bottom
line is.. I think your Norton product is broke!

Jim

On Fri, 25 Mar 2005 11:43:24 -0600, Ben Kamen wrote
>   I'm looking over it and the section reads more like 821 than 1123.
> 
> I'm not trying to beat a dead horse - I'm just trying to make sure 
> my interpretation of the "rules" are correct. Right now, Spam has 
> everyone trying things of which some seem to break MTA's in a 
> legitamate fashion while other methods are in a way vigalantism (if 
> that's word)...
> 
> How do you politely tell another admin he's broken something against 
> an RFC when there's room for personal inflection of what the RFC is
recommending.

--
EsisNet.com Webmail Client