Discussion:
OOT: Mail rejected with bogus helo
(too old to reply)
Budi Febrianto
2008-04-16 09:31:48 UTC
Permalink
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.

TIA
Steve Freegard
2008-04-16 10:43:25 UTC
Permalink
Hi Budi,
Post by Budi Febrianto
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.
RFC2821 states that the HELO should either by a FQDN or an IP-domain
literal (e.g. [ip.ip.ip.ip]) so a bareword IP address in the HELO that
is not in square brackets is not valid.

So - if you are sending "HELO ip.ip.ip.ip", then that isn't valid, but I
don't think it's possible for Sendmail to sent a HELO in this format as
it always does the right thing.

The command 'sendmail -d0.5 < /dev/null' will show you all the name
variations that sendmail would use in a HELO argument.

I suspect however that in this case it's simply a lame spam filter
that's causing you an issue. Feel free to mail me directly to my
@fsl.com which has strict-helo filtering amongst other things, so being
able to mail me directly without getting an SMTP-time rejection would be
a good way to prove it.

Cheers,
Steve.
Matt Kettler
2008-04-16 15:49:31 UTC
Permalink
Post by Budi Febrianto
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.
Scott Silva
2008-04-16 17:12:20 UTC
Permalink
Post by Matt Kettler
Post by Budi Febrianto
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.)
To expand on this, just in case the OP is still confused, your private IP helo
is possibly due to running your server natted behind a router. You will have
to modify your servers configuration to give a FQDN or IP that is its natted
equivalent.
Post by Matt Kettler
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.
--
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20080416/71247b24/signature.bin
Peter Farrow
2008-04-16 20:22:48 UTC
Permalink
Post by Matt Kettler
Post by Budi Febrianto
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
Glenn Steen
2008-04-16 20:48:14 UTC
Permalink
Post by Budi Febrianto
Post by Matt Kettler
Post by Budi Febrianto
Dear All,
I know this OOT, but because many sendmail experts in here, I give it a
shot.
Post by Matt Kettler
Post by Budi Febrianto
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.
Post by Matt Kettler
Post by Budi Febrianto
553 yyy.yyy.yyy.yyy rejected due to spam, contact 555-505-5555 (bogus
helo xxx.xxx.xxx.xxx)
Post by Matt Kettler
Post by Budi Febrianto
I'm not sure what happen, because I don't have the same problem with
others domain.
Post by Matt Kettler
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.
Post by Matt Kettler
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.)
Post by Matt Kettler
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))...;-)
Post by Budi Febrianto
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:-).
Post by Budi Febrianto
Pete
Cheers
--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
Peter Farrow
2008-04-16 22:58:29 UTC
Permalink
Post by Glenn Steen
Post by Budi Febrianto
Post by Matt Kettler
Post by Budi Febrianto
Dear All,
I know this OOT, but because many sendmail experts in here, I give it a
shot.
Post by Matt Kettler
Post by Budi Febrianto
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.
Post by Matt Kettler
Post by Budi Febrianto
553 yyy.yyy.yyy.yyy rejected due to spam, contact 555-505-5555 (bogus
helo xxx.xxx.xxx.xxx)
Post by Matt Kettler
Post by Budi Febrianto
I'm not sure what happen, because I don't have the same problem with
others domain.
Post by Matt Kettler
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.
Post by Matt Kettler
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.)
Post by Matt Kettler
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))...;-)
Post by Budi Febrianto
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:-).
Post by Budi Febrianto
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.
---------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20080416/11ce87f8/attachment.html
Hugo van der Kooij
2008-04-17 06:04:13 UTC
Permalink
Peter Farrow wrote:
| Glenn Steen wrote:
|> On 16/04/2008, Peter Farrow <***@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.

- --
***@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.
Glenn Steen
2008-04-17 09:40:13 UTC
Permalink
Post by Budi Febrianto
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.
Post by Budi Febrianto
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
Matt Kettler
2008-04-17 14:45:12 UTC
Permalink
Post by Glenn Steen
Post by Peter Farrow
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.
Actually, the RFCs do not demand you reject a malformed HELO, and you know that
as well as I do. However, they do OK it when the malformed HELO will cause your
Received: headers to violate RFC formats.

Regardless it is still 100% RFC compliant to accept a malformed HELO if you
don't ever quote it in a Received: header, or otherwise modify it so the
Received: header you generate is compliant.


Also, this thread is about using an IP as a HELO, which is NOT a malformed HELO
per the RFCs. Therefore it is still against the RFCs to refuse mail because the
HELO is an IP address.
Glenn Steen
2008-04-17 15:23:53 UTC
Permalink
Post by Matt Kettler
Post by Glenn Steen
Post by Peter Farrow
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.
Actually, the RFCs do not demand you reject a malformed HELO, and you know
that as well as I do. However, they do OK it when the malformed HELO will
:-) Yeah.
Post by Matt Kettler
cause your Received: headers to violate RFC formats.
Exactly. Next best thing.
Post by Matt Kettler
Regardless it is still 100% RFC compliant to accept a malformed HELO if you
don't ever quote it in a Received: header, or otherwise modify it so the
Received: header you generate is compliant.
Yup.
Post by Matt Kettler
Also, this thread is about using an IP as a HELO, which is NOT a malformed
HELO per the RFCs. Therefore it is still against the RFCs to refuse mail
because the HELO is an IP address.
Are you thinking "a plain word that looks like an IP address" then?
Cause I'm pretty sure (boy am I going to get it... Haven't reread the
exact wording:-) that the demand is for Ip address literals, like
Steve points out, not a domain name looking like an IP address...
Oh well.

