OOT: Mail rejected with bogus helo

[Peter Farrow]

Glenn Steen wrote:
> On 16/04/2008, Peter Farrow <peter at farrows.org> wrote:
>   
>> Matt Kettler wrote:
>>
>>     
>>> Budi Febrianto wrote:
>>>
>>>       
>>>> Dear All,
>>>>
>>>> I know this OOT, but because many sendmail experts in here, I give it a
>>>>         
>> shot.
>>     
>>>> I'm using sendmail-8.13.8-2.el5 with MailScanner 4.65.3.
>>>>
>>>> Whenever my users sent emails to certain domains, it will rejected with
>>>>         
>> this error.
>>     
>>>>  >>>>>
>>>> 553 yyy.yyy.yyy.yyy rejected due to spam, contact 555-505-5555 (bogus
>>>>         
>> helo xxx.xxx.xxx.xxx)
>>     
>>>>  >>>>>
>>>>
>>>> I'm not sure what happen, because I don't have the same problem with
>>>>         
>> others domain.
>>     
>>> Your system is issuing a HELO in IP format, which is RFC compliant, but
>>>       
>> some view this as a sign a system isn't properly configured and will refuse
>> mail from such systems.
>>     
>>> However, more troublesome is your system is issuing a HELO in IP format
>>>       
>> using a private-range non-routable IP, 10.10.16.24. This is blatantly bogus
>> when communicating with hosts outside your network, as those hosts will
>> never be able to route to 10.10.16.24 and reach your server. (The original
>> intent, although outdated, is for the HELO to be usable as a hint for where
>> to return mail to if DNS fails to generate a MX or implicit MX record.
>> Generating private IPs here is clearly contrary to that.)
>>     
>>> Ultimately, it's up to the administrator of the system you're trying to
>>>       
>> contact to tell you why he's filtering you. Those are purely guesses on my
>> part, based on looking at the HELO's your server issued, and general
>> knowledge of what some admins do for filtering that not everyone does.
>>     
>>  I agree, technically its against RFC to block email based on a bad helo see
>> RFC 2821, however none of the systems I administer will accept an obviously
>> bogus hello, this is very effective at MTA level in controlling the entry of
>> spam into the mailscanner.
>>
>>  RFC 2821 >> "However, the server MUST NOT refuse to accept a message for
>> this reason if the verification fails"
>>     
> This only pertain to verification (via DNS)  of the address. If the
> adress doesn't follow the norm for a FQDN (the letter of the law, so
> to speak), you are quite right to reject it.
> Matt and I hashed this over a while back, go look in the archives (or
> both RFC1123 (which manage HELO) and 2821 (for EHLO))...;-)
>
>   
>>  Its up to you how you handle it, but more and more servers will refuse a
>> bad helo even though technically they shouldn't.
>>     
> ... oh yes they should... at least if the form (a plain word, or
> malformed address literal... or somesuch) is wrong. But you are right
> in that RFC1123/2821 demand that you don't reject based on a DNS
> verification (although you're free to do one... Whatever good that
> would do:-).
>
>
>   
>>  Pete
>>
>>
>>     
>
> Cheers
>   
Glen,

Not quite right there my friend....

No disrespect and this is a moot point since all the servers I configure 
reject based on a bogus helo the RFC says "if possible" and "MUST NOT", 
which is not obligatory, which means technically a bogus helo is not a 
good enough reason to reject( even though I do), so, on a point of 
"internet law" you're in the wrong for rejecting based exclusively on 
bogus helos.  However the defacto standard and general good practice 
would dictate that yes indeed it is valid thing to do...

If you want to be really picky here is the text verbatim from 2821

-----------
The SMTP client MUST, if possible, ensure that the domain parameter to 
the EHLO command is a valid principal host name (not a CNAME or MX name) 
for its host. If this is not possible (e.g., when the client's address 
is dynamically assigned and the client does not have an obvious name), 
an address literal SHOULD be substituted for the domain name and 
supplemental information provided that will assist in identifying the 
client. 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.
---------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20080416/11ce87f8/attachment.html