SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/")

[Sukhenko, Alex]

Sorry if I am jumping on mid stream and missing the main point but SPF was
suppose to be the first step and then next would be reputation.

BTY I am very pleased with SenderBase (even catches Comcast zombies) I would
be curious to know if anyone else is?

I also noticed that some corp. at least one Kraft, is rejecting email if
your sending IP is not one of your MX IPs:

"v=spf1 mx ?all"

----------------------------------------
Alex Sukhenko
CTO
Exmplar
3900 Jermantown Road
Fairfax, VA 20330
703 273 2311 x232 - phone
703 654 6588 - fax

-----Original Message-----
From: owner-ietf-***@mail.imc.org [mailto:owner-ietf-***@mail.imc.org]
On Behalf Of Carl Hutzler
Sent: Thursday, May 26, 2005 7:21 AM
To: ***@xyzzy.claranet.de
Cc: ietf-***@imc.org
Subject: Re: SPF PASS (was: "If you believe that the SPF concept is
fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/")

Is this use of SPF flawed?

[...]

If the [connecting IP] = [SPF record] then "trust it
more/whitelist"

It's perfectly possible for a spammer to get a PASS. You
wouldn't whitelist a spammer. But it's impossible for a
spammer to pretend to be me, he'd get a FAIL (in my case).
Unless I'm this spammer of course.

Actually, we DO WHITELIST SPAMMERS. I mean it happens. We don't want it
to happen a lot, but it does. See we also monitor everyone on the WL
very closely via volume, complaint, and bounce rates. So while a spammer
could get onto the whitelist, they won't be for long. And a new spammer
will have very low limits placed on how much they can send via a simple
SPF=whitelist type method. Now if they prove once on the SPF=whitelist
that they are a good sender, we would bump up their rate limits....or if
they contact us to get "accredited" via our postmaster.aol.com webpage
where you can simply ask to be on the whitelist, we might let them in
with higher limits on day 1. We do this of course for well known
organizations.

valuable reverse MX records which cover well over 95% of
the email traffic on the internet today.

Is that a guess ? 95% is a rather high number.

OK, 85%. Is that better? Still beats the 80/20 rule easily. How much
mail is not sent directly from the sending ISP to the destination ISP.
For AOL it is a small number.

Perhaps SPF should be updated to have the above logic.

You can use it this way. But whitelisting a PASS only
"v=spf1 +exists:{ir}.comcast.blackholes.us -all"

See above. It actually IS very good for AOL because of all our other
reputation based logic. Perhaps not every ISP can build this, but we do
have one. Of course many 3rd party products are out there that do what
we do...SenderBase (volume/bounces), SpamCop (complaints), Spamnet
(complaints), etc.

Back to my day job :-)

Be careful with mail from these comcast IPs, bye, Frank

[Andrew Newton]

Post by Sukhenko, Alex

valuable reverse MX records which cover well over 95% of
the email traffic on the internet today.

Is that a guess ? 95% is a rather high number.

OK, 85%. Is that better? Still beats the 80/20 rule easily. How much
mail is not sent directly from the sending ISP to the destination ISP.
For AOL it is a small number.

So why aren't more people publishing very assertive SPF records ending
in -all and why aren't more people only accepting mail that has a PASS?

Like Carl, I use SPF but not in the manner prescribed by the SPF
documents. I think there would be fewer detractors of SPF if more
emphasis were placed on the "Framework" portion of the spec. That's
not to say that the work currently underway by Wayne is unimportant.

-andy

[william(at)elan.net]

Post by Sukhenko, Alex
OK, 85%. Is that better? Still beats the 80/20 rule easily. How much
mail is not sent directly from the sending ISP to the destination ISP.
For AOL it is a small number.

So why aren't more people publishing very assertive SPF records ending in
-all and why aren't more people only accepting mail that has a PASS?

85% of email traffic (percent counted based on single messages) may well
be < 50% of email senders (percent counted based on individual authors)
and may be < 10% of email sender domains (percent counted based on domains
of individual senders).

Its that last number that is likely to be crucial because the first 2
numbers involve people user communicates with most often or who are on
the same net and those are likely to already be on their whitelist (if
they have it), but user does not expect mail from others to be rejected
or otherwise such user would already be using whitelisting-only setup.

Like Carl, I use SPF but not in the manner prescribed by the SPF documents.

Unless I'm mistaken, you use it exactly in the manner prescribed by the EHLO
part of the spec, you're just downgrade results from MAILFROM check.

As I said long ago, EHLO should be totally separate document with separate
recommendations about its use (like CSV) and separate recommendations about
setting up records (because records should be a lot more precise and consist
of one or couple of "a" instead of entire ip blocks and includes).

And for each scope like EHLO it should be up to receiver if it wants to
use just one scope or several in combination with optional document
that is available describing guidelines for doing combined checks.

I think there would be fewer detractors of SPF if more emphasis were placed
on the "Framework" portion of the spec.

Sure, I'd love to get started on the "Framework" (aka UnifiedSPF), if only
we did not have well known political factors distracting us from the work.

[Carl Hutzler]

I wish there was a way to utilize the relatively large number of SPF
records in a technology like CSV.

-Carl

[Tony Finch]

I wish there was a way to utilize the relatively large number of SPF records
in a technology like CSV.

It seemed to me at one point that there was some promise that it would be
possible to write an SPF record which applied only to HELO or only to PRA
or only to the return path. However divergent SPF/SenderID implementations
and specifications have horribly muddied the waters and I'm not sure it's
possible to do this now and expect any kind of reliable interoperability.
Disaster.

Tony.

[william(at)elan.net]

Post by Tony Finch

I wish there was a way to utilize the relatively large number of SPF records
in a technology like CSV.

It seemed to me at one point that there was some promise that it would be
possible to write an SPF record which applied only to HELO or only to PRA
or only to the return path. However divergent SPF/SenderID implementations
and specifications have horribly muddied the waters and I'm not sure it's
possible to do this now and expect any kind of reliable interoperability.
Disaster.

At the end of MARID we started on the path towards unified spf and
multiple scopes. I'd not have been surprised if HELO was next scope
introduced and while I recognize contributions made by CSV people and
hard work they have put in their documents, a common syntax is better
for all and in the end, I believe their work would have been adoptable
as "restricted profile" SPF record (using "a" in place of SRV) as
documentation for HELO scope.

IESG did not do us (I mean everyone who is interest in better email
anti-spoofing and security technologies) any favors by closing down
MARID when we finally started getting somewhere even if we were behind
on the deadline, other WGs are years behind in their work and do not
get disbanded (or need I mention USEFOR perhaps...)