Cheers
--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
Matt Kettler
2008-04-17 18:00:59 UTC
Permalink
Post by Glenn Steen
Post by Matt Kettler
Also, this thread is about using an IP as a HELO, which is NOT a malformed
HELO per the RFCs. Therefore it is still against the RFCs to refuse mail
because the HELO is an IP address.
Are you thinking "a plain word that looks like an IP address" then?
Cause I'm pretty sure (boy am I going to get it... Haven't reread the
exact wording:-) that the demand is for Ip address literals, like
Steve points out, not a domain name looking like an IP address...
Oh well.
Erm, I'm not sure what difference you're implying exists between "a plain word
that looks like an IP address" and an "IP address literal". I'm also not sure
what you mean by "a domain name looking like an IP address".

The HELO string in question was "10.10.16.24", sans quotes, which matches
RFC2821's definition of IPv4-address-literal in section 4.1.3, which is in turn
a sub-type of address-literal in 4.1.2. This makes it 100% valid syntactically.

Of course, exposing a non-routable IP as a HELO is obviously bogus information,
but it is not syntactically invalid. Thus, blocking based on it is technically
against the RFCs. However, I'd expect some sites will block this, since the
information presented is obviously invalid.
mikea
2008-04-17 19:01:27 UTC
Permalink
Post by Matt Kettler
Post by Glenn Steen
Post by Matt Kettler
Also, this thread is about using an IP as a HELO, which is NOT a malformed
HELO per the RFCs. Therefore it is still against the RFCs to refuse mail
because the HELO is an IP address.
Are you thinking "a plain word that looks like an IP address" then?
Cause I'm pretty sure (boy am I going to get it... Haven't reread the
exact wording:-) that the demand is for Ip address literals, like
Steve points out, not a domain name looking like an IP address...
Oh well.
Erm, I'm not sure what difference you're implying exists between "a plain
word that looks like an IP address" and an "IP address literal". I'm also
not sure what you mean by "a domain name looking like an IP address".
The HELO string in question was "10.10.16.24", sans quotes, which matches
RFC2821's definition of IPv4-address-literal in section 4.1.3, which is in
turn a sub-type of address-literal in 4.1.2. This makes it 100% valid
syntactically.
With respect, I have to differ with you. This point arises from time
to time on other lists, and I had to be educated about it myself.

<mode "rules-lawyer">

It's precisely the difference between "[10.10.16.24]" and "10.10.16.24",
and the semantics associated with those differences in the text of the
RFC.

"10.10.16.24", sans quotes, does not match RFC2821's definition of
IPv4-address literal in section 4.1.3, because it is not enclosed in
brackets ("[]"), as required by section 4.1.3:

: 4.1.3 Address Literals
:
: Sometimes a host is not known to the domain name system and
: communication (and, in particular, communication to report and repair
: the error) is blocked. To bypass this barrier a special literal form
: of the address is allowed as an alternative to a domain name. For
: IPv4 addresses, this form uses four small decimal integers separated
: by dots and enclosed by brackets such as [123.255.37.2], which
: indicates an (IPv4) Internet Address in sequence-of-octets form.

Instead, "10.10.16.24", sans quotes, is a domain name with a Top-Level
Domain "24", just as "foo.example.com" is a domain name with Top-Level
Domain "com". See section 2.3.5, and the BNF definition of "Domain" in
section 4.1.2, of RFC2821.
Post by Matt Kettler
Of course, exposing a non-routable IP as a HELO is obviously bogus
information, but it is not syntactically invalid. Thus, blocking based on
it is technically against the RFCs. However, I'd expect some sites will
block this, since the information presented is obviously invalid.
Au contraire, it is syntactically invalid because the brackets, which
are required, are absent: "[10.10.16.24]" is syntactically valid as an
address literal, while "10.10.16.24" is not -- sans quotes in both
cases, of course.

</mode>

