Mailing List Archive

On Mon, 5 Jan 2009, Don Lee wrote:

> Where do we stand with SPF usage on HELO/EHLO?
>
> The establishment of "capitol" out there in the net in the
> form of the thousands of domains that publish SPF records
> may or may not be used to check MAIL FROM: but can most
> certainly be used to check HELO/EHLO. Yet, I am still
> getting static when I bring this up in other forums.
> ("SPF breaks forwarding... blah blah")
>
> Using SPF on HELO/EHLO is a straightforward and effective way
> to prevent forgery of MTA identity, and though not directly
> effective in suppressing SPAM, it's a vital pre-requisite to
> reputation scoring of MTAs.
>
> Is there evidence of progress on this front?

I have always rejected any message HELO has an SPF record and
fails to get PASS. Rejecting on HELO SPF fail is a no brainer.
The controversy is whether receivers should reject for HELO SPF
neutral/softfail. My reasoning is that there is absolutely no excuse
for a real MTA to get anything other than PASS on HELO SPF - other
than a totally incompetent admin, whose mail I don't want any way.
Others may disagree.

For client mail that I admin, I reject on HELO SPF neutral (and
on "three strikes" - no available PTR/HELO/SPF identity) when
"strong" spam rejection is requested. Incredibly, there are a handful of their
customers who publish SPF and can't even get their own MTAs right.
(And many more who forgot to tell their users about the new requirement
to relay through the central MTA published in their policy.)
I have an exception database for these bozos (who, being customers,
are nevertheless "right").

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


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

>On Mon, 5 Jan 2009, Don Lee wrote:
>
>> Where do we stand with SPF usage on HELO/EHLO?
>>
>> The establishment of "capitol" out there in the net in the
>> form of the thousands of domains that publish SPF records
>> may or may not be used to check MAIL FROM: but can most
>> certainly be used to check HELO/EHLO. Yet, I am still
>> getting static when I bring this up in other forums.
>> ("SPF breaks forwarding... blah blah")
>>
>> Using SPF on HELO/EHLO is a straightforward and effective way
>> to prevent forgery of MTA identity, and though not directly
>> effective in suppressing SPAM, it's a vital pre-requisite to
>> reputation scoring of MTAs.
>>
>> Is there evidence of progress on this front?
>
>I have always rejected any message HELO has an SPF record and
>fails to get PASS. Rejecting on HELO SPF fail is a no brainer.
>The controversy is whether receivers should reject for HELO SPF
>neutral/softfail. My reasoning is that there is absolutely no excuse
>for a real MTA to get anything other than PASS on HELO SPF - other
>than a totally incompetent admin, whose mail I don't want any way.
>Others may disagree.
>
>For client mail that I admin, I reject on HELO SPF neutral (and
>on "three strikes" - no available PTR/HELO/SPF identity) when
>"strong" spam rejection is requested. Incredibly, there are a handful of their
>customers who publish SPF and can't even get their own MTAs right.
>(And many more who forgot to tell their users about the new requirement
>to relay through the central MTA published in their policy.)
>I have an exception database for these bozos (who, being customers,
>are nevertheless "right").
>
>--
> Stuart D. Gathman <stuart@bmsi.com>

This is exactly what I would hope to hear, but I am hoping to hear it
from more admins. ;->

The sense I get in other forums is that SPF "can't be used" because it
"breaks forwarding". The heavy lifting that needs to be done is to
"get the word out" that what you are doing is safe and effective.

Are there any efforts/activities afoot that will "get the word out"?

-dgl-


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

On Mon, 5 Jan 2009, spfdiscuss@caution.icompute.com wrote:

> The sense I get in other forums is that SPF "can't be used" because it
> "breaks forwarding". The heavy lifting that needs to be done is to
> "get the word out" that what you are doing is safe and effective.
>
> Are there any efforts/activities afoot that will "get the word out"?

The other word that needs to get out is that SPF can only break forwarding
(or secondary MXes) when receivers totally screw up their implementation. And
receivers that have legitimate reasons why proper forwarder handling is more
difficult than proper MX handling (large ESPs that allow users to setup
random alias forwarders with no reporting or supervision) can simply punt and
not check SPF. There is never any reason not to publish SPF (other than an
irrational and/or criminal desire to send mail from random MTAs worldwide).

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


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