And not that it matters, but AOL did not help either by agreeing to
support SID with use of spf1 only records (which brought political crisis
and strong unhappiness in spf community and stalled further work on
unified spf) - instead you should have pushed for quickly having rfc
(even if its not 100% perfect) that documents current spf1 with all
further work continuing on "spf2" with more comprehensive per-scope
documentation and usage guidelines.

Oh well, enough of history... Lets hope we can salvage at least some of
what we had worked for in the future even if it will not happen quickly.

[Frank Ellermann]

Post by william(at)elan.net
need I mention USEFOR perhaps...

For his sins (3710, MARID) Harald was now condemned to be a
co-chair, he has already found the first trap and pitfall ;-)

Post by william(at)elan.net
Oh well, enough of history... Lets hope we can salvage at
least some of what we had worked for in the future even
if it will not happen quickly.

ACK. Delete one erroneous SHOULD in senderid-core and move
on, I like this SIQ idea. Bye, Frank

[wayne]

Post by Tony Finch

I wish there was a way to utilize the relatively large number of SPF records
in a technology like CSV.

It seemed to me at one point that there was some promise that it would be
possible to write an SPF record which applied only to HELO or only to PRA
or only to the return path.

Yes, at one point there was the ability to limit SPF version 1 records
to only certain scopes, but the scope= modifier was removed in the
fall of 2003. At the time, we really couldn't think of a reliable way
of applying SPF records to the 2822.From: header, and it was thought
that distinguishing between the 2821.MAILFROM and 2821.HELO identities
was not needed.

After widespread experimentation with SPF started in Dec of 2003, it
made changes to the SPF specification very hard.

Post by Tony Finch
However divergent SPF/SenderID implementations
and specifications have horribly muddied the waters and I'm not sure it's
possible to do this now and expect any kind of reliable interoperability.
Disaster.

The goal of the latest SPF-classic (e.g original SPF) I-D is to
document what exists, not to try and create a new SPF protocol. We
have worked very hard to try and keep as much of the semantics of the
draft-mengwong-spf-0[01] documents as practical.

It is true that the MARID I-Ds[*] define a newer protocol with updated
semantics that include things like the return of scopes to SPF. These
I-Ds also call for a new version number to be used, which is good, but
then these I-Ds say that the new semantics should be applied to SPFv1
records, which is REALLY bad. I have asked the IESG to block the
publication of the MARID I-Ds due to the harm that will cause to the
existing SPFv1 deployment. So far, the IESG has not agreed with this
and the incompatible MARID I-Ds are going forward.


-wayne



[*] At one time, Andy asked the PTB whether the existing SenderID
trademark would cause legal problems for the IETF/ISOC if we
published I-Ds using that trademark. Andy came back and said the
risk is too high and that SenderID shouldn't be used in IETF RFCs.

Until such time that I hear that the PTB of the IETF have changed
their mind, I am trying to avoid the use of "SenderID" when
referencing the MARID I-Ds.

[Tony Finch]

These I-Ds also call for a new version number to be used, which is good,
but then these I-Ds say that the new semantics should be applied to
SPFv1 records, which is REALLY bad.

I strongly agree. This makes it impossible to use SPF's baroqueness to
advantage, e.g. by using BATV with stunt DNS servers, and other clever
tricks.

Tony.

[wayne]

Post by Tony Finch

These I-Ds also call for a new version number to be used, which is good,
but then these I-Ds say that the new semantics should be applied to
SPFv1 records, which is REALLY bad.

I strongly agree. This makes it impossible to use SPF's baroqueness to
advantage, e.g. by using BATV with stunt DNS servers, and other clever
tricks.

If you agree that this is really bad, I encourage you to tell
***@ietf.org about this.

I had placed a warning about these problems in the spf-classic I-D
submitted early this year, but someone took it upon themselves,
without informing either Meng nor me, to remove this warning. In the
lastest SPF-classic I-D, the SPF community came up with what I think
is a nice paragraph on the subject, with an explict reference to just
such stunt DNS server as you describe. (See sections 2.4 and 9.3.1.2)


-wayne

[John Levine]

Post by Tony Finch

I wish there was a way to utilize the relatively large number of SPF records
in a technology like CSV.

Yeah. Too bad that among SPF's many flaws is that it completely
confuses the HELO domain and the MAIL FROM domain (and on a bad day,
the domains in From:, Sender:, Resent-From:, and Resent-Sender:.)

Post by Tony Finch
It seemed to me at one point that there was some promise that it
would be possible to write an SPF record which applied only to HELO
or only to PRA or only to the return path.

SPF 2.0 was supposed to let you specify which contexts each record is
supposed to apply to, but I agree that it'll never get any traction.

[Terry Fielder]

Post by John Levine

Post by Tony Finch

I wish there was a way to utilize the relatively large number of SPF records
in a technology like CSV.

Yeah. Too bad that among SPF's many flaws is that it completely
confuses the HELO domain and the MAIL FROM domain

No it does not. It checks each independently. See my previous post to
your question.

Post by John Levine
(and on a bad day,
the domains in From:, Sender:, Resent-From:, and Resent-Sender:.)

SPF never does that, please do not confuse PRA with SPF.

Post by John Levine

Post by Tony Finch
It seemed to me at one point that there was some promise that it
would be possible to write an SPF record which applied only to HELO
or only to PRA or only to the return path.

SPF 2.0 was supposed to let you specify which contexts each record is
supposed to apply to, but I agree that it'll never get any traction.

SPF 2.0 won't, because its tied to PRA. That does not preclude SPF 3.0
using the syntax of proposed SPF2.0, which would superscede SPF1 and
really be the second generation of SPF1 (because SPF2.0 was *not* second
generation of SPF, it was hijacking to a completely different usage and
meaning (PRA))

[John L]

Post by John Levine
Yeah. Too bad that among SPF's many flaws is that it completely
confuses the HELO domain and the MAIL FROM domain

No it does not. It checks each independently. See my previous post to your
question.

Could you show me the SPF records I would use to indicate that
mta.example,com is valid as an EHLO but not as a bounce address domain
while example.com is a valid bounce address domain but not an EHLO. If
it'll help, assume they both have an A record of 12.34.56.78.

Post by John Levine
(and on a bad day,
the domains in From:, Sender:, Resent-From:, and Resent-Sender:.)

SPF never does that, please do not confuse PRA with SPF.

In real life, lots of people use SPF records for PRA, and there was a loud
debate before coming to a consensus that the alternative of throwing
everything away and starting over was unworkable. I sure wish the SPF
crowd had a better institutional memory.

R's,
John

[Terry Fielder]

Post by John L

Post by Terry Fielder

