OOT: Mail rejected with bogus helo

[Peter Farrow]

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"

Its up to you how you handle it, but more and more servers will refuse a 
bad helo even though technically they shouldn't.

Pete