Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bogus HELO/EHLO mail servers

37 views
Skip to first unread message

My name

unread,
Jan 7, 2004, 4:36:12 PM1/7/04
to
The following companys' mail servers are using bogus HELO/EHLO host
names when sending emails. What is their reason for doing so? How
can we ask them to change?

northgrum.com
csi-corp.com

We don't like keep adding exceptions to host authenications in our
mail server. Emails to their system administrators get nowhere. Any
suggestions?

William Park

unread,
Jan 7, 2004, 5:25:23 PM1/7/04
to

So, why do anything?

--
William Park, Open Geometry Consulting, <openge...@yahoo.ca>
Linux solution for data management and processing.

those who know me have no need of my name

unread,
Jan 7, 2004, 5:29:51 PM1/7/04
to
in comp.mail.misc i read:

>The following companys' mail servers are using bogus HELO/EHLO host
>names when sending emails. What is their reason for doing so?

these names are not required to be `valid' from your point of view.

--
a signature

Sam

unread,
Jan 7, 2004, 7:08:52 PM1/7/04
to
My name writes:

> The following companys' mail servers are using bogus HELO/EHLO host
> names when sending emails. What is their reason for doing so?

Either ignorance, indifference, or incompetence. Or some combination of the
three.

> How
> can we ask them to change?
>
> northgrum.com
> csi-corp.com
>
> We don't like keep adding exceptions to host authenications in our
> mail server.

Then don't.

> Emails to their system administrators get nowhere. Any
> suggestions?

Make a judgement call whether you want to bother making an exception for
them, try to continue your attempts to reach someone with a clue, or just
leave it alone, and let their mail bounce.

And once the decision has been made, you may consider the issue closed.

Jem Berkes

unread,
Jan 7, 2004, 7:35:39 PM1/7/04
to

An appropriate place to list the domains would be
http://www.rfc-ignorant.org/

Actually, the first domain is already listed there. Getting a listing here
will pressure a site to change their policy.

--
Jem Berkes
http://www.sysdesign.ca/

Neil W Rickert

unread,
Jan 7, 2004, 8:11:18 PM1/7/04
to
m...@news.info-for.us (My name) writes:

>The following companys' mail servers are using bogus HELO/EHLO host
>names when sending emails. What is their reason for doing so? How
>can we ask them to change?

>northgrum.com
>csi-corp.com

What are they using, and why is it a problem?

Andrew Butchart

unread,
Jan 7, 2004, 10:24:23 PM1/7/04
to

"Neil W Rickert" <ricke...@cs.niu.edu> wrote in message
news:btianm$8jj$1...@usenet.cso.niu.edu...
It could also depend on where the server is located. Some servers use their
own host name (some don't) and if their own name resolves to something
different than what you expect, that's an issue to address with their
network admin. I presume that you have a relationship with these companies
since you are caring about their HELO string.

--
Andrew Butchart
http://www.abutchartconsulting.com/botdocs/ - ABC Bot - Shareware SMTP/POP3
Mail Server


Jonathan de Boyne Pollard

unread,
Jan 8, 2004, 12:01:06 AM1/8/04
to
MN> The following companys' mail servers are using bogus HELO/EHLO
MN> host names when sending emails. What is their reason for
MN> doing so?

What is your reason for thinking that they are "bogus" ? Are they
syntactically incorrect ? Or is your SMTP Relay server trying to actually
derive a meaning from them in some fashion (which is at best a poor idea) ?

Alan Connor

unread,
Jan 8, 2004, 1:28:37 AM1/8/04
to

Expecting someone to identify themselves properly, to use their "real name"
is a "poor idea"?

AC

Andrea Griffini

unread,
Jan 8, 2004, 2:29:13 AM1/8/04
to
On Thu, 08 Jan 2004 06:28:37 GMT, Alan Connor <zzz...@xxx.yyy> wrote:

>Expecting someone to identify themselves properly, to use their "real name"
>is a "poor idea"?

Why would someone want to know the host name my server
has on my internal network provided for example that
there would be anyway no technical mean to reach that
server from the outside ?

I set up my server to present itself as smtp.<domain>
and by doing a forward DNS query that name actually
resolves to the IP address the server is using on the
internet, but the real machine name is different from
that; why should this be a problem ?

IMO the name we provide is real "enough" for the outside
world: it's a valid name, for which is possible to get
the IP address that also is exactly the one that the
connection is being done from and the domain is the same
specified in the "from" field... this should be even
*more* than enough to be sure the sender is traceable.

What is the "name" the machine has in our LAN, or what
is for example its internal IP address is something that
no one in the world excluding us should care about.
For the job of delivering mail its name is smtp.<domain>.

May be they are doing a *reverse* lookup on the IP
and find a different name ? I don't think this is
a reasonable check to be done. For example we simply
have no control at all about what the *reverse*
lookup on our IP returns.

Andrea

Alan Connor

unread,
Jan 8, 2004, 3:28:41 AM1/8/04
to

Thanks for clarifying the OP's post. I don't have any problem at all
with what you are doing.

As long as you provide an address where you can be reached and actually
check the mail there and respond to it "personally" that's good enough
for me.

By "personally", I mean that even if you send an initial auto-response, a
receipt, a real human being will follow-up in a timely manner.

AC

Philip Homburg

unread,
Jan 8, 2004, 11:39:08 AM1/8/04
to
In article <56ca06ef.04010...@posting.google.com>,

Maybe you should be a bit more specific. I don't get a lot of mail from
northgrum.com or csi-corp.com so I don't know what they are doing.

Note that SMTP does not support the concept of host authentication
(other than SMTP AUTH), so you may want to check (and cite in this group)
chapter and verse of the RFCs that you are trying to implement.

Expecting someone to do something that is not documented is not very
productive. Unfortunately for you, the RFCs are very specific about the
checks that receiver is not supposed to do.

--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr

Jonathan de Boyne Pollard

unread,
Jan 10, 2004, 10:29:32 PM1/10/04
to
JdeBP> What is your reason for thinking that they are "bogus" ?
JdeBP> Are they syntactically incorrect ? Or is your SMTP Relay
JdeBP> server trying to actually derive a meaning from them in
JdeBP> some fashion (which is at best a poor idea) ?

AC> Expecting someone to identify themselves properly, to use
AC> their "real name" is a "poor idea"?

Your question is not a paraphrase of what I have written. The "HELO" command
has nothing to do with an SMTP Relay client identifying itself "properly".
You are mischaracterising the command in order to create a straw man. The
client is identified by its IP address. The actual purpose of the parameter
to the "HELO" command was to detect loops, where an MTS ends up talking to
itself. (For that purpose, it is not necessary that the string be "proper",
whatever that may mean, only that it be guaranteed to be unique to a single
MTS.) This mechanism is insufficient for handling the common cases of MTSes
where the SMTP Relay server and SMTP Relay client are separate from each
other, and has largely been superceded by the "MX" list truncation mechanism,
where the SMTP Relay client, rather than the SMTP Relay server, has the
responsibility for detecting and avoiding such loops.

RFCs 821 and 1123 are both clear that deriving a meaning from the domain
parameter of a "HELO" command is at best a poor idea. In practice, about the
only thing that an SMTP Relay client can do with it is stuff it in a
"Received:" header. (The "MUST" requirements in RFC 2821 are unworkable in
practice, and constitute a deficiency in that RFC.)

Alan Connor

unread,
Jan 11, 2004, 12:58:34 AM1/11/04
to

Very interesting. I appreciate you taking the time to educate me, Jonathan.

Comment withdrawn.

AC

Mark Crispin

unread,
Jan 11, 2004, 3:30:59 PM1/11/04
to
On Sun, 11 Jan 2004, Jonathan de Boyne Pollard wrote:
> The actual purpose of the parameter
> to the "HELO" command was to detect loops, where an MTS ends up talking to
> itself.

In particular, this was to correct a problem on the old (pre-1983)
NCP-based ARPAnet. NCP had no equivalent to IP; instead, the ARPAnet's
1822 (the equivalent of Ethernet Mac level) was used. It also helps to
understand that ARPAnet used hubs called IMPs. The IMPs were the only
machines on the ARPAnet; all other machines connected to IMPs and 1822 was
the interface between IMP and host via an electrical interface which looks
charmingly primitive by today's standards. A "host on the ARPAnet" was
thus more akin to a human using a telephone being "on the telephone
network" rather than networking as we think of it today.

Periodically, a host's port on the IMP was put into loopback mode. This
could be done in one of several ways. The effect was that, at the
"hardware" level, any packet that was sent to that port on that IMP would
be returned to the sender as if it came from that port on that IMP.

Thus, if you connected to a server on an ARPAnet address that was in
loopback, you would get your own server. What's more, the server would
think that it's serving a client at that other end.

In the pre-SMTP days, mail was conveyed via FTP. There was a MAIL command
which took a single recipient as an argument and then behaved like the
SMTP DATA command; and an MLFL command which used an external FTP data
connection. There was no equivalent of HELO, MAIL FROM, etc. There were
extensions to do multiple recipients, but they weren't widely implemented,
so you often had to do a separate session per recipient.

It's not difficult to see how a loop would develop. It was at times a
*HUGE* problem. SMTP was a reaction to all of this.

The loop problem went away with TCP/IP, and SMTP's solution with HELO thus
became unnecessary. The introduction of a real network layer (IP) instead
of just letting the hardware do the network layer brought an end to
"mirrors" due to hardware loopback. However, there was a thought that
maybe someday it would be necessary to depend upon HELO loop detection
again, so HELO was left in SMTP. The introduction of DNS gave that
argument some credence.

Judging from the number of SMTP servers which happily accept HELO of their
own name (and as spammers have discovered, sometimes this puts the SMTP
server into "trusted client, can relay" mode), it's doubtful that SMTP
loop detection has worked in a useful fashion for 20 years.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Kari Hurtta

unread,
Jan 11, 2004, 4:45:17 PM1/11/04
to
Mark Crispin <m...@CAC.Washington.EDU> writes in comp.mail.misc:

> Judging from the number of SMTP servers which happily accept HELO of their
> own name (and as spammers have discovered, sometimes this puts the SMTP
> server into "trusted client, can relay" mode), it's doubtful that SMTP
> loop detection has worked in a useful fashion for 20 years.

My impression is that sendmail is done that ( ie lookin hostname given
on HELO command) for loop detection, but on some time ago shifted to
do loop detection on smtp client (ie. looking hostname given
on smtp server's banner).

Probably:


8.6/8.6 1993/10/05
<...>
Relax check of name on HELO packet so that a program using -bs
that claims to be itself works properly.


If it is that, it is only 10 years ago, not 20 years ago.

/ Kari Hurtta

Mark Crispin

unread,
Jan 11, 2004, 7:31:24 PM1/11/04
to
On Sun, 11 Jan 2004, Mark Crispin wrote:
> In particular, this was to correct a problem on the old (pre-1983)
> NCP-based ARPAnet. NCP had no equivalent to IP; instead, the ARPAnet's
> 1822 (the equivalent of Ethernet Mac level) was used. It also helps to
> understand that ARPAnet used hubs called IMPs. The IMPs were the only
> machines on the ARPAnet; all other machines connected to IMPs and 1822 was
> the interface between IMP and host via an electrical interface which looks
> charmingly primitive by today's standards.

I forgot to mention an important detail about the IMPs, which helps to
understand why looping was such a problem in 1822/NCP days.

There were three low-level protocols on the ARPAnet: IMP-IMP, IMP-host,
and host-IMP. IMP-IMP was the closest to IP in that it had both source
and destination address, but only the IMPs ever saw it and access was
strictly regulated by the Network Control Center at BBN.

The IMP-host and host-IMP protocols only had a "remote host" field in the
message. That is, the IMP-host protocol had a source host, and the
host-IMP protocol had a destination host. To make matters worse, these
two protocols were in the same format.

Hence, a message *from* host 3 on IMP 11 in the IMP-host protocol was
identical to the equivalent message *to* host 3 on IMP 11 in the host-IMP
protocol. So, when the wire carrying IMP-host protocol was shorted to the
wire carrying host-IMP protocol, you had loopback. It was impossible to
detect it at the other end.

TCP/IP does not have this problem, because IP datagrams carry both a
"source host" and a "destination host". Unlike 1822, IP has no separate
protocol for incoming datagrams, outgoing datagrams, and in-transit
datagrams.

The amusing part about all of this is that FTP-based mail did not die
until after the TCP/IP transition on January 1, 1983. Although SMTP based
mail started to become generally available in 1982, the bulk of all email
was FTP based. What little SMTP existed prior to the transition was over
TCP/IP; SMTP over NCP was experimental only.

Thus, SMTP's fix to the loopback problem happened after it was no longer
needed! :-)

Besides HELO, another SMTP improvement was that unlike FTP mail, SMTP was
carefully designed to relay, something that undoubtably bewilders people
today in this age of spam! But that's another story...

David F. Skoll

unread,
Jan 11, 2004, 11:38:47 PM1/11/04
to
Mark Crispin wrote:

[Quite fascinating history of the Internet]

> Judging from the number of SMTP servers which happily accept HELO of their
> own name (and as spammers have discovered, sometimes this puts the SMTP
> server into "trusted client, can relay" mode), it's doubtful that SMTP
> loop detection has worked in a useful fashion for 20 years.

I have a fair bit of empirical evidence that some spamware connects to
my server (roaringpenguin.com) and identifies itself as
"roaringpenguin.com" in the HELO/EHLO command.

Although the RFC's say that you shouldn't reject a connection based on
HELO/EHLO, if you're doing content filtering, I don't think it's unreasonable
to consider the HELO/EHLO argument content and filter on it. You need
to do it very carefully, but the specific case of random machines identifying
themselves as "roaringpenguin.com" is an extremely reliable way for me to
detect and block spam.

Regards,

David.

Jem Berkes

unread,
Jan 11, 2004, 11:42:13 PM1/11/04
to
> I have a fair bit of empirical evidence that some spamware connects to
> my server (roaringpenguin.com) and identifies itself as
> "roaringpenguin.com" in the HELO/EHLO command.

I get something similar... in my case, several connecting spammers do a
HELO with my IP address as if it were their host name! Silly spammers...

Jonathan de Boyne Pollard

unread,
Jan 11, 2004, 8:24:03 PM1/11/04
to
JdeBP> In practice, about the only thing that an SMTP Relay client
JdeBP> can do with it is stuff it in a "Received:" header.

Aaargh!

1s/client/server/

those who know me have no need of my name

unread,
Jan 12, 2004, 12:44:09 AM1/12/04
to
in comp.mail.misc i read:

>I have a fair bit of empirical evidence that some spamware connects to
>my server (roaringpenguin.com) and identifies itself as
>"roaringpenguin.com" in the HELO/EHLO command.

unfortunately this also happens with some very common mua's, i.e., outlook
express can do this if the host's configuration is set in a way that is all
too common.

--
a signature

Alan Connor

unread,
Jan 12, 2004, 1:02:11 AM1/12/04
to
a
:-) You use ed too? I love it.


AC

Mark Crispin

unread,
Jan 12, 2004, 5:57:34 AM1/12/04
to
On Sun, 11 Jan 2004, David F. Skoll wrote:
> I have a fair bit of empirical evidence that some spamware connects to
> my server (roaringpenguin.com) and identifies itself as
> "roaringpenguin.com" in the HELO/EHLO command.

Indeed. And given that you have an MX for roaringpenguin.com of
www.roaringpenguin.com I'll wager that you see a fair number of instances
of SMTP clients that identify themselves as "www.roaringpenguin.com" in
the HELO/EHLO command.

> Although the RFC's say that you shouldn't reject a connection based on
> HELO/EHLO, if you're doing content filtering, I don't think it's unreasonable
> to consider the HELO/EHLO argument content and filter on it.

I always felt that that statement in the RFCs was an over-reaction, even
when it was first made. Its original purpose was to prohibit the behavior
of a particular implementation which rejected any HELO with a name that
was not in the SMTP server's host table (yes, this predated DNS) and/or
did not match the address in the host table. Thus, that server did not
accept "FOO-BAR is now on the net at 10.7.0.69, please update your host
tables" messages from new hosts or hosts which changed their net address.

Such email messages were a quaint way of distributed database management
which is now remembered only by a few. Needless to say, it ceased to
scale 20 years ago, hence leading to the advent of the DNS.

Anyway, the author of that implementation complained bitterly that nobody
warned him of this consequence, and thus the specification was updated to
add a prohibition of that and all similar behavior. That pattern of
tragi-comedy, at least, continues to happen to this day... :-)

> You need
> to do it very carefully, but the specific case of random machines identifying
> themselves as "roaringpenguin.com" is an extremely reliable way for me to
> detect and block spam.

The same should be done for your www.roaringpenguin.com MX as well. I've
seen spammers use both my domain name and its MX relay name.

My SMTP server implementations have always rejected such HELOs. In the
early 1980s it was for loopback protection; today it's to block a
particular form of spam. Nobody ever complained.

D. Stussy

unread,
Jan 12, 2004, 6:15:29 AM1/12/04
to

True, but there is one check (which is technically "non-RFC") which is
permitted: If a site claims to be YOU and it is not you, then you may refuse
the mail. Otherwise, any syntactically valid hostname (including a bracketed
domain IP-address literal) must be accepted and you may NOT refuse the
connection based on that criterion alone.

those who know me have no need of my name

unread,
Jan 12, 2004, 8:15:53 AM1/12/04
to
in comp.mail.misc i read:

>On Wed, 7 Jan 2004, those who know me have no need of my name wrote:
>> in comp.mail.misc i read:

>> >The following companys' mail servers are using bogus HELO/EHLO host
>> >names when sending emails. What is their reason for doing so?
>>
>> these names are not required to be `valid' from your point of view.
>
>True, but there is one check (which is technically "non-RFC") which is
>permitted: If a site claims to be YOU and it is not you, then you may
>refuse the mail.