Post by John Levine
Yeah. Too bad that among SPF's many flaws is that it completely
confuses the HELO domain and the MAIL FROM domain

No it does not. It checks each independently. See my previous post
to your question.

Could you show me the SPF records I would use to indicate that
mta.example,com is valid as an EHLO but not as a bounce address domain
while example.com is a valid bounce address domain but not an EHLO. If
it'll help, assume they both have an A record of 12.34.56.78.

You cannot with SPFv1 (based on your assumption). You missed the point:
It doesn't matter, primarily the HELO is only checked if the MAIL FROM
fails.

A pass from the HELO or MAIL FROM results in SPF PASS status.

Post by John L

Post by Terry Fielder

Post by John Levine
(and on a bad day,
the domains in From:, Sender:, Resent-From:, and Resent-Sender:.)

SPF never does that, please do not confuse PRA with SPF.

In real life, lots of people use SPF records for PRA,

Name one ISP MSP or ISP. Small time single domain self maintained
organizational mail servers don't really count in the volume of things,
but just for the hell of it, try naming a few of those.

Post by John L
and there was a
loud debate before coming to a consensus that the alternative of
throwing everything away and starting over was unworkable. I sure wish
the SPF crowd had a better institutional memory.

I fail to see how the crowds memory has changed. Currently the SPF
council is writing the official "what is SPFv1" so then it can be
carried forth to "what should be in the successor version".

Post by John L
R's,
John

[John L]

Post by John L
Could you show me the SPF records I would use to indicate that
mta.example.com is valid as an EHLO but not as a bounce address domain
while example.com is a valid bounce address domain but not an EHLO. If
it'll help, assume they both have an A record of 12.34.56.78.

You cannot with SPFv1 (based on your assumption). You missed the point: It
doesn't matter, primarily the HELO is only checked if the MAIL FROM fails.
A pass from the HELO or MAIL FROM results in SPF PASS status.

My point, which I would have thought was obvious, is that SPF provides no
way to say that EHLO example.com or MAIL FROM:<***@mta.example.com> are
invalid. In practice, I see quite a lot of forged mail like that, and
SPF's inability to deal with it is a significant problem.

Regards,
John Levine, ***@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

[Terry Fielder]

Post by John L

Post by Terry Fielder

Post by John L
Could you show me the SPF records I would use to indicate that
mta.example.com is valid as an EHLO but not as a bounce address
domain while example.com is a valid bounce address domain but not an
EHLO. If it'll help, assume they both have an A record of 12.34.56.78.

You cannot with SPFv1 (based on your assumption). You missed the
point: It doesn't matter, primarily the HELO is only checked if the
MAIL FROM fails.
A pass from the HELO or MAIL FROM results in SPF PASS status.

My point, which I would have thought was obvious, is that SPF provides
are invalid. In practice, I see quite a lot of forged mail like that,
and SPF's inability to deal with it is a significant problem.

Yes, and if people could write the final version the first time then,
well, they wouldn't need versions, would they.

It's not that you don't want SPF, you just want it to do more. Stay on
board, there are good things coming once they get past the SPFv1 spec.

Terry

Post by John L
Regards,
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

[wayne]

Post by John L

Post by Terry Fielder

Post by John Levine
Yeah. Too bad that among SPF's many flaws is that it completely
confuses the HELO domain and the MAIL FROM domain

No it does not. It checks each independently. See my previous post
to your question.

Could you show me the SPF records I would use to indicate that
mta.example,com is valid as an EHLO but not as a bounce address domain
while example.com is a valid bounce address domain but not an EHLO.
If it'll help, assume they both have an A record of 12.34.56.78.

I'll start off by not answering your quesiton. ;-)

Personally, I would recommend just publishing these SPF records:

example.com TXT "v=spf a -all"
mta.example.com TXT "v=spf a -all"

If you trust the host 12.34.56.78 enough to authorize it to use both
the example.com and mta.example.com domain names, why wouldn't you
trust it enough to use them in the right context?


Ok, now I'll actually answer your question:

example.com TXT "v=spf1 redirect=%{i}._spf.%{d}"
postmaster._spf.example.com TXT "v=spf1 -all"
*._spf.example.com TXT "v=spf1 a -all"



mta.example.com TXT "v=spf1 redirect=%{i}._spf.%{d}"
postmaster._spf.mta.example.com TXT "v=spf1 a -all"
*._spf.mta.example.com TXT "v=spf1 -all"


ugly as sin, and it means that you can't send email using the
postmaster local part, but other wise it works and is well defined
back to Dec 2003 (or earlier).


-wayne

[Terry Fielder]

Post by wayne

Post by John L

Post by Terry Fielder

Post by John Levine
Yeah. Too bad that among SPF's many flaws is that it completely
confuses the HELO domain and the MAIL FROM domain

No it does not. It checks each independently. See my previous post
to your question.

Could you show me the SPF records I would use to indicate that
mta.example,com is valid as an EHLO but not as a bounce address domain
while example.com is a valid bounce address domain but not an EHLO.
If it'll help, assume they both have an A record of 12.34.56.78.

I'll start off by not answering your quesiton. ;-)
example.com TXT "v=spf a -all"
mta.example.com TXT "v=spf a -all"
If you trust the host 12.34.56.78 enough to authorize it to use both
the example.com and mta.example.com domain names, why wouldn't you
trust it enough to use them in the right context?
example.com TXT "v=spf1 redirect=%{i}._spf.%{d}"
postmaster._spf.example.com TXT "v=spf1 -all"
*._spf.example.com TXT "v=spf1 a -all"
mta.example.com TXT "v=spf1 redirect=%{i}._spf.%{d}"
postmaster._spf.mta.example.com TXT "v=spf1 a -all"
*._spf.mta.example.com TXT "v=spf1 -all"
ugly as sin, and it means that you can't send email using the
postmaster local part, but other wise it works and is well defined
back to Dec 2003 (or earlier).

I stand corrected, it can be done with SPFv1, hats off to Wayne (and I
am going to keep this one for myself to use :)

BTW Ugly as sin is irrelevant, once setup only computers need to read
it, and it can be as ugly and cryptic as necessary, as long as *it works*.

Terry

Post by wayne
-wayne

[wayne]

Post by Terry Fielder

Post by John L
Could you show me the SPF records I would use to indicate that
mta.example,com is valid as an EHLO but not as a bounce address domain
while example.com is a valid bounce address domain but not an EHLO.

[example snipped]

I stand corrected, it can be done with SPFv1, hats off to Wayne (and I
am going to keep this one for myself to use :)

I first learned this trick from Greg Connor. I'm not sure if others
realized it could be done earlier or independantly.

