Mailing List Archive

-----Original Message-----
From: Don Lee [mailto:spfdiscuss@caution.icompute.com]
Sent: zaterdag 5 januari 2008 19:41
To: spf-discuss@v2.listbox.com
Subject: [spf-discuss] SPF adoption - HELO vs FROM

> That scrutiny is forcing server operators to provide RFC-compliant
> HELO data that can in turn be checked with SPF.

The 'problem' with RFC-compliant HELO data is, of course, that,
officially, there's no other requirement than that HELO be a FQDN or an
address literal.

Section 3.6 of RFC 2821 states:

The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.

Nowhere is it written, in RFC-marble, that said HELO name actually
corresponds
with the connecting IP address. It makes a great deal of sense in doing so,
of
course; but the point being, that server operators can supply fully
RFC-compliant HELO data, and still be relatively free in their choice of
HELO
name.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82225035-9503cb
Powered by Listbox: http://www.listbox.com

-----Original Message-----
From: Don Lee [mailto:spfdiscuss@caution.icompute.com]
Sent: zaterdag 5 januari 2008 19:41
To: spf-discuss@v2.listbox.com
Subject: [spf-discuss] SPF adoption - HELO vs FROM

> That scrutiny is forcing server operators to provide RFC-compliant
> HELO data that can in turn be checked with SPF.

The 'problem' with RFC-compliant HELO data is, of course, that,
officially, there's no other requirement than that HELO be a FQDN or an
address literal.

Section 3.6 of RFC 2821 states:

The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.

Nowhere is it written, in RFC-marble, that said HELO name actually
corresponds
with the connecting IP address. It makes a great deal of sense in doing so,
of
course; but the point being, that server operators can supply fully
RFC-compliant HELO data, and still be relatively free in their choice of
HELO
name.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82383751-965d6a
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 11:39 AM, Don Lee <spfdiscuss@caution.icompute.com> wrote:

> I want to remind everyone on the list that we are all pushing for the
> same thing - we want SPF to become a more widely used tool to
> reduce abuse of the e-mail system.
>
> There are two places in the SMTP "stream" where SPF can be useful. One is
>
> at MAIL FROM time when a server can check return addresses. The other is
> at HELO time when servers "greet" one another.


This makes a lot of sense to me, especially if you do the HELO check first.
Then you can reject an entire session, and not bother with checking every
return address a spammer can think of. I would go even further, and when I
see a HELO fail, reject anything from that IP address for the next hour.
That would sure reduce the clutter in my log files.

HELO checking fits right in with a multi-layer strategy. First firewall any
IPs spewing spam, then block any attempt to forge a HELO name, then
depending on the sender's policy, proceed with checking return addresses,
from headers, and content. A bank may tell its customers - we need your
real address, not some forwarded address, and then use SPF -all to enforce
that policy. It could also say it's From header will always match its HELO
name, and it could even call for a DKIM check on the entire message.

>
> The former is the subject of a lot of debate, and has lots of
> complications because there are a lot of people who cling to a lot
> of traditional (bad?) practices. It is clear that changing behaviors
> in these areas is a struggle.
>
> The latter is a much clearer win. Over time HELO data provided by an
> incoming
> server is seeing more authentication scrutiny because it is a useful
> predictor of bad behavior. That scrutiny is forcing server
> operators to provide RFC-compliant HELO data that can in turn be
> checked with SPF. An SPF check on HELO is completely without "false
> positive"
> risk AFAIK because it is checking the HELO name vs. the connecting server
> IP,
> not the desired (or forwarded) identity on the message.


And if there is a false reject, it can be corrected easily and immediately
by the sender, without risking further losses or adding addresses they are
not sure about.


> Let's push harder on the HELO checking. Once done, and in common use,
> we can take the next step of sorting out the obstacles to getting
> SPF used in message identities and return paths.


Good strategy. Do the easy part first. Keep the layers well separated.
Don't let the "forwarding problem" affecting return addresses only,
interfere with efforts to get robust authentication of the HELO name.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82226007-eb539e
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 2:50 PM, Mark <admin@asarian-host.net> wrote:

>
> > That scrutiny is forcing server operators to provide RFC-compliant
> > HELO data that can in turn be checked with SPF.
>
> The 'problem' with RFC-compliant HELO data is, of course, that,
> officially, there's no other requirement than that HELO be a FQDN or an
> address literal.


Which is a good thing, because it gives senders a lot of flexibility to put
whatever they want in that space. Senders who care will make an effort to
use a name which is easily authenticated. Senders who continue to say "HELO
this is Jupiter", we can ignore.

>
>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82230730-74df79
Powered by Listbox: http://www.listbox.com

On Jan 5, 2008 2:50 PM, Mark
<<mailto:admin@asarian-host.net>admin@asarian-host.net> wrote:


> That scrutiny is forcing server operators to provide RFC-compliant
> HELO data that can in turn be checked with SPF.

The 'problem' with RFC-compliant HELO data is, of course, that,
officially, there's no other requirement than that HELO be a FQDN or an
address literal.


Which is a good thing, because it gives senders a lot of flexibility
to put whatever they want in that space. Senders who care will make
an effort to use a name which is easily authenticated. Senders who
continue to say "HELO this is Jupiter", we can ignore.

In my case - "ignore" == "blacklist". For instance, I have a filter on
my mailserver that checks HELO and blacklists any server that provides HELO
of the form -?[0-9]*. (regex - matches "-678243786234" and "12345".)

Very effective. Blocks a lot of spam from bots. I have yet to see a
false positive.

-dgl-

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82236504-37390d
Powered by Listbox: http://www.listbox.com

Mark wrote:
> The 'problem' with RFC-compliant HELO data is, of course, that,
> officially, there's no other requirement than that HELO be a FQDN or an
> address literal.
>
> Section 3.6 of RFC 2821 states:
>
> The domain name given in the EHLO command MUST be either a primary
> host name (a domain name that resolves to an A RR) or, if the host
> has no name, an address literal as described in section 4.1.1.1.
>
> Nowhere is it written, in RFC-marble, that said HELO name actually
> corresponds
> with the connecting IP address. It makes a great deal of sense in doing so,
> of
> course; but the point being, that server operators can supply fully
> RFC-compliant HELO data, and still be relatively free in their choice of
> HELO
> name.

Section 3.2 says, in addition,
In the EHLO command the host sending the command identifies itself

While that isn't a direct link to the IP in use, some people
feel that it isn't unreasonable to require a traceable coupling
between the IP and the HELO via DNS lookups (even if it takes more
than one lookup step) in order to enforce the 3.2 wording.

Cheers,
Jeremy

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82239213-399c58
Powered by Listbox: http://www.listbox.com

Jeremy wrote:

> Section 3.2 says, in addition,

> In the EHLO command the host sending the command identifies itself
>
> While that isn't a direct link to the IP in use, some people
> feel that it isn't unreasonable to require a traceable coupling
> between the IP and the HELO via DNS lookups (even if it takes more
> than one lookup step) in order to enforce the 3.2 wording.

Agreed. But I'd also like to draw your attention to RFC 2821 4.1.4,
Paragraph 6

4.1.4 Order of Commands [paragraph 6]:

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.

The forbidding MUST NOT leaves little room for interpretation.

Don't get me wrong, though, I'm all for HELO checking, and I personally do
a LOT of it. But all under the heading of: "My MTA, my rules." :)

But my 'objections' were more to Don's scrutiny to force server operators
"to provide RFC-compliant HELO data," in the pointing out that when it
comes to RFCs, to-date they still offer more space to maneouvre in than
perhaps we'd like to see.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82248587-9a4350
Powered by Listbox: http://www.listbox.com

Jeremy wrote:

> Section 3.2 says, in addition,

> In the EHLO command the host sending the command identifies itself
>
> While that isn't a direct link to the IP in use, some people
> feel that it isn't unreasonable to require a traceable coupling
> between the IP and the HELO via DNS lookups (even if it takes more
> than one lookup step) in order to enforce the 3.2 wording.

Agreed. But I'd also like to draw your attention to RFC 2821 4.1.4,
Paragraph 6