On Monday 05 January 2009 16:45, Don Lee wrote:
> Where do we stand with SPF usage on HELO/EHLO?
>
> The establishment of "capitol" out there in the net in the
> form of the thousands of domains that publish SPF records
> may or may not be used to check MAIL FROM: but can most
> certainly be used to check HELO/EHLO. Yet, I am still
> getting static when I bring this up in other forums.
> ("SPF breaks forwarding... blah blah")
>
> Using SPF on HELO/EHLO is a straightforward and effective way
> to prevent forgery of MTA identity, and though not directly
> effective in suppressing SPAM, it's a vital pre-requisite to
> reputation scoring of MTAs.
>
> Is there evidence of progress on this front?
>
To echo what Stuart said, for HELO/EHLO checks the default in my SPF policy
server is to reject any mail that does is not Pass/None. So far no one has
complained about it.

http://www.openspf.org/Software#python-postfix-policyd-spf

This is a volunteer project and so we need people to jump in and help spread
the word.

Scott K


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

spfdiscuss@caution.icompute.com wrote:
> The sense I get in other forums is that SPF "can't be used" because it
> "breaks forwarding".

One reason why "forwarding" may be considered broken is that that term
doesn't actually have a definite technical meaning in SMTP. To wit,
RFC 5321 added (w.r.t. RFC 2821) an apparently inconsistent phrase
about forwarding. Section 3.9.2 (lists) begins with:

| A mailing list may be said to operate by "redistribution" rather
| than by "forwarding".

apparently implying that "forwarding" is a different operation than
sending mailing list messages. However, the phrase added to the same
paragraph says that:

| the key difference between handling aliases (Section 3.9.1) and
| forwarding (this subsection) is the change to the backward-pointing
| address in this case.

which implies that sending mailing list messages _is_ "forwarding".
The standard literally says that forwarding with a changed return
address is not forwarding. Should that be interpreted like the Baima
Lun saying that a white horse is not a horse?

> Are there any efforts/activities afoot that will "get the word out"?

Perhaps http://fixforwarding.org/.


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

On Wed, 07 Jan 2009 12:22:24 +0100 Alessandro Vesely <vesely@tana.it> wrote:
>spfdiscuss@caution.icompute.com wrote:
>> The sense I get in other forums is that SPF "can't be used" because it
>> "breaks forwarding".
>
>One reason why "forwarding" may be considered broken is that that term
>doesn't actually have a definite technical meaning in SMTP. To wit,
>RFC 5321 added (w.r.t. RFC 2821) an apparently inconsistent phrase
>about forwarding. Section 3.9.2 (lists) begins with:
>
>| A mailing list may be said to operate by "redistribution" rather
>| than by "forwarding".
>
>apparently implying that "forwarding" is a different operation than
>sending mailing list messages. However, the phrase added to the same
>paragraph says that:
>
>| the key difference between handling aliases (Section 3.9.1) and
>| forwarding (this subsection) is the change to the backward-pointing
>| address in this case.
>
>which implies that sending mailing list messages _is_ "forwarding".
>The standard literally says that forwarding with a changed return
>address is not forwarding. Should that be interpreted like the Baima
>Lun saying that a white horse is not a horse?

With a mailing list, a message is sent to the list manager, it is
delivered, and then a new message (with a usually modified body) is created
and sent to the subscriber list. So whatever 'forwarding' is, it's pretty
clearly not a mailing list.

Scott K


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

Scott Kitterman wrote:
> On Wed, 07 Jan 2009 12:22:24 +0100 Alessandro Vesely <vesely@tana.it> wrote:
>>
>>| the key difference between handling aliases (Section 3.9.1) and
>>| forwarding (this subsection) is the change to the backward-pointing
>>| address in this case.
>>
>>The standard literally says that forwarding with a changed return
>>address is not forwarding. Should that be interpreted like the Baima
>>Lun saying that a white horse is not a horse?
>
> With a mailing list, a message is sent to the list manager, it is
> delivered, and then a new message (with a usually modified body) is created
> and sent to the subscriber list.

Why a "new" message? The Message-ID field should be preserved. Even if
the ENVID value should be changed and (positive) DSNs should not reach
the original sender, I wouldn't decorate MTAs with the authorship that
creating a new message requires... Automated body modifications are
also done by clients and MSAs.

> So whatever 'forwarding' is, it's pretty clearly not a mailing list.