Post by Terry Fielder
BTW Ugly as sin is irrelevant, once setup only computers need to read
it, and it can be as ugly and cryptic as necessary, as long as *it works*.

Yeah, but I still don't see the point. Configure your MTA to use the
right HELO domain, and configure your MTA to reject email claiming to
be from the MTA's host name, and you can just use normal SPF records.
Spammers can't abuse either name because they can't send email from
the right IP addresses.


-wayne

[Julian Mehnle]

Post by John L
Could you show me the SPF records I would use to indicate that
mta.example,com is valid as an EHLO but not as a bounce address domain
while example.com is a valid bounce address domain but not an EHLO.

You can't. The expressiveness of SPFv1 is limited in this regard.

However, SPF still effectively prevents forgery of both the "mta.example.
com" and "example.com" identities, because no MTAs except those authorized
by your SPF record(s) can use them, and those MTAs authorized by you
should be under your control.

[Julian Mehnle]

Post by John Levine
Yeah. Too bad that among SPF's many flaws is that it completely
confuses the HELO domain and the MAIL FROM domain

I agree that the combined HELO+MAILFROM semantics somewhat limit the
expressiveness of SPF, but as those semantics have been clear since the
earliest days of SPFv1, I don't think this is a significant problem.

Post by John Levine
(and on a bad day, the domains in From:, Sender:, Resent-From:, and
Resent-Sender:.)

SPF doesn't do that. Sender-ID does. Complain to Microsoft and the IESG.

[william(at)elan.net]

I wish there was a way to utilize the relatively large number of SPF records
in a technology like CSV.

We could easily write EHLO guidelines for SPF record checking and
publishing as separate document, kind of like BCP. In fact I'll
keep this in mind and bring it up on spf-discuss when things are
a little more calm from current spf-classic draft discussions.

----

BTW - while we're talking about it, here is an algorithm for you to test:

1. Check if EHLO name is delegated in DNS, if so go to #2, otherwise
skip to the end with result of UNKNOWN
2. Check if EHLO name has corresponding "A" record and if so go to #3
else go to #4
3. Check if "A" record points to the ip of SMTP client, if so result
is PASS, smile and skip to the end. Otherwise proceed to #4
4. Check if EHLO name has an SPF record. If it does, go to #5,
otherwise go to #7
5. Try to do SPF test against EHLO name and client ip.
If result is SPF pass, take it as PASS, smile and skip to the end.
If result is SPF fail, take it as FAIL and skip to the end
If result is SPF softfail, go to #6
If result is SPF neutral or something else, take it as UNKNOWN and
skip to the end
6. Check if EHLO name has one or more MX record. If it has none, then
result is FAIL, skip to the end. Otherwise result is UNKNOWN.
[If it has an MX, its good indication the name is used as domain
and not as a host - most hosts do not have assigned MX]
7. If EHLO name is not TLD then cut down the first component of the name
(i.e. for "host.example.com", cut down "host" to make it "example.com").
Take this new cut name as if it was original EHLO name and proceed to #4
8. THE END

[John Levine]

Post by william(at)elan.net
We could easily write EHLO guidelines for SPF record checking and
publishing as separate document, kind of like BCP. In fact I'll
keep this in mind and bring it up on spf-discuss when things are
a little more calm from current spf-classic draft discussions.

We could, but since you can't tell whether the list of addresses in
an SPF record is supposed to apply to the EHLO address or the MAIL FROM
address or one of the message header addresses, what's the point?

The domain names in my EHLOs is completely disjoint from the set in my
MAIL FROM and mail headers. How is SPF going to handle that?

[wayne]

Post by John Levine

Post by william(at)elan.net
We could easily write EHLO guidelines for SPF record checking and
publishing as separate document, kind of like BCP. In fact I'll
keep this in mind and bring it up on spf-discuss when things are
a little more calm from current spf-classic draft discussions.

We could, but since you can't tell whether the list of addresses in
an SPF record is supposed to apply to the EHLO address or the MAIL FROM
address or one of the message header addresses, what's the point?

While far from perfect, it is possible to check the local part to see
if it is "postmaster" and use that to distinguish between HELO and
MAIL FROM. In order for this to strictly work, you can't send email
using postmaster from hosts that you have these kinds of SPF checks.

So, you could say:

example.com TXT "v=spf1 redirect=%{l}._spf.%{d}"
postmaster.example.com TXT "v=spf1 ... HELO policy ..."
*.example.com TXT "v=spf1 ... MAIL FROM policy ..."

Yes, this very ugly. Yes, if the designers of SPF knew two years ago
what we know today, we would have done a lot of things differently.
Lacking a time machine, we are kind of stuck with the semantics of
SPFv1 records.


-wayne

[Terry Fielder]

Post by John Levine

Post by william(at)elan.net
We could easily write EHLO guidelines for SPF record checking and
publishing as separate document, kind of like BCP. In fact I'll
keep this in mind and bring it up on spf-discuss when things are
a little more calm from current spf-classic draft discussions.

We could, but since you can't tell whether the list of addresses in
an SPF record is supposed to apply to the EHLO address or the MAIL FROM
address or one of the message header addresses, what's the point?

Read on to see the point.

Post by John Levine
The domain names in my EHLOs is completely disjoint from the set in my
MAIL FROM and mail headers. How is SPF going to handle that?

I believe you will find that the EHLO/HELO is only checked if the MAIL
FROM fails. I think I have heard of other implementations where:
If the EHLO fails, you check the MAIL FROM, and if that passes then it
gets an SPF pass.

Either way, it doesn't matter if your EHLO fails (it does on many, maybe
even MOST systems), because as long as your MAIL FROM is SPF PASS, then
your mails SPF response on the whole is a PASS, and is not negatively
affected.

PS This is from memory, one of the developers are better qualified to
answer this question, if you don't trust my answer, but the
generalization is at least correct, AFAICT.

When it comes time to using the authorization to compare to domain
black/white listing, then the MAIL FROM domain and the EHLO/HELO domain
could be used as a query to the lists. So THEN a bad reputation of
either the domain in your MAIL FROM or your EHLO/HELO could give you a
bad score later down the line in SA or the like. But I don't think
anyone is doing that, if for no other reason then because there are no
ways of confirming the email is from the domain it claims until SPF is
deployed.



Terry

[william(at)elan.net]

Post by John Levine
The domain names in my EHLOs is completely disjoint from the set in my
MAIL FROM and mail headers. How is SPF going to handle that?

I believe you will find that the EHLO/HELO is only checked if the MAIL FROM
fails.

Why? Doing EHLO check is useful no matter if MAILFROM fails or passes!
And it does not make any sense to delay it until MAILFROM when EHLO is
the first identity parameter email server receives and this identity
that has very few failure cases with SPF (unlike MAILFROM)