4.1.4 Order of Commands [paragraph 6]:

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.

The forbidding MUST NOT leaves little room for interpretation.

Don't get me wrong, though, I'm all for HELO checking, and I personally do
a LOT of it. But all under the heading of: "My MTA, my rules." :)

But my 'objections' were more to Don's scrutiny to force server operators
"to provide RFC-compliant HELO data," in the pointing out that when it
comes to RFCs, to-date they still offer more space to maneouvre in than
perhaps we'd like to see.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82382802-bb14ad
Powered by Listbox: http://www.listbox.com

On Sat, Jan 05, 2008 at 09:50:17PM +0000, Mark wrote:

> The 'problem' with RFC-compliant HELO data is, of course, that,
> officially, there's no other requirement than that HELO be a FQDN or an
> address literal.

That's not correct.

4.1.1.1 says:

"The argument field contains the fully-qualified domain name
of the SMTP client if one is available."
^^^^^^^^^^^^^^^^^^

Although it may be hard to verify that the client is lying,
there's plenty of room in RFC2821 to allow rejecting a bad HELO.

What is not allowed ("MUST NOT" in 4.1.4) is rejecting on HELO <<if
this is because the client address and the helo parameter don't
correspond>>. That does *not* say it is forbidden to reject for
other reasons.

Carefully read "...for this reason...", which is about
"...corresponds to...".

Officially, the name which is used as HELO parameter MUST be
"a valid principal host name [...] for its host."
(or an address literal, under certain specific circumstances)

Your statement ignores the 'for its host' part.


If I know that the HELO parameter does not belong to the client host,
I can reject the command and thus any subsequent MAIL FROM command.

The following examples are allowed by RFC 2821:

C = connecting client
S = server connected to

C: HELO something.example
S: 5xy No, you are not something.examle, I am!
(or: I know that host and it's not you!)

C: HELO something.example
S: 5xy According to the SPF policy at something.example, [10.1.2.3] is not authorized to use that name

C: HELO something.example
S: 5xy Something.example does not resolve


The only examples of what is not allowed by 4.1.4 are:

C: HELO something.examle
S: 5xy [10.1.2.3] is not named something.example

C: HELO something.examle
S: 5xy something.example does not resolve to [10.1.2.3]


In other words: the HELO parameter needs to be a name for the host, but
it does not need to be the name of the interface used to connect.


Besides: 821 is the standard, not 2821. And 821 says:
"
In the HELO command the host sending the command identifies
itself; the command may be interpreted as saying "Hello, I am
<domain>".
"

And <domain> is to be read as <FQDN>, not as <ISP> or similar.
"HELO yahoo.com" is not RFC compliant, unless there happens to be
just one mailhost, with a lot of interfaces, having name "yahoo.com".

Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82298693-ef271c
Powered by Listbox: http://www.listbox.com

-----Original Message-----
From: Alex van den Bogaerdt [mailto:alex@ergens.op.het.net]
Sent: zondag 6 januari 2008 1:09
To: spf-discuss@v2.listbox.com
Subject: Re: [spf-discuss] SPF adoption - HELO vs FROM

On Sat, Jan 05, 2008 at 09:50:17PM +0000, Mark wrote:

> > The 'problem' with RFC-compliant HELO data is, of course, that,
> > officially, there's no other requirement than that HELO be a FQDN or
> > an address literal.
>
> That's not correct.
>
> 4.1.1.1 says:
>
> "The argument field contains the fully-qualified domain name
> of the SMTP client if one is available."
> ^^^^^^^^^^^^^^^^^^

Yes, I left that part out. My bad. Obviously, you are not allowed to use
just any FQDN.

> What is not allowed ("MUST NOT" in 4.1.4) is rejecting on HELO
> if this is because the client address and the helo parameter don't
> correspond. That does *not* say it is forbidden to reject for
> other reasons.

Nor did I say that you can never reject on HELO. :) All I said is,
that it doesn't have to correspond to the connecting IP address.

> If I know that the HELO parameter does not belong to the client host,
> I can reject the command and thus any subsequent MAIL FROM command.