It was John Klensin who used that term for the action discussed in the
"List" subsection of the standard.


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

At 06:40 AM 1/7/2009 -0500, Scott Kitterman wrote:

>On Wed, 07 Jan 2009 12:22:24 +0100 Alessandro Vesely <vesely@tana.it> wrote:
>>spfdiscuss@caution.icompute.com wrote:
>>> The sense I get in other forums is that SPF "can't be used" because it
>>> "breaks forwarding".
>>
>>One reason why "forwarding" may be considered broken is that that term
>>doesn't actually have a definite technical meaning in SMTP. To wit,
>>RFC 5321 added (w.r.t. RFC 2821) an apparently inconsistent phrase
>>about forwarding. Section 3.9.2 (lists) begins with:
>>
>>| A mailing list may be said to operate by "redistribution" rather
>>| than by "forwarding".
>>
>>apparently implying that "forwarding" is a different operation than
>>sending mailing list messages. However, the phrase added to the same
>>paragraph says that:
>>
>>| the key difference between handling aliases (Section 3.9.1) and
>>| forwarding (this subsection) is the change to the backward-pointing
>>| address in this case.
>>
>>which implies that sending mailing list messages _is_ "forwarding".
>>The standard literally says that forwarding with a changed return
>>address is not forwarding. Should that be interpreted like the Baima
>>Lun saying that a white horse is not a horse?
>
>With a mailing list, a message is sent to the list manager, it is
>delivered, and then a new message (with a usually modified body) is created
>and sent to the subscriber list. So whatever 'forwarding' is, it's pretty
>clearly not a mailing list.

The term "forwarding" can apply to anything from routers, which store and forward IP datagrams, to any MTA, which stores and forwards an email message. The best thing to do is agree on terminology at the start of each and every discussion. It helps to have a webpage, like I do at http://open-mail.org/MHSmodel.html Then, when the original message in a thread is forgotten, everyone can refer back to the agreed-on definitions, and avoid a long discussions where the participants don't even realize they are not talking about the same thing.

In discussions of email, I prefer to limit the term Forwarding to just Agents on the Recipient's side of the Border. I use capitalization to show I have specific definitions in mind. An Agent may operate several MTAs, and forwarding within that Agent's ADMD (Administrative Management Domain), is not Forwarding. Forwarding requires a change in the envelope address of the Recipient, changing at least the domain name in that address.

Using this definition of Forwarding, we can leave out Transmitters and Remailers. Each of those Agents has an entirely different set of responsibilities, and calling them forwarders will make a general solution to the "forwarding problem" extremely difficult, probably impossible. See http://en.wikipedia.org/wiki/E-mail_forwarding for a discussion of forwarding vs remailing.





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

On Wednesday 07 January 2009 07:38, Alessandro Vesely wrote:
> Scott Kitterman wrote:
> > On Wed, 07 Jan 2009 12:22:24 +0100 Alessandro Vesely <vesely@tana.it>
wrote:
> >>| the key difference between handling aliases (Section 3.9.1) and
> >>| forwarding (this subsection) is the change to the backward-pointing
> >>| address in this case.
> >>
> >>The standard literally says that forwarding with a changed return
> >>address is not forwarding. Should that be interpreted like the Baima
> >>Lun saying that a white horse is not a horse?
> >
> > With a mailing list, a message is sent to the list manager, it is
> > delivered, and then a new message (with a usually modified body) is
> > created and sent to the subscriber list.
>
> Why a "new" message? The Message-ID field should be preserved. Even if
> the ENVID value should be changed and (positive) DSNs should not reach
> the original sender, I wouldn't decorate MTAs with the authorship that
> creating a new message requires... Automated body modifications are
> also done by clients and MSAs.
>
> > So whatever 'forwarding' is, it's pretty clearly not a mailing list.
>
> It was John Klensin who used that term for the action discussed in the
> "List" subsection of the standard.

For me, as an MTA admin, the distinction has always been that there's a
delivery. I've no idea how that relates to what's in the current standards
as it's been some time since I looked.

Scott K


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

The question here is not a technical one, but a marketing one.

The thousands of SPF records in DNS provided by admins represent an
asset that I would like to see used. To provide incentive to
grow that asset, we need to be crystal clear about how it is
useful. Any downside, or FUD is damaging.