Also note that MAILFROM identity corresponds to original recipient
(unless every forwarder starts using SRS and you change its semantics,
but that is unlikely) where as EHLO name corresponds to the mail system.
As John proper said, they are disjoint and should not be mixed.

If the EHLO fails, you check the MAIL FROM, and if that passes then it gets
an SPF pass.

Unless I'm mistaken SPF pass is specific per scope/identity checked and
there is no overall SPF pass.

Either way, it doesn't matter if your EHLO fails (it does on many, maybe even
MOST systems), because as long as your MAIL FROM is SPF PASS, then your mails
SPF response on the whole is a PASS, and is not negatively affected.
PS This is from memory, one of the developers are better qualified to answer
this question, if you don't trust my answer, but the generalization is at
least correct, AFAICT.
When it comes time to using the authorization to compare to domain
black/white listing, then the MAIL FROM domain and the EHLO/HELO domain could
be used as a query to the lists.

You should not query different identities on the same reputation service,
I believe that is a possibility for unpredictable and incorrect results
and reputation systems must be setup for each specific identity in question.

----

BTW, for those who do not participate at spf-discuss and don't know -
I'm writing paper on email identities and how they are used in path and
cryptographic authentication methods (i.e LMAP and MASS) for anti-spoofing
protection. This is very much on the topic of what has been discussed here
and on ietf-smtp about good and bad points of each proposal.

You can find the latest public draft at:

http://www.elan.net/~william/emailsecurity/path_and_cryptographic_authentication-draft-limited-07.htm

Comments on the content, especially if I got anything wrong are appreciated.

[Terry Fielder]

Post by william(at)elan.net

Post by Terry Fielder

Post by John Levine
The domain names in my EHLOs is completely disjoint from the set in my
MAIL FROM and mail headers. How is SPF going to handle that?

I believe you will find that the EHLO/HELO is only checked if the MAIL
FROM fails.

Why? Doing EHLO check is useful no matter if MAILFROM fails or passes!
And it does not make any sense to delay it until MAILFROM when EHLO is
the first identity parameter email server receives and this identity
that has very few failure cases with SPF (unlike MAILFROM)

Right, I fell into the the JL trap of thinking that the two domains had
to be the same and yet represent something different. But if its a
relay server, the HELO *will* be different and consequently *will* use a
different SPF record (if one exists).

Post by william(at)elan.net
Also note that MAILFROM identity corresponds to original recipient
(unless every forwarder starts using SRS and you change its semantics,
but that is unlikely) where as EHLO name corresponds to the mail system.
As John proper said, they are disjoint and should not be mixed.

Post by Terry Fielder
If the EHLO fails, you check the MAIL FROM, and if that passes then it
gets an SPF pass.

Unless I'm mistaken SPF pass is specific per scope/identity checked and
there is no overall SPF pass.

That was not my understanding, but I accept being corrected if that's
the case.

Post by william(at)elan.net

Post by Terry Fielder
Either way, it doesn't matter if your EHLO fails (it does on many,
maybe even MOST systems), because as long as your MAIL FROM is SPF
PASS, then your mails SPF response on the whole is a PASS, and is not
negatively affected.
PS This is from memory, one of the developers are better qualified to
answer this question, if you don't trust my answer, but the
generalization is at least correct, AFAICT.
When it comes time to using the authorization to compare to domain
black/white listing, then the MAIL FROM domain and the EHLO/HELO
domain could be used as a query to the lists.

You should not query different identities on the same reputation service,
I believe that is a possibility for unpredictable and incorrect results
and reputation systems must be setup for each specific identity in question.

I disagree, a domain may authorize RELAY.com to relay his email. But if
RELAY.com is notoroious for sending spam (from his other customers he
relays for), then when I check the HELO name I may want to reject the
mail from RELAY.com because of his bad spamming reputation even if the
"MAIL FROM" domain is SPF PASS for said relay.

Consider the case when RELAY.com is actually SPAMMER.com, and once
SPAMMER.com is black listed you want to keep blocking mail from him even
if he registers other throwaway domains to pretend his server
SPAMMER.com is relaying for. A thumbs up on the reputation of
THROWAWAY.com may want to be ignored if a thumbs down occurs for the MTA
SPAMMER.com

Post by william(at)elan.net
----
BTW, for those who do not participate at spf-discuss and don't know -
I'm writing paper on email identities and how they are used in path and
cryptographic authentication methods (i.e LMAP and MASS) for anti-spoofing
protection. This is very much on the topic of what has been discussed
here and on ietf-smtp about good and bad points of each proposal.
http://www.elan.net/~william/emailsecurity/path_and_cryptographic_authentication-draft-limited-07.htm
Comments on the content, especially if I got anything wrong are appreciated.

[Julian Mehnle]

Post by Terry Fielder

Post by william(at)elan.net
You should not query different identities on the same reputation
service, I believe that is a possibility for unpredictable and
incorrect results and reputation systems must be setup for each
specific identity in question.

William is right. You should not confuse "example.com-the-HELO-domain"
with "example.com-the-MAILFROM-domain".

You should not query "mailsenders.reputation-provider.com" for HELO
identities or "mtas.reputation-provider.com" for MAIL FROM identities.

Post by Terry Fielder
I disagree, a domain may authorize RELAY.com to relay his email. But if
RELAY.com is notoroious for sending spam (from his other customers he
relays for), then when I check the HELO name I may want to reject the
mail from RELAY.com because of his bad spamming reputation even if the
"MAIL FROM" domain is SPF PASS for said relay.

Well, this scenario is actually one of the strengths of SPF (and other
sender domain authentication methods). Even if relay.com sends a lot of
spam, if you _do_ trust them to prevent cross-user forgery[1], you may be
able to still successfully get your own legitimate mail through, because
receivers don't necessarily have to block on the relay.com MTA IP address
any more, but can assess reputation on a per-domain basis instead.

References:
1.
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01.html#cross-user-forgery

[Frank Ellermann]

Post by Terry Fielder

Post by william(at)elan.net
Unless I'm mistaken SPF pass is specific per scope/identity
checked and there is no overall SPF pass.

That was not my understanding, but I accept being corrected
if that's the case.

The only "overall" thing in the actual draft is a HELO FAIL.

Hm... or it used to be in -00, -01pre1, -01pre2, -01pre3,
-01pre4, -01pre5, but was dropped in -01pre6, -01pre7, -01.

Now that's a bug. Wayne, please fix this back, it was no
nonsense, I don't recall any debate / resolution about it.

And there was no -01pre5 vs. 01pre6 diff, and that's how I
missed it.

