<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Glenn Steen wrote:
<blockquote
cite="mid223f97700804161241u31d94078y7400333d403f1a8@mail.gmail.com"
type="cite">
<pre wrap="">On 16/04/2008, Peter Farrow <a class="moz-txt-link-rfc2396E" href="mailto:peter@farrows.org"><peter@farrows.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Matt Kettler wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Budi Febrianto wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear All,
I know this OOT, but because many sendmail experts in here, I give it a
</pre>
</blockquote>
</blockquote>
<pre wrap="">shot.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap="">this error.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> >>>>>
553 yyy.yyy.yyy.yyy rejected due to spam, contact 555-505-5555 (bogus
</pre>
</blockquote>
</blockquote>
<pre wrap="">helo xxx.xxx.xxx.xxx)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> >>>>>
I'm not sure what happen, because I don't have the same problem with
</pre>
</blockquote>
</blockquote>
<pre wrap="">others domain.
</pre>
<blockquote type="cite">
<pre wrap="">Your system is issuing a HELO in IP format, which is RFC compliant, but
</pre>
</blockquote>
<pre wrap="">some view this as a sign a system isn't properly configured and will refuse
mail from such systems.
</pre>
<blockquote type="cite">
<pre wrap="">However, more troublesome is your system is issuing a HELO in IP format
</pre>
</blockquote>
<pre wrap="">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.)
</pre>
<blockquote type="cite">
<pre wrap="">
Ultimately, it's up to the administrator of the system you're trying to
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<pre wrap=""> 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"
</pre>
</blockquote>
<pre wrap=""><!---->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))...;-)
</pre>
<blockquote type="cite">
<pre wrap=""> Its up to you how you handle it, but more and more servers will refuse a
bad helo even though technically they shouldn't.
</pre>
</blockquote>
<pre wrap=""><!---->... 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:-).
</pre>
<blockquote type="cite">
<pre wrap=""> Pete
</pre>
</blockquote>
<pre wrap=""><!---->
Cheers
</pre>
</blockquote>
Glen,<br>
<br>
Not quite right there my friend....<br>
<br>
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...<br>
<br>
If you want to be really picky here is the text verbatim from 2821<br>
<br>
-----------<br>
<font face="Courier New, Courier, monospace"> 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.
</font><br>
---------<br>
</body>
</html>