SPF can be used to vet HELO/EHLO between MTAs. This is non-controversial,
and effective to prevent some kinds of spoofing. Checking SPF on
HELO/EHLO enables reputation checking of MTAs. This is all
goodness. No downside. No FUD.

I want to have this conversation - stand-alone. I want to . I want this convince certain admins and authors to implement SPF checking
on HELO/EHLO. Without crystal clear guidance from SPF "authorities",
that's proven difficult.

The verbiage on the web site is helpful, but is not clear enough on
this single point to help me convince people that SPF can be used in
this way safely and effectively.

Most conversations I have about SPF get bogged down in forwarding tech
and FUD. My thrust - check HELO - quickly gets derailed, and I
don't get my HELO checking.

The tech talk about RFCs is certainly important, and efforts are
underway to do the heavy lifting to "fix forwarding", but I want
to separate the "clearly useful - let's just do it" part (HELO)
from the "arguably wonderful, but we can't quite get to closure" parts.

The former is easy, and I would like to see it emphasized. The latter
detracts from the former when its debate clouds the issue, and leaves
admins thinking that SPF is a "single package".

I think we can fix this by separating these two ideas.

-dgl-

>On Wednesday 07 January 2009 07:38, Alessandro Vesely wrote:
>> Scott Kitterman wrote:
>> > On Wed, 07 Jan 2009 12:22:24 +0100 Alessandro Vesely <vesely@tana.it>
>wrote:
>> >>| the key difference between handling aliases (Section 3.9.1) and
>> >>| forwarding (this subsection) is the change to the backward-pointing
>> >>| address in this case.
>> >>
>> >>The standard literally says that forwarding with a changed return
>> >>address is not forwarding. Should that be interpreted like the Baima
>> >>Lun saying that a white horse is not a horse?
>> >
>> > With a mailing list, a message is sent to the list manager, it is
>> > delivered, and then a new message (with a usually modified body) is
>> > created and sent to the subscriber list.
>>
>> Why a "new" message? The Message-ID field should be preserved. Even if
>> the ENVID value should be changed and (positive) DSNs should not reach
>> the original sender, I wouldn't decorate MTAs with the authorship that
>> creating a new message requires... Automated body modifications are
>> also done by clients and MSAs.
>>
>> > So whatever 'forwarding' is, it's pretty clearly not a mailing list.
>>
>> It was John Klensin who used that term for the action discussed in the
>> "List" subsection of the standard.
>
>For me, as an MTA admin, the distinction has always been that there's a
>delivery. I've no idea how that relates to what's in the current standards
>as it's been some time since I looked.
>
>Scott K
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org
>Modify Your Subscription: http://www.listbox.com/member/
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/
>Powered by Listbox: http://www.listbox.com



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

On Wed, 7 Jan 2009, Don Lee wrote:

> The question here is not a technical one, but a marketing one.
> ...
> SPF can be used to vet HELO/EHLO between MTAs. This is non-controversial,
> and effective to prevent some kinds of spoofing. Checking SPF on
> HELO/EHLO enables reputation checking of MTAs. This is all
> goodness. No downside. No FUD.
>
> I want to have this conversation - stand-alone. I want to . I want this
> convince certain admins and authors to implement SPF checking on HELO/EHLO.
> Without crystal clear guidance from SPF "authorities",
> that's proven difficult.

As an (expired) SPF council member, HELO SPF is a no brainer. That is why it
doesn't get discussed much. :-)

On that topic, when SPF is not available, I consider a HELO name
with an A/AAAA record that matches the connecting IP as good as an
SPF pass for reputation purposes. SPF just lets the MTA admin be
more flexible with IP assignment for their MTAs.

Furthermore, no user education (to use SMTP AUTH for instance) is required
to get the full benefits of HELO SPF. Only admin education.

As you say, all goodness, no gotchas.

[.resisting urge to throw in another point about the much more interesting
topic of MAIL FROM SPF and "forwarding" ...]

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


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

>On Wed, 7 Jan 2009, Don Lee wrote:
>
>> The question here is not a technical one, but a marketing one.
>> ...
>> SPF can be used to vet HELO/EHLO between MTAs. This is non-controversial,
>> and effective to prevent some kinds of spoofing. Checking SPF on
>> HELO/EHLO enables reputation checking of MTAs. This is all
>> goodness. No downside. No FUD.
>>
>> I want to have this conversation - stand-alone. I want to . I want this
>> convince certain admins and authors to implement SPF checking on HELO/EHLO.
>> Without crystal clear guidance from SPF "authorities",
>> that's proven difficult.
>
>As an (expired) SPF council member, HELO SPF is a no brainer. That is why it
>doesn't get discussed much. :-)

