OOT: Mail rejected with bogus helo

[Glenn Steen]

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
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se