Yes, but your examples are perfect cases of where you can determine, with
certainty, that the used HELO name belongs to someone else. When this is
not the case, without the ability to match it against the connecting IP
address, you may find it, like you said, hard to determine whether the
client is lying. So, my point is, that while I fully agree there's enough
instances where you can flat-out reject on a HELO, the reverse, which we
were talking about, namely to authenticate a HELO, is not something which
can reliably be done, sans SPF, when the HELO does not resolve to the IP
address of the connecting client.

C: HELO notsoblatent.example
S: 250 ...Uhm, yeah, you could be; I have no real way of telling. :)

So, effectively, without SPF or other auth mechanism, there is, as
receiver, not a whole lot else you can do except check for FQDN, and of
course weed out the cases where you KNOW the client is lying.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82312592-26ef7b
Powered by Listbox: http://www.listbox.com

-----Original Message-----
From: Alex van den Bogaerdt [mailto:alex@ergens.op.het.net]
Sent: zondag 6 januari 2008 1:09
To: spf-discuss@v2.listbox.com
Subject: Re: [spf-discuss] SPF adoption - HELO vs FROM

On Sat, Jan 05, 2008 at 09:50:17PM +0000, Mark wrote:

> > The 'problem' with RFC-compliant HELO data is, of course, that,
> > officially, there's no other requirement than that HELO be a FQDN or
> > an address literal.
>
> That's not correct.
>
> 4.1.1.1 says:
>
> "The argument field contains the fully-qualified domain name
> of the SMTP client if one is available."
> ^^^^^^^^^^^^^^^^^^

Yes, I left that part out. My bad. Obviously, you are not allowed to use
just any FQDN.

> What is not allowed ("MUST NOT" in 4.1.4) is rejecting on HELO
> if this is because the client address and the helo parameter don't
> correspond. That does *not* say it is forbidden to reject for
> other reasons.

Nor did I say that you can never reject on HELO. :) All I said is,
that it doesn't have to correspond to the connecting IP address.

> If I know that the HELO parameter does not belong to the client host,
> I can reject the command and thus any subsequent MAIL FROM command.

Yes, but your examples are perfect cases of where you can determine, with
certainty, that the used HELO name belongs to someone else. When this is
not the case, without the ability to match it against the connecting IP
address, you may find it, like you said, hard to determine whether the
client is lying. So, my point is, that while I fully agree there's enough
instances where you can flat-out reject on a HELO, the reverse, which we
were talking about, namely to authenticate a HELO, is not something which
can reliably be done, sans SPF, when the HELO does not resolve to the IP
address of the connecting client.

C: HELO notsoblatent.example
S: 250 ...Uhm, yeah, you could be; I have no real way of telling. :)

So, effectively, without SPF or other auth mechanism, there is, as
receiver, not a whole lot else you can do except check for FQDN, and of
course weed out the cases where you KNOW the client is lying.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82369206-33eadb
Powered by Listbox: http://www.listbox.com

On Sun, Jan 06, 2008 at 12:59:09AM +0000, Mark wrote:

> Nor did I say that you can never reject on HELO. :) All I said is,
> that it doesn't have to correspond to the connecting IP address.

I'm sure you ment well, but what you said was:

> > > The 'problem' with RFC-compliant HELO data is, of course, that,
> > > officially, there's no other requirement than that HELO be a FQDN or
> > > an address literal.

which is simply not true, not even close. You may understand the
fine points, but others are reading this list too. And they interpret
"a FQDN" as "a (semi-random) FQDN", not as "the FQDN of the host".

cheers
Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82317408-5d141c
Powered by Listbox: http://www.listbox.com

