OOT: Mail rejected with bogus helo

[Glenn Steen]

On 16/04/2008, Peter Farrow <peter at farrows.org> wrote:
>
>  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....
:-) Look again... This is all about DNS address verification. Not
relevant to the rejection of a malformed HELO/EHLO.
The RFCs actually _demand_ that you reject those.

>  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.
>  ---------
Yes, this is correct ... it states that you cannot use DNS for
rejections. This is entirely beside the point. Go read the thread if
you like the nitty gritty details (I'm too lazy to find the relevant
quotes again).

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