Not talking about HELO FAIL doesn't solve the pending HELO
PermError issue.

Without an overall HELO FAIL stuff like op=helo needs to be
checked, e.g. do we _need_ it ? It's almost what Carl wants:

http://purl.net/xyzzy/home/test/draft-spf-6-3-options-06.txt

Bye, Frank

[wayne]

Post by Frank Ellermann

Post by Terry Fielder

Post by william(at)elan.net
Unless I'm mistaken SPF pass is specific per scope/identity
checked and there is no overall SPF pass.

That was not my understanding, but I accept being corrected
if that's the case.

The only "overall" thing in the actual draft is a HELO FAIL.
Hm... or it used to be in -00, -01pre1, -01pre2, -01pre3,
-01pre4, -01pre5, but was dropped in -01pre6, -01pre7, -01.
Now that's a bug. Wayne, please fix this back, it was no
nonsense, I don't recall any debate / resolution about it.

There was debate about it. It is mentioned in the release notes.

What happened is that, as part of restoring the HELO checking from
draft-mengwong-spf-0[01], I copied that sentence into
draft-schlitt-spf-classic-00. However, that sentence was originally
part of a "RECOMMENDED algorithm", so copying that sentence caused a
change in semantics. The whole "RECOMMENDED algoright" has been
dropped. It is Receiver Policy anyway, not Sender Policy.


-wayne

[Frank Ellermann]

Post by wayne
There was debate about it.

MID ? Any _comma_ changed with the results is important. It's
only luck that I tried grep 'overall' while writing a reply to
Terry / William.

Post by wayne
It is mentioned in the release notes.

| Removed e-mail receiver policy definition on how to handle
| HELO checking. It was copied incorrectly from
| draft-mengwong-spf-01, changing its meaning.

Yes, obviously I didn't get the meaning of this part by only
reading the diff.

Post by wayne
It is Receiver Policy anyway, not Sender Policy.

Curious senders might wish to kow what the expected effect of
a HELO FAIL is. Curious implementors might also wish to know
what to do in this case. And if curious admins like Terry
consider to test MAIL FROM before HELO they waste time if it
is a HELO FAIL.

No receiver policy in the spec. is fine, but please don't get
carried away. For a "who knows what the effect might be" text
100 KB are rather long, and there are already good PRG RfCs
not using DNS at all.
Bye, Frank

<http://mid.gmane.org/***@xyzzy.claranet.de>
<http://mid.gmane.org/***@xyzzy.claranet.de>

[Julian Mehnle]

Post by John Levine
We could, but since you can't tell whether the list of addresses in
an SPF record is supposed to apply to the EHLO address or the MAIL FROM
address or one of the message header addresses, what's the point?

If it starts with "v=spf1", its semantics is defined in draft-schlitt-spf-
classic, which, in a long tradition, defines such records to apply both to
the HELO/EHLO and MAIL FROM identites, and no others.

Post by John Levine
The domain names in my EHLOs is completely disjoint from the set in my
MAIL FROM and mail headers. How is SPF going to handle that?

Great! If you are using separate sets of domains for HELO/EHLO and MAIL
FROM, you can use separate SPF records for each of them. Problem solved.

[Frank Ellermann]

Post by John Levine
The domain names in my EHLOs is completely disjoint from the
set in my MAIL FROM and mail headers. How is SPF going to
handle that?

Different FQDNs have different policies (for a HELO FQDN it's
generally possible to arrange things so that it's different
from MAIL FROM FQDNs)

That's exactly what Carl wants, use a _simple_ policy for the
HELO FQDN. Or convince him to test CSV, and use CSV. Or do
both, then he can do whatever pleases him. For a HELO FQDN
"v=spf1 a -all" should be generally good enough. Bye, Frank

[Mark]

Post by Sukhenko, Alex
-----Original Message-----
Sent: donderdag 26 mei 2005 19:12
Subject: Re: SPF PASS (was: "If you believe that the SPF
concept is fundam entally flawed, please subscribe at
http://www.imc.org/ietf-mxcomp/")
The domain names in my EHLOs is completely disjoint from the set in my
MAIL FROM and mail headers. How is SPF going to handle that?

Typically, HELO/EHLO is only used in the special case of MAIL FROM: <>, so
to have the SPF client check against ***@HELO. Since there is no
MAIL FROM identity to protect in case of an empty envelope-from, it would
suffice to just publish this simple SPF record (BIND style) for your
completely disjoint HELO/EHLO name:

completelydisjoint.mydomain.com. TXT "v=spf1 a -all"

That will ensure, that in the case of a DSN, your own mailer is always
authorized (and no one else!). That easy.

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

[Hector Santos]

----- Original Message -----
From: "Carl Hutzler" <***@aol.com>
Sent: Thursday, May 26, 2005 11:39 AM
Subject: Re: SPF PASS

Post by Carl Hutzler
I wish there was a way to utilize the relatively large number of SPF
records in a technology like CSV.
-Carl

The basic issue with all of this is not a specific methodology can work or
not work, but rather the basic fact that none of it can be enforced.

So even if all the kinks were solved in SPF, CSV, FUZZ, ABC or what have
you, SMTP developers, such as yourself, myself and others will still be
stuck with still ACCEPTING the non-compliant senders and/or dealing with
legacy issues.

It doesn't make sense. The only, and I mean only reason I implemented SPF
was two reasons:

1) AOL.COM announced support from a domain standpoint. AOL being one of the
greatest sources of spam (spoofed or otherwise), we need something from AOL
to help all the other victim systems. So once AOL.COM announce SPF support
by publishing a SPF domain, we immediately started to implement SPF, and
guess what, the AOL announcement also made MICROSOFT jump and in my view,
was the reason MARID eventually started

2) SPF would be part of a suite of other methods, in particular ONE method
that has no dependency with "new" information being available - this is the
CBV, the call back verifier.

The CBV is 100% based on the idea that "ok, we don't have much to go on, but
at the VERY least, from a SMTP BOUNCE compliancy standpoint, the return
path must be valid. It may be spoofed, it may be a zombie, but it must be
valid. It can not be junk."

So we explored the CBV. I am not saying it is the "answer" but what it
proved was one fundamental aspect of the problem we are trying to address:

That indeed, the majority, by atleast 60-80% of all transactions
are non-compliant from a SMTP standpoint.

Period. No ands, ifs or butts. And it should not be a SURPRISE to anyone
because it is the reason why we have the problem in the first place.

So what's missing from the process?

We need an anchor that exist today to address the backward compatibility
issue. We don't really have a consensus on what uniquely identifies a MAIL
sender or machine that is part of a mail domain.

So we can debate, argue left and right, we are still left with the same old
issue on how to address backward compatibility.