>Jeremy wrote:
>
>> Section 3.2 says, in addition,
>
>> In the EHLO command the host sending the command identifies itself
>>
>> While that isn't a direct link to the IP in use, some people
>> feel that it isn't unreasonable to require a traceable coupling
>> between the IP and the HELO via DNS lookups (even if it takes more
>> than one lookup step) in order to enforce the 3.2 wording.
>
>Agreed. But I'd also like to draw your attention to RFC 2821 4.1.4,
>Paragraph 6
>
>4.1.4 Order of Commands [paragraph 6]:
>
> 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.
>
>The forbidding MUST NOT leaves little room for interpretation.
>
>Don't get me wrong, though, I'm all for HELO checking, and I personally do
>a LOT of it. But all under the heading of: "My MTA, my rules." :)
>
>But my 'objections' were more to Don's scrutiny to force server operators
>"to provide RFC-compliant HELO data," in the pointing out that when it
>comes to RFCs, to-date they still offer more space to maneouvre in than
>perhaps we'd like to see.
>
>- Mark

In the broad scheme of things, this would be very high on my list of things
to change. The RFCs should, IMHO, require a traceable HELO/EHLO for
server "greeting". It is already that way de-facto by virtue of the
checking on HELO that most servers already do for anti-spam.

The "MUST NOT refuse" verbiage should just be removed.

Is there a legitimate reason to maintain this particular "room to
maneuver" for HELO? It seems little more to me than a hole in the
standard that leaves elbow room for the malicious and the incompetent.

-dgl-

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82340500-fdf27d
Powered by Listbox: http://www.listbox.com

Alex wrote:

> > On Sat, Jan 05, 2008 at 09:50:17PM +0000, Mark wrote:

> > The 'problem' with RFC-compliant HELO data is, of course, that,
> > officially, there's no other requirement than that HELO be a FQDN
> > or an address literal.
>
> That's not correct.
>
> Officially, the name which is used as HELO parameter MUST be "a valid
> principal host name [...] for its host." (or an address literal,
> under certain specific circumstances)
>
> Your statement ignores the 'for its host' part.

Well, my statement, to be precise, was a from-memory paraphrase of RFC
2821, Section 3.6 Domains, which reads:

- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.

The 'for its host' part is the language of 4.1.4 Order of Commands:

- 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. (...)

(last caps mine). Of course, we both agree that it MUST be a principal
host name for its host, so the point is somewhat moot. :) In fact, the
language of 3.6, "if the host has no name" already hints to the same. The
problem, however, remains the next paragraph:

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

Though it's near treading on the realm of semantics, in the strictest
sense you could say RFC 2821, stating that HELO, if possible, MUST be a
valid principal host name for its host, leaves not much room. However, the
text of 4.1.4, at the same time, robs us of an important way to verify a
correspondence to the connecting IP address (or, rather, robs us of the
option to reject for that reason). So, where does that leave us? In the
somewhat awkward position that, the gnashing of the teeth despite, when
someone comes along and asks whether they are, by RFC, allowed to reject a
HELO name when no correspondence to the connection IP address can be
established, we'd have to say no. So, effectively, yes, there's room for
spammers to move in. A spammer could, for instance, use a very low-key,
'karma'-neutral FQDN for HELO, one that has not been blacklisted anywhere,
and for which no SPF record is published yet, and which is not obviously
not his.

Don wrote:

> In the broad scheme of things, this would be very high on my list of
> things to change. The RFCs should, IMHO, require a traceable
> HELO/EHLO for server "greeting". It is already that way de-facto by
> virtue of the checking on HELO that most servers already do for
> anti-spam.
>
> The "MUST NOT refuse" verbiage should just be removed.

That alone, I fear, wouldn't cut it. Inherent in the language "MUST be a
valid principal host name for its host," is buried the inability of
reliably tying said principal host name to the connecting client. Maybe
something like:

"MUST be a valid principal host name that corresponds to the IP address of
the connecting client."

It may be a while, though, before the powers that be are willing to make
such changes. :) In the meantime, we can all just publish SPF records for
our HELO names, too. I'm seeing in my logs a larger amount of "none" for
HELO names than for MFROM domains. Not sure what that means, exactly.
Maybe folks forgot to set up SPF records for their HELO names as well? At
any rate, the more HELO can be verified the better, of course.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82352402-23fab4
Powered by Listbox: http://www.listbox.com

Alex wrote:

> > On Sat, Jan 05, 2008 at 09:50:17PM +0000, Mark wrote:

> > The 'problem' with RFC-compliant HELO data is, of course, that,
> > officially, there's no other requirement than that HELO be a FQDN
> > or an address literal.
>
> That's not correct.
>
> Officially, the name which is used as HELO parameter MUST be "a valid
> principal host name [...] for its host." (or an address literal,
> under certain specific circumstances)
>
> Your statement ignores the 'for its host' part.

Well, my statement, to be precise, was a from-memory paraphrase of RFC
2821, Section 3.6 Domains, which reads:

- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.

The 'for its host' part is the language of 4.1.4 Order of Commands:

- 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. (...)

(last caps mine). Of course, we both agree that it MUST be a principal
host name for its host, so the point is somewhat moot. :) In fact, the
language of 3.6, "if the host has no name" already hints to the same. The
problem, however, remains the next paragraph:

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

Though it's near treading on the realm of semantics, in the strictest
sense you could say RFC 2821, stating that HELO, if possible, MUST be a
valid principal host name for its host, leaves not much room. However, the
text of 4.1.4, at the same time, robs us of an important way to verify a
correspondence to the connecting IP address (or, rather, robs us of the
option to reject for that reason). So, where does that leave us? In the
somewhat awkward position that, the gnashing of the teeth despite, when
someone comes along and asks whether they are, by RFC, allowed to reject a
HELO name when no correspondence to the connection IP address can be
established, we'd have to say no. So, effectively, yes, there's room for
spammers to move in. A spammer could, for instance, use a very low-key,
'karma'-neutral FQDN for HELO, one that has not been blacklisted anywhere,
and for which no SPF record is published yet, and which is not obviously
not his.

Don wrote:

> In the broad scheme of things, this would be very high on my list of
> things to change. The RFCs should, IMHO, require a traceable
> HELO/EHLO for server "greeting". It is already that way de-facto by
> virtue of the checking on HELO that most servers already do for
> anti-spam.
>
> The "MUST NOT refuse" verbiage should just be removed.

That alone, I fear, wouldn't cut it. Inherent in the language "MUST be a
valid principal host name for its host," is buried the inability of
reliably tying said principal host name to the connecting client. Maybe
something like:

"MUST be a valid principal host name that corresponds to the IP address of
the connecting client."

It may be a while, though, before the powers that be are willing to make
such changes. :) In the meantime, we can all just publish SPF records for
our HELO names, too. I'm seeing in my logs a larger amount of "none" for
HELO names than for MFROM domains. Not sure what that means, exactly.
Maybe folks forgot to set up SPF records for their HELO names as well? At
any rate, the more HELO can be verified the better, of course.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82363755-2742c0
Powered by Listbox: http://www.listbox.com

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

Don wrote:
> In the broad scheme of things, this would be very high on my list of
> things to change. The RFCs should, IMHO, require a traceable
> HELO/EHLO for server "greeting". It is already that way de-facto by
> virtue of the checking on HELO that most servers already do for
> anti-spam.
>
> The "MUST NOT refuse" verbiage should just be removed.

In reality it doesn't matter, because receivers are already rejecting for
all kinds of reasons, RFC compliant or not.

Mark wrote:
> In the meantime, we can all just publish SPF records for our HELO names,
> too. I'm seeing in my logs a larger amount of "none" for HELO names than
> for MFROM domains. Not sure what that means, exactly. Maybe folks forgot
> to set up SPF records for their HELO names as well? At any rate, the
> more HELO can be verified the better, of course.

I also get more HELO "None"s than MFROM "None"s (about 8% more), but then
I get 15% more HELO "Pass"es than MFROM "Pass"es! (The rest is "Fail",
"SoftFail", and "Neutral", all of which I get far more often with MFROM
than with HELO -- those are NOT false positives, though, as far as I can
see.)

My mail stream is far from being representative, of course.

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

iD8DBQFHgLmNwL7PKlBZWjsRAk8ZAJ0YymEwhaVtCv68MTT3ekDvzqAmlgCfWrF6
wljInktpklAh6zblHOdE6tQ=
=flf6
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82355037-f0006d
Powered by Listbox: http://www.listbox.com