hmm. if i'm remembering correctly the rfc's make no mention of this
exception, hence the `must not' (refuse so long as the argument is
formatted properly) is still effective.

putting that aside, one should still merely document the helo/ehlo used and
go on with the transaction, especially if only a hostname is given and it
happens to match the mta's -- two mta's whose names are the same is not
terribly unusual; mail and smtp are probably rampant. (the days when loops
could happen are mostly gone and that was it's only real purpose, but back
then no two hosts could have the same hostname because the nic managed the
hosts file and much grief would come about with two entries with different
addresses, which sorts of things did happen hence the need for the nic.)

and as i've mentioned else-thread it's not impossible for various mua's to
mistakenly use the hostname or domain name of the target server (or other
things which seem improbable or `lies', e.g., `localhost') when they greet
the mta, it's not only spammers which do it (spammers learned by watching,
more or less).

>Otherwise, any syntactically valid hostname (including a bracketed
>domain IP-address literal) must be accepted and you may NOT refuse the
>connection based on that criterion alone.

yes. it's sad that so many seem to feel otherwise.

--
a signature

David F. Skoll

unread,
Jan 12, 2004, 8:35:00 AM1/12/04
to
those who know me have no need of my name wrote:

> unfortunately this also happens with some very common mua's, i.e., outlook
> express can do this if the host's configuration is set in a way that is
> all too common.