Until someone can address this, all the proposals are for the most part
worthless.

This is the secret the spammers don't want us to discover and realize,
because until we do, they have no reason for them to change or adapt.

SPF can work if everyone was forced to use SUBMITTER like idea to address
the transitional domain/ip changes.

CSV can work if everyone was forced to use reliable client domain name.

etc, etc, but as long as it is not "REQUIRED" or enforceable, it is all
worthless.

So Carl, how can we enforce these proposals? How do I enforce CSV support?

No, I am not encouraging "POLICY" discussions. I am talking about how can
we automate the framework of a mixed hetergeneous network of systems?

I have a few ideas.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

[Carl Hutzler]

Post by Hector Santos
----- Original Message -----
Sent: Thursday, May 26, 2005 11:39 AM
Subject: Re: SPF PASS

Post by Carl Hutzler
I wish there was a way to utilize the relatively large number of SPF
records in a technology like CSV.
-Carl

The basic issue with all of this is not a specific methodology can work or
not work, but rather the basic fact that none of it can be enforced.
So even if all the kinks were solved in SPF, CSV, FUZZ, ABC or what have
you, SMTP developers, such as yourself, myself and others will still be
stuck with still ACCEPTING the non-compliant senders and/or dealing with
legacy issues.
It doesn't make sense. The only, and I mean only reason I implemented SPF
1) AOL.COM announced support from a domain standpoint. AOL being one of the
greatest sources of spam (spoofed or otherwise), we need something from AOL
to help all the other victim systems. So once AOL.COM announce SPF support
by publishing a SPF domain, we immediately started to implement SPF, and
guess what, the AOL announcement also made MICROSOFT jump and in my view,
was the reason MARID eventually started
2) SPF would be part of a suite of other methods, in particular ONE method
that has no dependency with "new" information being available - this is the
CBV, the call back verifier.
The CBV is 100% based on the idea that "ok, we don't have much to go on, but
at the VERY least, from a SMTP BOUNCE compliancy standpoint, the return
path must be valid. It may be spoofed, it may be a zombie, but it must be
valid. It can not be junk."
So we explored the CBV. I am not saying it is the "answer" but what it
That indeed, the majority, by atleast 60-80% of all transactions
are non-compliant from a SMTP standpoint.
Period. No ands, ifs or butts. And it should not be a SURPRISE to anyone
because it is the reason why we have the problem in the first place.
So what's missing from the process?
We need an anchor that exist today to address the backward compatibility
issue. We don't really have a consensus on what uniquely identifies a MAIL
sender or machine that is part of a mail domain.
So we can debate, argue left and right, we are still left with the same old
issue on how to address backward compatibility.
Until someone can address this, all the proposals are for the most part
worthless.
This is the secret the spammers don't want us to discover and realize,
because until we do, they have no reason for them to change or adapt.
SPF can work if everyone was forced to use SUBMITTER like idea to address
the transitional domain/ip changes.
CSV can work if everyone was forced to use reliable client domain name.
etc, etc, but as long as it is not "REQUIRED" or enforceable, it is all
worthless.
So Carl, how can we enforce these proposals? How do I enforce CSV support?
No, I am not encouraging "POLICY" discussions. I am talking about how can
we automate the framework of a mixed hetergeneous network of systems?
I have a few ideas.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

So if AOL began doing CSV, then everyone would follow? Hmmm, it might
help, but not sure that's a given.

[John Glube]

|-----Original Message-----
|From: owner-ietf-***@mail.imc.org
[mailto:owner-ietf-|***@mail.imc.org] On Behalf Of Carl
Hutzler
|Sent: May 26, 2005 4:08 PM
|To: ***@santronics.com
|Cc: ***@elan.net; Andrew Newton; ietf-***@imc.org
|Subject: Re: Addressing Backward Compatibility [was Re: SPF
|PASS]
|
|<snip>
|
|So if AOL began doing CSV, then everyone would follow?
|Hmmm, it might help, but not sure that's a given.

Possibly. However, if AOL were to say those senders who are
white listed, or who are applying to be white listed with
AOL something like:

As part of its ongoing efforts to improve network security
and its user's experience, AOL is implementing Certified
Server Validation (CSV). We urge all bulk mailers and
internet access services who are presently white listed
with AOL or who are seeking white listing status with AOL
to review this protocol and take the appropriate
implementation steps. For more details:

<http://www.mipassoc.org/csv/index.html>

At the same time, let it be known within the ISP and
marketing industries:

* We are implementing Certified Server Validation (CSV).
We encourage all bulk mailers and internet access services
sending mail to AOL to also implement CSV as appropriate.

Presuming you are satisfied that CSV does what you want:

* Set up a 'special' white list for those senders who have
published CSV records and indicate you plan to merge this
with your 'special' white list for those senders who have
published SPF records.

I believe that would get the ball rolling. As the saying goes,
"your wish is my command" :-)

John

John Glube
Toronto, Canada

[Frank Ellermann]

Post by Carl Hutzler
I wish there was a way to utilize the relatively large number
of SPF records in a technology like CSV.

You could try the SIQ-idea: input IP and FQDN, output PASS,
FAIL, or DUNNO. The SIQ-server checks CSV and if n/a SPF to
create its (IP, FQDN, result, TTL) HELO-tuples.

If the SIQ-server is forced to use SPF (no CSV) to create its
records it could ignore all policies with the vague qualifiers
? or ~, and it could also ignore all "expensive" SPF policies,
anything with mx, ptr, include could be defined as "forget it,
too expensive for a simple HELO test".

So you only look at +/-a +/-ip4, +/-ip6, +/-all. I'm not sure
about "mx" and "exists", a dedicated SIQ-server could have
enough time to evaluate these mechanisms. Bye, Frank

P.S., you better add MTAMARK before CSV before restricted SPF

[Scott Kitterman]

