OOT: Mail rejected with bogus helo

[Hugo van der Kooij]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Farrow 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....
|
| 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.
| ---------

I think the principal concern with rejects here was not about policies
on the receiving SMP servers but the generic concern one should not
reject in case your DNS server is not working (properly).

Hugo.

- --
hvdkooij at vanderkooij.org               http://hugo.vanderkooij.org/
PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc

	A: Yes.
	>Q: Are you sure?
	>>A: Because it reverses the logical flow of conversation.
	>>>Q: Why is top posting frowned upon?

Bored? Click on http://spamornot.org/ and rate those images.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIBtofBvzDRVjxmYERAkWpAJ4l6ZofCSr7WX0d2Qg2UtzXQAO6ygCfQP+P
60MAHfa1CBIJUz4J9nqp2lg=
=CNHM
-----END PGP SIGNATURE-----