I should have mentioned that the server I do the HELO/EHLO checks on is
not intended for use by MUAs. It's only for inbound mail for our domain.

--
David.

David F. Skoll

unread,
Jan 12, 2004, 8:38:41 AM1/12/04
to
Mark Crispin wrote:

> Indeed. And given that you have an MX for roaringpenguin.com of
> www.roaringpenguin.com I'll wager that you see a fair number of instances
> of SMTP clients that identify themselves as "www.roaringpenguin.com" in
> the HELO/EHLO command.

Yes. In fact, my filter checks for _anything_ ending in "roaringpenguin.com",
as well as something who identifies itself as "209.195.84.23" (my machine's
IP address.)

--
David.

Jem Berkes

unread,
Jan 12, 2004, 9:58:03 AM1/12/04
to
>> >The following companys' mail servers are using bogus HELO/EHLO host
>> >names when sending emails. What is their reason for doing so?
>>
>> these names are not required to be `valid' from your point of view.
>
> True, but there is one check (which is technically "non-RFC") which is
> permitted: If a site claims to be YOU and it is not you, then you may
> refuse the mail. Otherwise, any syntactically valid hostname
> (including a bracketed domain IP-address literal) must be accepted and
> you may NOT refuse the connection based on that criterion alone.

I wouldn't worry too much about being non-RFC compliant. If you have some
reason for blocking mail traffic, do so! You're only losing your own mail
if you make a bad filtering decision.

Do you know how many sites block my mail because I'm on a DSL connection?
You show me one RFC or other core specification that tells me you should
discriminate TCP/IP connections by end-link technology and I'll show you
one engineer who has severely misunderstood the IP, TCP, and SMTP
protocols.

D. Stussy

unread,
Jan 12, 2004, 12:59:33 PM1/12/04
to
On Mon, 12 Jan 2004, those who know me have no need of my name wrote:
> in comp.mail.misc i read:
> >On Wed, 7 Jan 2004, those who know me have no need of my name wrote:
> >> in comp.mail.misc i read:
>
> >> >The following companys' mail servers are using bogus HELO/EHLO host
> >> >names when sending emails. What is their reason for doing so?
> >>
> >> these names are not required to be `valid' from your point of view.
> >
> >True, but there is one check (which is technically "non-RFC") which is
> >permitted: If a site claims to be YOU and it is not you, then you may
> >refuse the mail.
>
> hmm. if i'm remembering correctly the rfc's make no mention of this
> exception, hence the `must not' (refuse so long as the argument is
> formatted properly) is still effective.

That's why I said it's non-RFC. However, it is not unreasonable for a server to
know that it's connecting to ITSELF.... Remember that you're not refusing the
mail SOLELY on the HELO hostname, but on the combination of that hostname and
the incoming IP address not being yours.

> putting that aside, one should still merely document the helo/ehlo used and
> go on with the transaction, especially if only a hostname is given and it
> happens to match the mta's -- two mta's whose names are the same is not
> terribly unusual; mail and smtp are probably rampant. (the days when loops
> could happen are mostly gone and that was it's only real purpose, but back
> then no two hosts could have the same hostname because the nic managed the
> hosts file and much grief would come about with two entries with different
> addresses, which sorts of things did happen hence the need for the nic.)

Although there may be cases where multiple physical machines act as a single
virtual server by sharing a domain name (but have different IP addresses; the
DNS having multiple A/AAAA/A6 records, etc), I know of no case where under
normal operations, one of the physical machines in the virtual collective would
connect (or need to) via SMTP to another in the same collective.

> and as i've mentioned else-thread it's not impossible for various mua's to
> mistakenly use the hostname or domain name of the target server (or other
> things which seem improbable or `lies', e.g., `localhost') when they greet
> the mta, it's not only spammers which do it (spammers learned by watching,
> more or less).