Agreed.

>On that topic, when SPF is not available, I consider a HELO name
>with an A/AAAA record that matches the connecting IP as good as an
>SPF pass for reputation purposes. SPF just lets the MTA admin be
>more flexible with IP assignment for their MTAs.

This is actually not true. SPF is quite a bit better than a match between
IP and fwd/reverse DNS. The biggest reason is that SPF says explicitly
that the admin of the IP and domain authorize mail to be sent from that
IP. On the other side, there are both lots of DNS/IP combinations that
have "matching" entries that have no business sending mail. (ex:
ppp123.321.22.34.dynamic.bogoisp.com.ru) There are also various reasons
for _valid_ IP/DNS combinations to "not match". (insert long discussion
here about details and issues, plus a dash of FUD)

SPF is a much more accurate, simpler test. In the absence of SPF, A/AAA
and IP checking is better than nothing. ;->

>Furthermore, no user education (to use SMTP AUTH for instance) is required
>to get the full benefits of HELO SPF. Only admin education.
>
>As you say, all goodness, no gotchas.

Exactly.

>[.resisting urge to throw in another point about the much more interesting
>topic of MAIL FROM SPF and "forwarding" ...]

;->

-dgl-


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

On Wed, 7 Jan 2009 13:56:10 -0600 Don Lee <spfdiscuss@caution.icompute.com>
wrote:
>The verbiage on the web site is helpful, but is not clear enough on
>this single point to help me convince people that SPF can be used in
>this way safely and effectively.
>
Make a proposal for what you think it ought to say (in the community
section of the wiki - all of the web site is a wiki) and I'll review it and
publish it in the "official" section.

Scott K


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

Don Lee wrote:
>>On that topic, when SPF is not available, I consider a HELO name
>>with an A/AAAA record that matches the connecting IP as good as an
>>SPF pass for reputation purposes. SPF just lets the MTA admin be
>>more flexible with IP assignment for their MTAs.
>
> This is actually not true. SPF is quite a bit better than a match between
> IP and fwd/reverse DNS. The biggest reason is that SPF says explicitly
> that the admin of the IP and domain authorize mail to be sent from that
> IP.

However, as a domain admin, I cannot use SPF to specify that a given
host is _not_ authorized to send mail. Assume I manage 192.0.2.2 and
it corresponds to client.example.com. I think that host is likely to
become possessed, but I cannot filter out its connections to port 25.
So I try and explicitly authorize no hosts by publishing

client.example.com IN TXT "v=spf1 -all"

Now, what if that host connects to some port 25 server out there and
says any of the following:

EHLO not.that.client.example.com
EHLO [192.0.2.2]
HELO HOWDY

My naive TXT record above won't play. The server will get an SPF
result of "none", which it has better accept as it is plenty of MTAs
with correct SPF records except for the HELO identity. Since it had no
"pass", the server may verify DNS/rDNS: it will find the name doesn't
match; however, 192.0.2.2 and client.example.com make a consistent
pair and it accepts the connection. FWIW, the RFC says

| An SMTP server MAY verify that the domain name argument in the EHLO
| command actually corresponds to the IP address of the client.
| However, if the verification fails, the server MUST NOT refuse to
| accept a message on that basis. Information captured in the
| verification attempt is for logging and tracing purposes.

Perhaps SPF on HELO would have been more effective if servers checked
the name resulting from rDNS.


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