Post by Sukhenko, Alex
-----Original Message-----
Sent: Thursday, May 26, 2005 11:40 AM
Subject: Re: SPF PASS (was: "If you believe that the SPF concept is
fundam entally flawed, please subscribe at
http://www.imc.org/ietf-mxcomp/")
I wish there was a way to utilize the relatively large number of SPF
records in a technology like CSV.
-Carl

What would be the advantage, from your perspective, to doing that instead of
using the HELO checking approach already defined in SPF?

Scott Kitterman

[Carl Hutzler]

Post by Scott Kitterman

Post by Sukhenko, Alex
-----Original Message-----
Sent: Thursday, May 26, 2005 11:40 AM
Subject: Re: SPF PASS (was: "If you believe that the SPF concept is
fundam entally flawed, please subscribe at
http://www.imc.org/ietf-mxcomp/")
I wish there was a way to utilize the relatively large number of SPF
records in a technology like CSV.
-Carl

What would be the advantage, from your perspective, to doing that instead of
using the HELO checking approach already defined in SPF?
Scott Kitterman

Never even knew there was helo checking in SPF. I might have to do some
reading. My bad!

[Sauer, Damon]

<snip>

Post by Terry Fielder
I stand corrected, it can be done with SPFv1, hats off to Wayne (and I
am going to keep this one for myself to use :)
BTW Ugly as sin is irrelevant, once setup only computers
need to read
it, and it can be as ugly and cryptic as necessary, as long
as *it works*.
Terry

And I am going to keep this one for the next time I have to explain my
perl code :P

I guess nobody remembers programming on a Commodore? :D


Regards,
Damon Sauer

*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162

[Hallam-Baker, Phillip]

Post by Carl Hutzler
Never even knew there was helo checking in SPF. I might have
to do some reading. My bad!

It was in at the very start, then it got taken out, then it got put back
in again.

I think that there had been some discussion about putting HELO checking
back in before your comment at the FTC but after that event it became a
no-brainer. First there was a major ISP that found that the check had
value, second there was absolutely no point in having a standards war
over how people make use of SPF records when there is precisely nothing
the sender can or should be able to do to dictate how the information is
interpreted.

I think that all this discussion and techno-politics have caused folk to
loose sight of the fact that all we are doing here is providing the
receiver with information that might help a recipient decide that he
really wants to accept a piece of email.

[Hector Santos]

----- Original Message -----
From: "Hallam-Baker, Phillip" <***@verisign.com>
To: "Carl Hutzler" <***@aol.com>; <***@kitterman.com>
Sent: Saturday, May 28, 2005 12:25 AM
Subject: RE: SPF PASS (was: "If you believe that the SPF concept is fundam
entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/")

Post by Hallam-Baker, Phillip

Post by Carl Hutzler
Never even knew there was helo checking in SPF. I might have
to do some reading. My bad!

It was in at the very start, then it got taken out, then it got put back
in again.

And I guess, in regards to SPF, I was probably had most of the blame for the
debate surrounding this.

The issue started with DMP which SPF is based on.

DMP has a return path domain check and a HELO client domain (CD) logic:

Check Return Path Domain
if not pass then check Client Domain

When we implemented DMP, it protected our local domains spoofing when the
client tried to emulate a internal network client.

DMP was extremely simple to explore and implement. Then SPF came along, it
was more complex. Not sure of what direction it will take, we held off on
it. Once AOL.COM announced support, we began to implement it.

SPF had a HELO check but only when the Return Path was NULL

if Return Path is NULL
check Client Domain
else
check Return Path

Once SPF was implemented, DMP was deprecated. Almost immediately, we began
to see spam from clients spoofing our HELO client domain once protected by
DMP coming in. It was fairly obvious that the above logic of only checking
the HELO domain when the return path was null was not only illogical, it
allowed for a spammer loophole into the spec.

So I argued for a SPF helo check as well regardless if the return path was
null or not.

However, by this point, the other implementation issues of DNS based
proposals was becoming more obvious - DNS overhead of open-ended lookups.

So I understood that there was a concern for redundant checks and given the
fact that traditionally the client domain can not relied upon for being
correct, my suggestion was to make it optional for implementators but more
importantly, I wanted to highlight that the best protection the LMAP
protocol had to offer was the protection of local domains (your own). The
LMAP results of local domains are more trusted. You can't trust the results
of remote domains.

Meng and others were not sure which way to go. I thought it was simple
issue to realize and important be considerd. It simply can't be ignored.

But at the very least, all systems should perform a local domain check and
in the final analysis, as we have it today, local domain/IP matching can be
done internally and more efficiently. We call it DIP rules (DOMAIN/IP) that
is part of our White/Black list filtering before any DNS-based protocol is
triggered.

In addition, for our implementation, we provided an optional list file to
define domains that should be check for SPF client domain names.

So we leave it to the administrator as to how much checking he wants to do.

The point is basically HELO is important to consider and possibly with the
introduction of CSV emphasizing client domain checking, maybe Meng and et
decided that it is important to have as well, if only for "competitive"
reasons.

My argument has always been that if we use a Return Path Domain checking
concepts, then this presumes a compliant client. Therefore, it is a new
system, and therefore it should never have a invalid HELO client domain
name.

My assertion has been that it would be illogical to have a SPF return path
domain and an non-SPF client domain name. Not possible without something
being wrong with the setup, a malicious transaction or a hetergenous
topology of mixed systems.

result1 := LMAP(ReturnPath, IP)
result2 := LMAP(ClientDomain, IP)

These mixed policies MUST be consistent (pass or fail) in order for it to
work. Its part of the "chain of trust" methodology.

I tried to illustrate this point in:

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

A quick example would be:

HELO: localdomain
MAIL FROM: remotedomain

Which basically says, that if the MAIL FROM domain is remote (meaning, not
yours), then having a local domain for HELO is a LMAP violation.

In addition, I went further to show that "automated decisions", overhead is
further reduced by taken into account a vital piece of the transaction
parameters - the forwarding path (RCPT TO).

if RCPT is remote then
Standard Authentication Required
else Rcpt is Local and Not Authenticated Session
then check LMAP

Anyway, this is what DMP protected. SPF lost focus with HELO with its NULL
only rule. The above example is very typical spoofing transaction, about
12% of our total transactions where clients are trying to "fake" the server
into thinking it is a internal network machine.

In short, if HELO says

xxxx.winserver.com
xxxx.santronics.com

then the IP better be within our IP network, regardless of what the MAIL
FROM says.

So HELO checking is important and is part of the total scheme of things.
But it can't be used by itself like CSV advocates.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Post by Hallam-Baker, Phillip
I think that there had been some discussion about putting HELO checking
back in before your comment at the FTC but after that event it became a
no-brainer. First there was a major ISP that found that the check had
value, second there was absolutely no point in having a standards war
over how people make use of SPF records when there is precisely nothing
the sender can or should be able to do to dictate how the information is
interpreted.
I think that all this discussion and techno-politics have caused folk to
loose sight of the fact that all we are doing here is providing the
receiver with information that might help a recipient decide that he
really wants to accept a piece of email.

[Frank Ellermann]

Hector Santos wrote:

[HELO test]

Post by Hector Santos
And I guess, in regards to SPF, I was probably had most of
the blame for the debate surrounding this.

[...]

In one SPF Council meeting Meng wrote "Hector hectored us"
(or similar), it sounded more like praise than blame. IIRC
it was the s/MAY/SHOULD/ meeting.
Bye, Frank