Spammers learn? :-)

A system that is using the hostname of the target is misconfigured.

Jonathan de Boyne Pollard

unread,
Jan 13, 2004, 9:12:28 AM1/13/04
to
JdeBP> Aaargh!
JdeBP>
JdeBP> 1s/client/server/

AC> :-) You use ed too?

No.

<URL:http://catb.org./~esr/jargon/html/writing-style.html>

Jonathan de Boyne Pollard

unread,
Jan 22, 2004, 8:47:24 PM1/22/04
to
DFS> Although the RFC's say that you shouldn't reject a connection
DFS> based on HELO/EHLO, if you're doing content filtering, I don't
DFS> think it's unreasonable to consider the HELO/EHLO argument
DFS> content and filter on it.

But it's important to remember, whilst doing so, that

* one isn't rejecting clients because they are violating the protocol (since
they aren't), one is just rejecting clients because of a statistical
correlation between clients performing undesirable transations and a
particular use of a particular command in the protocol

and that

* that correlation can vanish at any time ("good" clients start using the
protocol in the same way, or "bad" clients stop using the protocol in this
way).

This is, of course, the same fundamental flaw as with other anti-UBM systems.
The design incorporates looking for some element, that is common to some
number of unsolicited bulk mail messages but that is not actually directly
related to their undesirable "unsolicited" and "bulk" qualities, and blocking
all messages with that element, unsolicited bulk ones or no.