On Thu, 08 Jan 2009 13:46:54 +0100 Alessandro Vesely <vesely@tana.it> wrote:
>Don Lee wrote:
>>>On that topic, when SPF is not available, I consider a HELO name
>>>with an A/AAAA record that matches the connecting IP as good as an
>>>SPF pass for reputation purposes. SPF just lets the MTA admin be
>>>more flexible with IP assignment for their MTAs.
>>
>> This is actually not true. SPF is quite a bit better than a match
between
>> IP and fwd/reverse DNS. The biggest reason is that SPF says explicitly
>> that the admin of the IP and domain authorize mail to be sent from that
>> IP.
>
>However, as a domain admin, I cannot use SPF to specify that a given
>host is _not_ authorized to send mail. Assume I manage 192.0.2.2 and
>it corresponds to client.example.com. I think that host is likely to
>become possessed, but I cannot filter out its connections to port 25.
>So I try and explicitly authorize no hosts by publishing
>
> client.example.com IN TXT "v=spf1 -all"
>
>Now, what if that host connects to some port 25 server out there and
>says any of the following:
>
> EHLO not.that.client.example.com
> EHLO [192.0.2.2]
> HELO HOWDY
>
>My naive TXT record above won't play. The server will get an SPF
>result of "none", which it has better accept as it is plenty of MTAs
>with correct SPF records except for the HELO identity. Since it had no
>"pass", the server may verify DNS/rDNS: it will find the name doesn't
>match; however, 192.0.2.2 and client.example.com make a consistent
>pair and it accepts the connection. FWIW, the RFC says
>
>| An SMTP server MAY verify that the domain name argument in the EHLO
>| command actually corresponds to the IP address of the client.
>| However, if the verification fails, the server MUST NOT refuse to
>| accept a message on that basis. Information captured in the
>| verification attempt is for logging and tracing purposes.
>
>Perhaps SPF on HELO would have been more effective if servers checked
>the name resulting from rDNS.
>

SPF only does what it does and isn't a panacea. Typically in cases like
this not.that.client.example.com doesn't exist (no A record) or is another
host (A points to another IP), so you can tell this is bogus before you
even check SPF or rDNS.

Scott K


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

Scott Kitterman wrote:
> On Thu, 08 Jan 2009 13:46:54 +0100 Alessandro Vesely <vesely@tana.it> wrote:
>>Perhaps SPF on HELO would have been more effective if servers checked
>>the name resulting from rDNS.
>
> SPF only does what it does and isn't a panacea.

Yup, it blocks senders, not hosts. Possibly, someone on this list
recalls how come RFC 4408 recommends checking the HELO identity as well...

> Typically in cases like this [...] you can tell this is bogus before you
> even check SPF or rDNS.

Yet, it's not quite sound to reject a message on that basis. The
ability to reject spurious senders right on the MAIL FROM command is
SPF's centerpiece. SPF on HELO can add or subtract a few points from a
spam score, and I'm not sure whether that deserves being highlighted
as a prominent feature for marketing purposes.



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

On Thursday 08 January 2009 09:42, Alessandro Vesely wrote:
> Scott Kitterman wrote:
> > On Thu, 08 Jan 2009 13:46:54 +0100 Alessandro Vesely <vesely@tana.it>
wrote:
> >>Perhaps SPF on HELO would have been more effective if servers checked
> >>the name resulting from rDNS.
> >
> > SPF only does what it does and isn't a panacea.
>
> Yup, it blocks senders, not hosts. Possibly, someone on this list
> recalls how come RFC 4408 recommends checking the HELO identity as well...

It started out as a fallback for what to do for null sender (Mail From <>)
messages, but proved to have general utility.

> > Typically in cases like this [...] you can tell this is bogus before you
> > even check SPF or rDNS.
>
> Yet, it's not quite sound to reject a message on that basis. The
> ability to reject spurious senders right on the MAIL FROM command is
> SPF's centerpiece. SPF on HELO can add or subtract a few points from a
> spam score, and I'm not sure whether that deserves being highlighted
> as a prominent feature for marketing purposes.

I disagree. Rejecting mail with an SPF HELO result that is not Pass/None is
quite safe and low cost.

Many entities reject mail where forward/reverse DNS don't match (AOL for one).
Even more reject for lack of rDNS. So rejecting mail for faulty HELO/EHLO is
quite well established even if the RFCs are behind (as usual). SPF HELO
checks add to this and are an easy win that do not have any of (from my view
small, but still real) downsides of rejecting mail based on SPF Fail for Mail
From.

If a server is acting as a MSA (submission agent) then for submission, I
totally agree that rejecting based on HELO/EHLO issues is unsound, but you
shouldn't check SPF at all in that case.

For MTA to MTA transactions, what is unsound about rejecting mail from a
non-existant HELO name or one where the HELO name A record don't match?

Scott K


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