To put it in the mildest of terms, I agree that it is not good practice
to expose as a HELO a non-routable IP written as an address literal. but
that's not what I'm blocking on at my shop.
--
Mike Andrews, W5EGO
***@mikea.ath.cx
Tired old sysadmin
Glenn Steen
2008-04-18 09:32:03 UTC
Permalink
Post by mikea
Post by Matt Kettler
Post by Glenn Steen
Post by Matt Kettler
Also, this thread is about using an IP as a HELO, which is NOT a malformed
HELO per the RFCs. Therefore it is still against the RFCs to refuse mail
because the HELO is an IP address.
Are you thinking "a plain word that looks like an IP address" then?
Cause I'm pretty sure (boy am I going to get it... Haven't reread the
exact wording:-) that the demand is for Ip address literals, like
Steve points out, not a domain name looking like an IP address...
Oh well.
Erm, I'm not sure what difference you're implying exists between "a plain
word that looks like an IP address" and an "IP address literal". I'm also
not sure what you mean by "a domain name looking like an IP address".
The HELO string in question was "10.10.16.24", sans quotes, which matches
RFC2821's definition of IPv4-address-literal in section 4.1.3, which is in
turn a sub-type of address-literal in 4.1.2. This makes it 100% valid
syntactically.
With respect, I have to differ with you. This point arises from time
to time on other lists, and I had to be educated about it myself.
As have we all.
Thank you Mike, for the work of explaining it in detail.
Post by mikea
<mode "rules-lawyer">
(snip)
Post by mikea
</mode>
To put it in the mildest of terms, I agree that it is not good practice
to expose as a HELO a non-routable IP written as an address literal. but
that's not what I'm blocking on at my shop.
Same here.

Cheers
--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
Julian Field
2008-04-17 19:04:48 UTC
Permalink
Glenn / Matt,

Do you fancy taking this never-ending thread off-list please? It
deserves an awful lot of O's in its "OT" and I'm sad to say it descended
below boredom threshold for many of the rest of us a long time ago :-)

If you ever come to an agreement, please feel free to post a summary :-)

Thanks guys!
Cheers,
Jules. :-)
Post by Matt Kettler
Post by Glenn Steen
Post by Matt Kettler
Also, this thread is about using an IP as a HELO, which is NOT a malformed
HELO per the RFCs. Therefore it is still against the RFCs to refuse mail
because the HELO is an IP address.
Are you thinking "a plain word that looks like an IP address" then?
Cause I'm pretty sure (boy am I going to get it... Haven't reread the
exact wording:-) that the demand is for Ip address literals, like
Steve points out, not a domain name looking like an IP address...
Oh well.
Erm, I'm not sure what difference you're implying exists between "a
plain word that looks like an IP address" and an "IP address literal".
I'm also not sure what you mean by "a domain name looking like an IP
address".
The HELO string in question was "10.10.16.24", sans quotes, which
matches RFC2821's definition of IPv4-address-literal in section 4.1.3,
which is in turn a sub-type of address-literal in 4.1.2. This makes it
100% valid syntactically.
Of course, exposing a non-routable IP as a HELO is obviously bogus
information, but it is not syntactically invalid. Thus, blocking based
on it is technically against the RFCs. However, I'd expect some sites
will block this, since the information presented is obviously invalid.
Jules
--
Julian Field MEng CITP CEng
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

MailScanner customisation, or any advanced system administration help?
Contact me at ***@Jules.FM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
PGP public key: http://www.jules.fm/julesfm.asc
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Glenn Steen
2008-04-18 09:34:33 UTC
Permalink
Post by Julian Field
Glenn / Matt,
Do you fancy taking this never-ending thread off-list please? It deserves
an awful lot of O's in its "OT" and I'm sad to say it descended below
boredom threshold for many of the rest of us a long time ago :-)
:-)
Sure, no problem.
Post by Julian Field
If you ever come to an agreement, please feel free to post a summary :-)
As far as I'm concerned, everything is crystal clear. Much thanks to
Mike Andrews summary on address literals.
But I'll shut up now:-).
Post by Julian Field
Thanks guys!
Cheers,
Jules. :-)
Cheers
--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
Peter Farrow
2008-04-18 00:33:24 UTC
Permalink
Post by Matt Kettler
Post by Glenn Steen
Post by Matt Kettler
Also, this thread is about using an IP as a HELO, which is NOT a malformed
HELO per the RFCs. Therefore it is still against the RFCs to refuse mail
because the HELO is an IP address.
Are you thinking "a plain word that looks like an IP address" then?
Cause I'm pretty sure (boy am I going to get it... Haven't reread the
exact wording:-) that the demand is for Ip address literals, like
Steve points out, not a domain name looking like an IP address...
Oh well.
Erm, I'm not sure what difference you're implying exists between "a
plain word that looks like an IP address" and an "IP address literal".
I'm also not sure what you mean by "a domain name looking like an IP
address".
The HELO string in question was "10.10.16.24", sans quotes, which
matches RFC2821's definition of IPv4-address-literal in section 4.1.3,
which is in turn a sub-type of address-literal in 4.1.2. This makes it
100% valid syntactically.
Of course, exposing a non-routable IP as a HELO is obviously bogus
information, but it is not syntactically invalid. Thus, blocking based
on it is technically against the RFCs. However, I'd expect some sites
will block this, since the information presented is obviously invalid.
Matt has touched on what I said earlier here and I think Matts summary
is most succinct and right on the money. Its not valid RFC form to
explicitly reject based on this type of helo, but to send such an
obviously bogus helo is really asking for trouble. You would not get
past my main servers with this type of helo, and it could be very simple
to correct. I would, in short, save yourself all the bother and just
send a properly constructed helo that is recognisable anywhere (i.e. not
constructed from anything in RFC1597) and definately not something like
"localhost" ;-)

Regards

Pete
Loading...