Jonathan de Boyne Pollard

unread,
Jan 22, 2004, 8:07:35 PM1/22/04
to
MC> Judging from the number of SMTP servers which happily accept
MC> HELO of their own name (and as spammers have discovered,
MC> sometimes this puts the SMTP server into "trusted client,
MC> can relay" mode), [...]

Good grief! The Brigade has obviously been at work again.

MC> [...] it's doubtful that SMTP loop detection [using "HELO"]
MC> has worked in a useful fashion for 20 years.

So of the two purposes that "HELO" serves in the protocol, one is in practice
obsolete and the other (checking that the state machine is in its initial
state) is of dubious utility given the kinds of reliable sequenced transport
protocols that SMTP is almost always layered on top of.

Mark Crispin

unread,
Jan 23, 2004, 12:48:12 AM1/23/04
to
On Fri, 23 Jan 2004, Jonathan de Boyne Pollard wrote:
> So of the two purposes that "HELO" serves in the protocol, one is in practice
> obsolete and the other (checking that the state machine is in its initial
> state) is of dubious utility given the kinds of reliable sequenced transport
> protocols that SMTP is almost always layered on top of.

That's a fair statement.

While we're talking about ancient history, I should mention something
about the latter purpose (checking that the state machine is in its
initial state). There was a bug in an early TCP in which left over data
from a previous use of a pseudo-terminal would remain in the
pseudo-terminal's input buffer and appear as input to a new process just
starting up on the pseudo-terminal.

I remember that bug quite well. I was the author of the SMTP server on
that system. At that time, SMTP sessions ran on a pseudo-terminal
(because it was easier that way, that's why). So, to be safe, my SMTP
server had to clear the input buffer at startup.

Other SMTP server must have had the same problem; that "state machine in
initial state" stuff was already in the SMTP specification when I wrote my
server.

Needless to say, my server's clearing its input buffer at startup was not
popular -- even then there were experiments with batch-SMTP.

All ended up well in the end. The bug in TCP pseudo-terminals was fixed,
but more importantly my server switched from pseudo-terminals to that OS'
equivalent of pipes, so the input buffer clear became superfluous and was
removed. Also pipes are *much* faster than pseudo-terminals!

I'm amazed that I still remember this. This was all over 20 years ago.

For all intents and purposes, the sole purpose of HELO today is to put
some additional trace crud into Received headers. EHLO, on the other
hand, has the equivalent of CAPA or CAPABILITY in other protocols and
actually has some use.

Ben Finney

unread,
Jan 23, 2004, 12:51:34 AM1/23/04
to
On Thu, 22 Jan 2004 21:48:12 -0800, Mark Crispin wrote:
> While we're talking about ancient history [...]

> I'm amazed that I still remember this. This was all over 20 years
> ago.

Thanks for this story. It's always useful to see, even anecdotally, how
standards and protocols evolve over time.

--
\ "For mad scientists who keep brains in jars, here's a tip: why |
`\ not add a slice of lemon to each jar, for freshness?" -- Jack |
_o__) Handey |
Ben Finney <http://bignose.squidly.org/>

David F. Skoll

unread,
Jan 23, 2004, 8:20:20 AM1/23/04
to
Jonathan de Boyne Pollard wrote:

> DFS> Although the RFC's say that you shouldn't reject a connection
> DFS> based on HELO/EHLO, if you're doing content filtering, I don't
> DFS> think it's unreasonable to consider the HELO/EHLO argument
> DFS> content and filter on it.

> But it's important to remember, whilst doing so, that

> * one isn't rejecting clients because they are violating the protocol
> (since they aren't), one is just rejecting clients because of a
> statistical correlation between clients performing undesirable transations
> and a particular use of a particular command in the protocol

Right. But that's no worse than content filtering.

> and that

> * that correlation can vanish at any time ("good" clients start using the
> protocol in the same way, or "bad" clients stop using the protocol in this
> way).

If the correlation vanishes, it is likely to vanish in the less-dangerous
direction: It's far more likely that "bad" clients will catch on and
stop using the protocol in that way, than "good" clients will suddenly
start behaving "badly".

> This is, of course, the same fundamental flaw as with other anti-UBM
> systems. The design incorporates looking for some element, that is common
> to some number of unsolicited bulk mail messages but that is not actually
> directly related to their undesirable "unsolicited" and "bulk" qualities,
> and blocking all messages with that element, unsolicited bulk ones or no.

Those are the facts of life. :-(

Regards,

David.

Jonathan de Boyne Pollard

unread,
Jan 23, 2004, 2:57:08 PM1/23/04
to
MC> For all intents and purposes, the sole purpose of HELO today
MC> is to put some additional trace crud into Received headers.
MC> EHLO, on the other hand, has the equivalent of CAPA or
MC> CAPABILITY in other protocols and actually has some use.

I agree. I wrote pretty much the same thing in
<URL:news://news.gmane.org./4004B180...@Tesco.NET>, with the additional
comment that in an ideal world no SMTP Relay server would require the use of
"EHLO" by an SMTP Relay client that didn't desire any service extensions.

Jonathan de Boyne Pollard

unread,
Jan 23, 2004, 9:56:38 PM1/23/04
to
JdeBP> But it's important to remember, whilst doing so, that
JdeBP>
JdeBP> * one isn't rejecting clients because they are violating
JdeBP> the protocol (since they aren't), one is just rejecting
JdeBP> clients because of a statistical correlation between
JdeBP> clients performing undesirable transations and a particular
JdeBP> use of a particular command in the protocol

DFS> Right. But that's no worse than content filtering.

It's not a question of which is better or worse. It is a question of why one
is performing the rejection. Rejecting because of a protocol violation is one
thing. But rejecting because of a statistical correlation between a
particular _valid_ datum and undesirable clients is another. All too often,
people conflate the two, forgetting that the rejection criterion is merely
derived from a statistical correlation and that the datum being tested is
_actually valid_, and start erroneously labelling their rejection criteria.

For example: People start talking about such things as there being "broken
reverse DNS lookup" when there is no address->name mapping for an SMTP Relay
client; when in fact there is no requirement that all IP addresses map to
domain names and this is a perfectly valid situation for an IP address (and in
fact is the case for vast swathes of the IP address space), and all that there
actually is is a statistical correlation (and not even a complete one, at
that) between such valid setups and SMTP Relay clients that initiate
undesirable transactions. The reverse lookup is not "broken".

JdeBP> and that
JdeBP>
JdeBP> * that correlation can vanish at any time ("good" clients
JdeBP> start using the protocol in the same way, or "bad" clients
JdeBP> stop using the protocol in this way).

DFS> If the correlation vanishes, it is likely to vanish in the
DFS> less-dangerous direction: It's far more likely that "bad"
DFS> clients will catch on and stop using the protocol in that
DFS> way, than "good" clients will suddenly start behaving "badly".

As has already been pointed out, what you consider to be the unlikely case
already happens. "good" clients exist that can use the protocol in exactly
this way.

Jonathan de Boyne Pollard

unread,
Jan 23, 2004, 10:46:58 PM1/23/04
to
DS> However, it is not unreasonable for a server to know that
DS> it's connecting to ITSELF.... Remember that you're not
DS> refusing the mail SOLELY on the HELO hostname, but on the
DS> combination of that hostname and the incoming IP address
DS> not being yours.

In modern SMTP Relay systems, the onus of avoiding loops is on the _client_,
not on the server. Loop prevention is done by "MX" list truncation.

Mark Crispin

unread,
Jan 24, 2004, 3:11:55 AM1/24/04
to
On Sat, 24 Jan 2004, Jonathan de Boyne Pollard wrote:
> In modern SMTP Relay systems, the onus of avoiding loops is on the _client_,
> not on the server. Loop prevention is done by "MX" list truncation.

The same was true of historic SMTP relay systems as well.

Kari Hurtta

unread,
Jan 24, 2004, 6:08:25 AM1/24/04
to

That alone do NOT prevent loops.

There is very many MX lists which best value points to name which
have address 127.0.0.1 or 0.0.0.0

/ Kari Hurtta

Jonathan de Boyne Pollard

unread,
Jan 24, 2004, 7:52:43 AM1/24/04
to
DS> However, it is not unreasonable for a server to know that
DS> it's connecting to ITSELF.... Remember that you're not
DS> refusing the mail SOLELY on the HELO hostname, but on the
DS> combination of that hostname and the incoming IP address
DS> not being yours.

JdeBP> In modern SMTP Relay systems, the onus of avoiding loops
JdeBP> is on the _client_, not on the server. Loop prevention
JdeBP> is done by "MX" list truncation.

KH> That alone do NOT prevent loops.

Your counterexample is false.

KH> There is very many MX lists which best value points to name
KH> which have address 127.0.0.1 or 0.0.0.0

This will not cause loops. An SMTP Relay client that is configured
to properly implement RFC 2821 will (if the SMTP Relay server for
that same MTS actually listens on those IP addresses, of course) know
those to be more of its "own" IP addresses and will perform "MX" list
truncation to eliminate both them and any less preferred SMTP Relay
servers.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/qmail-problems.html#local-address-recognition>
<URL:http://www.postfix.org./basic.html>

0 new messages