Scott Kitterman wrote:
> On Thursday 08 January 2009 09:42, Alessandro Vesely wrote:
>> SPF on HELO can add or subtract a few points from a
>> spam score, and I'm not sure whether that deserves being highlighted
>> as a prominent feature for marketing purposes.
>
> I disagree. Rejecting mail with an SPF HELO result that is not Pass/None is
> quite safe and low cost.

Yes it is, but only newbie spammers so ingenuous as to use a
prohibited domain name for their HELO identity will produce a fail.

> Many entities reject mail where forward/reverse DNS don't match (AOL for one).

According to http://postmaster.aol.com/guidelines/standards.html they
merely check for a consistent PTR record. I found no mention about
HELO identity requirements.

> Even more reject for lack of rDNS. So rejecting mail for faulty HELO/EHLO is
> quite well established even if the RFCs are behind (as usual).

Hm... Senders BCPs at MAAWG mention that the HELO name /should/ be the
same as that delivered by rDNS. However, I suspect most MTAs just
check that a consistent rDNS/DNS pair exists (what wikipedia calls a
"FCrDNS" (http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS))

> SPF HELO
> checks add to this and are an easy win that do not have any of (from my view
> small, but still real) downsides of rejecting mail based on SPF Fail for Mail
> From.

CSV and David's _auth mechanisms do that check with much less effort
and more reliability than SPF --those mechanisms provide for denying
an IP to send mail for a given domain. Besides possible
misconfiguration, there should be no downside in blocking prohibited
senders.

> If a server is acting as a MSA (submission agent) then for submission, I
> totally agree that rejecting based on HELO/EHLO issues is unsound, but you
> shouldn't check SPF at all in that case.

Correct.

> For MTA to MTA transactions, what is unsound about rejecting mail from a
> non-existant HELO name or one where the HELO name A record don't match?

Setting a matching HELO name may be cumbersome when using NAT,
multihomed hosts, VPNs, and the like. IMHO, checking the domain name
should suffice.



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

>On Thursday 08 January 2009 09:42, Alessandro Vesely wrote:
>> Scott Kitterman wrote:
>> > On Thu, 08 Jan 2009 13:46:54 +0100 Alessandro Vesely <vesely@tana.it>
>wrote:
>> >>Perhaps SPF on HELO would have been more effective if servers checked
>> >>the name resulting from rDNS.
>> >
>> > SPF only does what it does and isn't a panacea.
>>
>> Yup, it blocks senders, not hosts. Possibly, someone on this list
>> recalls how come RFC 4408 recommends checking the HELO identity as well...
>
>It started out as a fallback for what to do for null sender (Mail From <>)
>messages, but proved to have general utility.

OK. Maybe this is not quite baked yet.

What is the precise algorithm for checking SPF on HELO?

It seems to me that the HELO name is required to determine what domain
is taking responsibility for the mail being sent.

(Pardon the pseudo-code)

sender_IP /* actual IP of connecting MTA */
sender_HELO /* HELO offered by conneting MTA */
sender_HELO_IP /* IP of sender according to lookup of HELO name (unused?) */
sender_SPF_IP_list /* Listed IP addresses for HELO name, per SPF recs */

if (sender_HELO_IP != valid_A_rec) return(fail);
if (SPF(sender_HELO) == none) return(none);
if (sender_IP is_contained_in_list( sender_SPF_IP_list)) return (pass);
return (fail);

Note that the sender_HELO_IP is not used. One could also check to see that
sender_IP and sender_HELO_IP are the same. (they should be, but...)

Note also that the FUD surrounding -all ?all ~all is not relevant
here. If the IP being used to send mail from the SPF listed domain is
not explicitly listed, the check fails.

Would this algorithm be sufficient?

The idea is that an MTA that gets a <fail> would have all its mail rejected.
I currently do this, with no problems, but I do it "by hand".


I have a question from someone this morning about doing this. He says
that:

>The problem is there are *almost zero* SPF records published for HELO names. To be effective, there should be one record for every outgoing Border MTA, and the record should end in -all. How do we motivate senders to do this?

This brings up another point that needs to be resolved: is there any difference
between SPF records "for HELO checking" and "for MAIL FROM" checking?
I think not. (I will invite this gentleman to join this mail list BTW)

-dgl-


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

>> SPF HELO checks add to this and are an easy win that do not have any of (from my view small, but still real) downsides of rejecting mail based on SPF Fail for Mail From.
>
>CSV and David's _auth mechanisms do that check with much less effort and more reliability than SPF --those mechanisms provide for denying an IP to send mail for a given domain. Besides possible misconfiguration, there should be no downside in blocking prohibited senders.

Can you explain? What is "CSV and David's _auth"?

Note that FCrDNS is much weaker than SPF, because it allows the IP range
owner to "authorize" IPs for MTA activity. For example, comcast.net
has large ranges of IPs that have FCrDNS, but are used by cable
modem users. FCrDNS tells us that the DNS is up to date. SPF can tell
us if comcast.net authorized a mailserver to run on that IP.

-dgl-


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

On Thu, 8 Jan 2009, Alessandro Vesely wrote:

> Setting a matching HELO name may be cumbersome when using NAT, multihomed
> hosts, VPNs, and the like. IMHO, checking the domain name should suffice.

Multihomed hosts just need to use a HELO that matches the IP they
are sending mail on. Using a single HELO name with multiple A records
that matches *all* their IPs works too if the sending IP is selected
randomly. NAT and VPN are irrelevant. Just set HELO to something that matches
whatever you are natted to - just like multi-homed.

I don't *require* PTR. HELO works just as well as rDNS (better and cheaper).
But I'll take a valid PTR in place of a bogus HELO to establish MTA
identity. I don't like MTAs that require rDNS/PTR, because the vast majority
of MTAs for small domains do not have a 256 block of IPs, and have to
beg and plead with their ISP for weeks to get rDNS configured properly.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


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

Alessandro Vesely wrote:
> Scott Kitterman wrote:
>> On Thu, 08 Jan 2009 13:46:54 +0100 Alessandro Vesely <vesely@tana.it>
>> wrote:
>>> Perhaps SPF on HELO would have been more effective if servers checked
>>> the name resulting from rDNS.
>>
>> SPF only does what it does and isn't a panacea.
>
> Yup, it blocks senders, not hosts. Possibly, someone on this list
> recalls how come RFC 4408 recommends checking the HELO identity as well...

Hi,

I was one of the early proponents to push HELO SPF checking with a
strong PASS and FAIL consideration.

The key reason is that it is a easy check and since the client machine
domain must be used per 2821 and per 4408, there is none of the
"indirect forwarding issue" with it that can come about with the
requirement to use a persistent return path along a SMTP route (or
transition point before final destination).

I wrote the following analysis back in 2004 to illustrate HELO/MAIL
FROM checking, where the hard TRUE or FALSE conditions and
expectations and where/when there are indeterminate points.

http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm

--
HLS




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

Don Lee wrote:
>>CSV and David's _auth mechanisms do that check with much less effort and more reliability than SPF --those mechanisms provide for denying an IP to send mail for a given domain.
>
> Can you explain? What is "CSV and David's _auth"?

Two methods designed for establishing who is authorized to relay mail
in a hierarchically authoritative fashion, i.e. using DNS "properly"
(as opposed to DNSBL non-hierarchical scheme.)

For more info, see
http://en.wikipedia.org/wiki/Certified_Server_Validation
http://open-mail.org/Registry.html



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

On Thursday 08 January 2009 13:25, Don Lee wrote:
> >> SPF HELO checks add to this and are an easy win that do not have any of
> >> (from my view small, but still real) downsides of rejecting mail based
> >> on SPF Fail for Mail From.
> >
> >CSV and David's _auth mechanisms do that check with much less effort and
> > more reliability than SPF --those mechanisms provide for denying an IP to
> > send mail for a given domain. Besides possible misconfiguration, there
> > should be no downside in blocking prohibited senders.
>
> Can you explain? What is "CSV and David's _auth"?
>
> Note that FCrDNS is much weaker than SPF, because it allows the IP range
> owner to "authorize" IPs for MTA activity. For example, comcast.net
> has large ranges of IPs that have FCrDNS, but are used by cable
> modem users. FCrDNS tells us that the DNS is up to date. SPF can tell
> us if comcast.net authorized a mailserver to run on that IP.
>
http://mipassoc.org/csv/index.html is the CSV in question. It has zero
deployment and the author has given up on getting any. CSV may have been
a 'better' solution for HELO, but since it never got off top dead center it's
a theoretical point at most.

David's on the list, so I'll let him speak for himself.

Scott K


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