SPF and SenderID

What should I do now? Is there a way of supporting SPF
without helping to get a patented technology established
on the Internet?

Sure.

MS pretends to control spf2.0/pra to a certain degree, as
defined in draft-lyon-senderid-pra-01

They certainly don't control all of spf2.0, as defined in
draft-lyon-senderid-core-01

They never controlled a single bit of v=spf1 as defined
in draft-schlitt-spf-classic-01

As long as you don't want PRA this doesn't affect you,
v=spf1 is an open standard (wannabe from the IETF's POV,
there's yet no RfC for it).

MS tried to pull the stunt that v=spf1 is by default a
part of PRA. This is a lie, the IESG knows that it's a
lie, so senderid-lyon-core-01 can never pass as an RfC.

Bye, Frank (Cc: mxcomp)

-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1449865&user_secret=615bee79

Frank Ellermann

2005-06-15 08:41:18 UTC

What should I do now? Is there a way of supporting SPF
without helping to get a patented technology established
on the Internet?

Douglas Otis

2005-06-15 14:29:49 UTC

What should I do now? Is there a way of supporting SPF
without helping to get a patented technology established
on the Internet?

This advice is based upon a false impression that Microsoft waits for an
RFC before producing product. Recall draft-leach-cifs-v1-spec-02.txt?
Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to
Sender-ID.

-Doug

Michael Hammer

2005-06-15 15:11:42 UTC

Post by Douglas Otis
This advice is based upon a false impression that Microsoft waits for an
RFC before producing product. Recall draft-leach-cifs-v1-spec-02.txt?
Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to
Sender-ID.

Doug,

This is exactly what Microsoft wants people to do.

The correct action is for someone to force MS to back off (SPF
Council, FTC, IETF,EU...anyone listening) from what is essentially a
move to squash SPF. This could certainly be construed as an
anti-competitive action.

spf2.0/PRA lost in the marketplace. People simply weren't publishing
the records. People were publishing spf1 records at a significant rate
given that it wasn't even an "approved" standard. So, what better way
to cause problems for SPF AND co-opt the spf1 records that people were
publishing.

You don't resolve an issue of someone doing a wrong thing by giving in
through a work around that gives validation to the publication of
"their" (SPF2.0) record.

This also begs the question of who controls the SPF record format. Can
anyone come up with their own mechanisms willy-nilly? Does the SPF
Council control SPF? If not, who does? What about spf3.x and forward?

As usual, just my 2 cents.

Mike

wayne

2005-06-15 16:04:04 UTC

Post by Michael Hammer
This also begs the question of who controls the SPF record format. Can
anyone come up with their own mechanisms willy-nilly? Does the SPF
Council control SPF? If not, who does? What about spf3.x and forward?

By submitting the SPF and SID drafts to the IETF, all of us have
accepted that the IETF has a great deal of control over the spec. The
IESG has said that, in order to be fair to SID and not show favoritism
to SPF, both the SPF and SID drafts can say whatever they want about
the use of SPFv1 records and that the SPF draft will be held back
until the SID drafts are ready. Also, in order to be fair to SID, the
IESG is discounting the 1.5 years of deployment experience with SPF so
that both SPF and SID can start collecting deployment information now.
OK, I can't start collecting data now, because the IESG refuses to
tell me what kind of data they want to see. I'm sure this is to be
fair to SID.

Yes, the IESG is being very even handed and fair.

</heavy sarcasm>

For a slightly more realistic/accurate view of what the IESG actually
said, see: http://thread.gmane.org/gmane.mail.spam.spf.council/312

-wayne

Frank Ellermann

2005-06-15 17:34:49 UTC

Post by wayne
Yes, the IESG is being very even handed and fair.
</heavy sarcasm>

This case of excessive technical incomptence or outright
corruption is so far limited to _one_ member of the IESG.

Bye, Frank

Arnt Gulbrandsen

2005-06-15 18:17:15 UTC

This case of excessive technical incomptence or outright corruption is
so far limited to _one_ member of the IESG.

Just a question: Does that IESG member happen to think that SPF suffers
from poor workmanship?

Arnt

wayne

2005-06-15 19:14:47 UTC

Post by Arnt Gulbrandsen
Just a question: Does that IESG member happen to think that SPF
suffers from poor workmanship?

I have heard no such direct comment on the "workmanship". I suspect
that many people in the IESG, like many others outside, find the
subject of MTA Authorization Records In DNS (MARID) to be a
controversial subject.

I think David Kessens comments indicate that he doesn't particularly
like SPF:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=30894

Russ Housley echos those concerns:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=31013

Harald Alvestrand seems to think that the wordsmithing, at least, is
pretty good:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=30972

It might be best to look at the entire datatracker for SPF:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0

-wayne

william(at)elan.net

2005-06-15 20:47:53 UTC

This case of excessive technical incomptence or outright corruption is so
far limited to _one_ member of the IESG.

Just a question: Does that IESG member happen to think that SPF suffers from
poor workmanship?

I think it was quite clear that IESG wording had nothing to do with
technical merits of the proposal(s) and was due to political pressure.
And that is what worries me that IETF/IESG could be manipulated like that.

--
William Leibzon
Elan Networks
***@elan.net

Frank Ellermann

2005-06-16 03:15:27 UTC

Does that IESG member happen to think that SPF suffers from
poor workmanship?

That person changed [yes] to [discuss] after he found out that
his removal of one critical "NOT RECOMMENDED" against the PRA-
abuse doesn't fly with the SPF community. That person did not
propose to remove the offending "SHOULD abuse v=spf1" from PRA.

Bye, Frank

Ted Hardie

2005-06-16 17:39:52 UTC

Does that IESG member happen to think that SPF suffers from
poor workmanship?

All changes to the state of document are noted in a public ID tracker.
The URL for the tracker details for the SPF document is:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0

A sponsoring AD always has a ballot position of YES when they bring
a document to the IESG. Sponsoring ADs often put in what are called
"placeholder DISCUSS" comments when there are issues raised outside
of the IESG (since those would otherwise not be tracked). Those
should have explanatory text. In this case,the explanatory text is:

"Further discussion on the intended status and relationship to
MARID working group needed."

This was entered to track the fact that the IESG needed to discuss
Wayne's comments
on the disconnect between his intentions as author and the original
draft solicited
after MARID closed (draft-lentczner). This discussion has continued
through Wayne's
request that the spf draft be considered for Proposed Standard,
rather than Experimental.
It also encompasses the problems raised by forwarding both documents; these
were raised both within and outside the IESG, and the IESG had discussed them
at great length.

As was documented on the IETF list response to Wayne, there was no support for
at this time for publishing the spf draft as a Proposed Standard (to
be clear: the
IESG was asked this question at a telechat, and no AD thought it was
appropriate).

The IESG is currently considering moving forward on the basis of an IESG note
suggested by David Kessens. Once the IESG agrees that the document set
is ready, the sponsoring AD position will go back to YES. For those who find

Post by Frank Ellermann
The following documents (draft-schlitt-spf-classic, draft-katz-submitter,
draft-lyon-senderid-core, draft-lyon-senderid-pra) are published
simultaneously
as Experimental RFCs, although there is no general technical
consensus and efforts to reconcile the two approaches
have failed. As such these documents have not received full IETF review
and are published "AS-IS" to document the different approaches as
they were considered in the MARID working group.
The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach
and concerns about using them in tandem. The IESG
believes that documenting the different approaches does less harm
than not documenting them.
The community is invited to observe the success or failure of the
two approaches during the two years following publication, in
order that a community consensus can be reached in the future.

The document names would be replaced by RFC numbers by the RFC Editor.
All other instructions to the RFC Editor (that is, all the text
trying to reconcile
the two) has been removed.

There has been a lot of discussion of this draft, and this short
summary no doubt
misses some points, but I hope it clarifies the current state at
least somewhat.
regards,
Ted Hardie

william(at)elan.net

2005-06-16 19:47:27 UTC

Post by Ted Hardie
A sponsoring AD always has a ballot position of YES when they bring
a document to the IESG.

I don't think it is always. I will check datatracker more but I've
definitely seen no objections from everyone including sponsoring AD
for some documents (especially individual submissions for information
or experimental track).

Post by Ted Hardie
As was documented on the IETF list response to Wayne, there was no support
for at this time for publishing the spf draft as a Proposed Standard (to
be clear: the IESG was asked this question at a telechat, and no AD
thought it was appropriate).

Could you be more specific on which day this telechat happened and if
the logs/brief summary for it are available?

Post by Ted Hardie
The IESG is currently considering moving forward on the basis of an IESG note
suggested by David Kessens. Once the IESG agrees that the document set
is ready, the sponsoring AD position will go back to YES.

...

Post by Ted Hardie

Post by Frank Ellermann
The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach

I'd appreciate if you discussed more rational that went behind your note
and its text. I do understand that IETF does not wish to take position on
if authenticating PRA or MAILFROM identities is better choice for email.
This is not new and its one of the reason that MARID probably failed as
such decision may not have been something that we could easily find
consensus on. But it seems to me taking not position on above is different
then the note that you propose to add to the drafts.

Also it appears to me the IESG criteria for when evaluating documents
(especially for experimental status) is not necessarily to see if certain
approach is good or bad for internet future but more importantly to make
sure that proposal would not directly create problems for something else
being done at IETF and most important to make sure that the proposal does
not cause people to violate existing standards. So is my understanding
about this being part of IESG evaluation wrong?

Post by Ted Hardie
There has been a lot of discussion of this draft, and this short summary no
doubt misses some points, but I hope it clarifies the current state at
least somewhat

It clarified some things but as often fr short summaries it raised more
questions. I'd appreciate if you could find more time to discuss the
drafts and how IESG evaluation of them went.

--
William Leibzon
Elan Networks
***@elan.net

Ted Hardie

2005-06-16 21:27:42 UTC

Post by william(at)elan.net

Post by Ted Hardie
A sponsoring AD always has a ballot position of YES when they bring
a document to the IESG.

There are two types of Information and Experimental documents; those
which are sponsored by an AD and those which come from the RFC Editor
to be checked for conflict with IETF work. In the latter case, you may
well see blank spaces, all no-objections, or similar. In the former case,
it might happen that something does not have a Yes because of something
like a Last Call comment to be resolved simultaneously with IESG review,
but it is unusual and considered as a "yes-->placeholder" collapsed.

The IESG also asks different questions for the two tracks, because there
is a set of IESG Notes automatically added to RFC Editor-sponsored documents.

Post by william(at)elan.net
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"

The review instructions for RFC Editor-sponsored Informational and

Post by william(at)elan.net
The IESG will use RFC 3932 responses: 1) The IESG has not
found any conflict between this document and IETF work; 2) The
IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing; 3) The IESG thinks
that publication is harmful to work in WG <X> and recommends
not publishing at this time; 4) The IESG thinks that this
document violates the IETF procedures for <X> and should
therefore not be published without IETF review and IESG
approval; 5) The IESG thinks that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG approval.
Other matters may be recorded in comments to be passed on
to the RFC Editor as community review of the document.

Post by Ted Hardie
As was documented on the IETF list response to Wayne, there was no
support for at this time for publishing the spf draft as a Proposed
Standard (to be clear: the IESG was asked this question at a
telechat, and no AD thought it was appropriate).

Could you be more specific on which day this telechat happened and if
the logs/brief summary for it are available?

It was the June 9th telechat; the minutes get approved at the following
telechat (a week from today), and they'll be public then. The response
to Wayne contains all the data, though: the IESG considered it, but did
not find support for it.

Post by william(at)elan.net

...

Post by Ted Hardie

Post by Frank Ellermann
The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach

Just to be clear, David Kessens proposed the note; there has been
some wordsmithing
by others, but he was the person who brought it forward. I believe David has
some basic concerns about the usability of either approach as well as concerns
about using them in tandem. I don't want to speak for David, but I think
these were not limited to the question of which identity is at issue.

Post by william(at)elan.net
Also it appears to me the IESG criteria for when evaluating
documents (especially for experimental status) is not necessarily to
see if certain approach is good or bad for internet future but more
importantly to make sure that proposal would not directly create
problems for something else being done at IETF and most important to
make sure that the proposal does not cause people to violate
existing standards. So is my understanding about this being part of
IESG evaluation wrong?

See above for the evaluation instructions.

regards,
Ted Hardie

william(at)elan.net

2005-06-17 01:02:38 UTC

Post by Ted Hardie
There are two types of Information and Experimental documents; those
which are sponsored by an AD and those which come from the RFC Editor
to be checked for conflict with IETF work. In the latter case, you may
well see blank spaces, all no-objections, or similar. In the former case,
it might happen that something does not have a Yes because of something
like a Last Call comment to be resolved simultaneously with IESG review,
but it is unusual and considered as a "yes-->placeholder" collapsed.

Thank you for your explanation.

Post by Ted Hardie
The IESG also asks different questions for the two tracks, because there
is a set of IESG Notes automatically added to RFC Editor-sponsored documents.

If I understand based on IESG notes, it appears you're unable to answer
the above question clearly. In particular that you say:
"As such these documents have not received full IETF review and
are published "AS-IS" to document the different approaches"
and:
"The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach
and concerns about using them in tandem"

Post by Ted Hardie
The review instructions for RFC Editor-sponsored Informational and

So with RFC-Editor drafts, IESG is asked to evaluate the draft for
conflict with other standards and IETF work, but not necessarily
say that it agrees with it. That is good explanation, thank you.

Nevertheless it is unclear to me why the above points would in the
same way not apply to AD-sponsored drafts. If anything it would
indicate that as initial criteria for being "sponsored" the draft
would already have to have passed all above evaluation items and is
now being considered by IETF not just as individual contribution for
documentation of existing work but as something IETF is expected to
provide some kind of approval on (even if its just for experiment).

And overall (especially after reading your new note) the situation
seems to be that SPF & SID drafts can not find approval of IESG
so while they started as sponsored work, perhaps the situation right
now (with IESG note saying that you just want it documented) is
closer to the kind of documentation one would expect with draft being
submitted through RFC-Editor. So I think it maybe more appropriately
for IESG to directly reexamine evaluation criteria for the drafts and
work with them in the say way you would work as if it were drafts
coming from RFC-Editor.

Post by Ted Hardie
Just to be clear, David Kessens proposed the note; there has been some
wordsmithing by others, but he was the person who brought it forward.
I believe David has some basic concerns about the usability of either
approach as well as concerns about using them in tandem.

The problem is not just using them "in tandem", using in tandem would mean
somebody doing both SPF and SID check on his/her system. The problem we
have is different in that both drafts attempt to rely on the same record
but use it differently, this is collision of namespaces for different
experiments and it does seem like its something that IESG should be
seriously concerned with.

Post by Ted Hardie
I don't want to speak for David, but I think
these were not limited to the question of which identity is at issue.

Is it possible to ask David to come to this list and explain more about
his concerns?

--
William Leibzon
Elan Networks
***@elan.net

johnp

2005-06-16 20:24:07 UTC

This is the relevant extract from the note suggested by David Kessens:

https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1599&filename=draft-schlitt-spf-classic

" I would have much preferred a solution that would be an extension to SMTP
that simply checks back with one of the official MTA machines as listed
in the
'mx' records for the domain whether the sending machine can be accepted,
or just one simple DNS record with the name of the machine which is capable
of doing the verification. The
resulting protocol would be much simpler as all the configuration of the
MTA doesn't need standarization as this information would not need to be
published since it is not needed by any other than the 'mx' domain.

From an operational perspective, the DNS solution also has issues since
the DNS administrator is not necessarily the same as the mail
administrator. "

------

Taking these points in turn -

Unfortunately a domain does not have to have an MX record for it to be
used for e-mail. If an A record exists, this is sufficient. Should the
IETF/IESG choose to rectify that situation, the world of e-mail would
already become an easier place to work in.

SPF does have the ability to use a simple DNS record entry which can
include the relevant detailed record from another zonefile, perhaps the
zonefile of a subdomain. This would probably be the method of choice for
large users of SPF, since it eliminates the necessity of maintaining a
lot of records in each individual domain's zonefile.

Operationally, any specialist DNS administrator will be able to
accomodate his Mail administrator counter-part by allowing access to
add, edit or remove the relevant DNS records required by SPF.

Kind regards,

John Pinkerton

Post by Ted Hardie

Does that IESG member happen to think that SPF suffers from
poor workmanship?

All changes to the state of document are noted in a public ID tracker.
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0
A sponsoring AD always has a ballot position of YES when they bring
a document to the IESG. Sponsoring ADs often put in what are called
"placeholder DISCUSS" comments when there are issues raised outside
of the IESG (since those would otherwise not be tracked). Those
"Further discussion on the intended status and relationship to
MARID working group needed."
This was entered to track the fact that the IESG needed to discuss
Wayne's comments
on the disconnect between his intentions as author and the original
draft solicited
after MARID closed (draft-lentczner). This discussion has continued
through Wayne's
request that the spf draft be considered for Proposed Standard, rather
than Experimental.
It also encompasses the problems raised by forwarding both documents; these
were raised both within and outside the IESG, and the IESG had discussed them
at great length.
As was documented on the IETF list response to Wayne, there was no support for
at this time for publishing the spf draft as a Proposed Standard (to be
clear: the
IESG was asked this question at a telechat, and no AD thought it was
appropriate).
The IESG is currently considering moving forward on the basis of an IESG note
suggested by David Kessens. Once the IESG agrees that the document set
is ready, the sponsoring AD position will go back to YES. For those who find

Post by Frank Ellermann
The following documents (draft-schlitt-spf-classic,
draft-katz-submitter,
draft-lyon-senderid-core, draft-lyon-senderid-pra) are published
simultaneously
as Experimental RFCs, although there is no general technical
consensus and efforts to reconcile the two approaches
have failed. As such these documents have not received full IETF review
and are published "AS-IS" to document the different approaches as
they were considered in the MARID working group.
The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach
and concerns about using them in tandem. The IESG
believes that documenting the different approaches does less harm
than not documenting them.
The community is invited to observe the success or failure of the
two approaches during the two years following publication, in
order that a community consensus can be reached in the future.

The document names would be replaced by RFC numbers by the RFC Editor.
All other instructions to the RFC Editor (that is, all the text trying
to reconcile
the two) has been removed.
There has been a lot of discussion of this draft, and this short summary
no doubt
misses some points, but I hope it clarifies the current state at least
somewhat.
regards,
Ted Hardie

Douglas Otis

2005-06-16 01:29:02 UTC

Post by Michael Hammer
You don't resolve an issue of someone doing a wrong thing by giving in
through a work around that gives validation to the publication of
"their" (SPF2.0) record.

For "Sender Policy Framework (SPF) for Authorizing Use of Domains in
E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt. For
"Sender ID: Authenticating E-Mail" the listed authors are J. Lyon, and
M. Wong. The "spf2.0/" record syntax was a product of the MARID WG
specifically addressing this very issue. As all the authors
participated in the MARID WG that identified this scope related problem,
and as both of these drafts also credit common authorship, it would be
impossible to say which draft is now authoritative for the "v=spf1"
record.

By excluding a solution for a known problem, how can it be said the
draft for SPF based upon the bounce-address made any attempt to avoid
this situation? At least Sender-ID accommodates use of the SPF2.0
record. On April 13, 2004 Wayne, in response to Harry Katz talked about
the use of SPF2. By August 13, Mark Lentczner announced adoption of the
"spf2.0/" instead of the "v=spf2" by the design team for the
draft-ietf-marid-protocol-01. Checking the archive, around August 19,
my email warns of the problem of assuming the PRA as a scope for the
v=spf1 record. On August 25, Meng Wong introduced the "mfrom" scope as
a solution. This was done amid growing concerns of the licensing
required by Microsoft.

It has been nearly a year to consider the impact of this problem. Only
those that don't care about the scope of the record should publish
"v=spf1". Those that care, should publish "spf2.0" records that declare
the assured scope.

-Doug

Terry Fielder

2005-06-16 02:34:00 UTC

Post by Michael Hammer
You don't resolve an issue of someone doing a wrong thing by giving in
through a work around that gives validation to the publication of
"their" (SPF2.0) record.

Point 1: agreed

Post by Douglas Otis
and as both of these drafts also credit common authorship,

Point 2 (Meng): agreed

Post by Douglas Otis
it would be
impossible to say which draft is now authoritative for the "v=spf1"
record.

Point 3: Wrong, (Point 1 and point 2 do *not* add up to point 3, but
good wordsmithing)

Post by Douglas Otis
By excluding a solution for a known problem,

Wrong again, SID is not a solution for *anything*.

Post by Douglas Otis
how can it be said the
draft for SPF based upon the bounce-address made any attempt to avoid
this situation? At least Sender-ID accommodates use of the SPF2.0
record. On April 13, 2004 Wayne, in response to Harry Katz talked about
the use of SPF2. By August 13, Mark Lentczner announced adoption of the
"spf2.0/" instead of the "v=spf2" by the design team for the
draft-ietf-marid-protocol-01. Checking the archive, around August 19,
my email warns of the problem of assuming the PRA as a scope for the
v=spf1 record. On August 25, Meng Wong introduced the "mfrom" scope as
a solution. This was done amid growing concerns of the licensing
required by Microsoft.
It has been nearly a year to consider the impact of this problem. Only
those that don't care about the scope of the record should publish
"v=spf1". Those that care, should publish "spf2.0" records that declare
the assured scope.

You are entitled to your (albeit misguided) opinion.

Terry

Post by Douglas Otis
-Doug

--
Terry Fielder
***@greatgulfhomes.com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085

Douglas Otis

2005-06-17 19:56:33 UTC

Post by Douglas Otis
For "Sender Policy Framework (SPF) for Authorizing Use of Domains in
E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt. For
"Sender ID: Authenticating E-Mail" the listed authors are J. Lyon, and
M. Wong. The "spf2.0/" record syntax was a product of the MARID WG
specifically addressing this very issue. As all the authors
participated in the MARID WG that identified this scope related problem,
and as both of these drafts also credit common authorship, it would be
impossible to say which draft is now authoritative for the "v=spf1"
record.

I would certainly agree with you that the waters have been muddied. I
have stated my opinion on that in other threads/locations so I won't
go there. The issue at hand though is whether IETF/IESG should accept
an ID (even experimental) which proposes to break the implementation
(existing) of a competing ID where the purported reason for doing so
comes down to "people won't publish the record we want (and
participate in our experiment) so we will force them to publish our
record, suffer bad outcomes or remove existing (SPF1) records all
together.
From the day of the SPF/Sender-ID merger in the interim meeting at

Qualcomm, it has been clear the SPF record would be utilized to evaluate
the PRA. Microsoft wanted to use their XML record, but the WG convinced
them to use the existing record syntax. This is why Meng Wong
eventually suggested the use of the "spf2.0/mfrom ..." record once the
licensing issue became a concern. This is history that can not be
changed. Especially by a third-party like IETF/IESG. You want the IESG
to say who made the mistake? There were so many in sequence.

Post by Douglas Otis
It has been nearly a year to consider the impact of this problem. Only
those that don't care about the scope of the record should publish
"v=spf1". Those that care, should publish "spf2.0" records that declare
the assured scope.

I'm not sure how you can logically assert this Doug. People who
published v-=spf1 records didn't need to specify a scope because it
only applied to Mail From (and of course in the case of <> to HELO).

This depends upon which era is considered, and which draft the publisher
may have been reading.

Meng's white-paper on the spf.pobox.com website:
,----
| Sender ID was recently resubmitted to the IETF. It now specifies that
| both the return-path and the PRA may be used. Software that implements
| only SPF Classic can therefore be called Sender ID compliant. In
| practice, most people associate Sender ID with the PRA, and SPF
| Classic with the mail from, or return-path.
|
| The author recommends that MUA software implement Sender ID with PRA
| checking. The author recommends that MTA software implement Sender ID
| with mail from checking, aka SPF Classic.
'----
,----
| One half of Sender ID is SPF Classic. The original SPF Classic
| specification was frozen in early January 2004. It has evolved in only
| minor details since then. It was submitted to the IETF in October 2004
| and is expected to be published as an experimental RFC. When it is
| published, MTA vendors are encouraged to update their implementations
| to match it. Vendors who implement SPF Classic can indicate that they
| are Sender ID compliant.
|
| The other half of Sender ID is the PRA check. MTA vendors may also
| wish to implement that half. Specifications describing the PRA and how
| it fits into Sender ID were submitted to the IETF in October 2004 as
| well.
'----

The SPF spec is frozen, which is why it does not offer a solution to
your dilemma. You would need to thaw it out before you could use the
new and scope-safe record. According to Meng, both the bounce-address
and the PRA SHOULD be used. Obviously, there is little concern
regarding a reputation assessment described in a diagram on Page 11 of
this paper.

To make a leap from there to "don't care" is quite a stretch. To Ex
Post Facto apply new logic and claim that to know the "new" intent of
the publisher of the record (published prior to the claim that the new
logic should be applied) can have no basis in fact or logic.

You should review the histories of these two drafts. It is clear to me
the authors of the "frozen in time" draft have not allowed themselves to
deal with this conflict, as the PRA did not exist back then. This draft
is just to document a distant point in history, nothing more. Reading
the white paper, you would be hard pressed to even discern there was a
problem.

Could the action being discussed be called anything than mail (related
record) abuse?

I am posting to the MARID reflector in order to express my views
concerning the two drafts published. Your view of history is simply
biased. What is preventing the use of "spf2.0/mform"? Why battle when
there is a solution? You are talking about a mistake made by the group
as a whole. We all make mistakes. Watch for the camel's nose next
time.

-Doug

Terry Fielder

2005-06-19 12:12:57 UTC

Qualcomm, it has been clear the SPF record would be utilized to evaluate
the PRA. Microsoft wanted to use their XML record, but the WG convinced
them to use the existing record syntax.

Inaccurate at best, the working group convinced MS not to put bloated
inefficient unnecessary XML records in DNS. It had nothing to do with
"convincing MS to use their syntax", it had to do with "don't make SPF
have to use an XML format"

Terry

Post by Douglas Otis
This is why Meng Wong
eventually suggested the use of the "spf2.0/mfrom ..." record once the
licensing issue became a concern. This is history that can not be
changed. Especially by a third-party like IETF/IESG. You want the IESG
to say who made the mistake? There were so many in sequence.

This depends upon which era is considered, and which draft the publisher
may have been reading.
,----
| Sender ID was recently resubmitted to the IETF. It now specifies that
| both the return-path and the PRA may be used. Software that implements
| only SPF Classic can therefore be called Sender ID compliant. In
| practice, most people associate Sender ID with the PRA, and SPF
| Classic with the mail from, or return-path.
|
| The author recommends that MUA software implement Sender ID with PRA
| checking. The author recommends that MTA software implement Sender ID
| with mail from checking, aka SPF Classic.
'----
,----
| One half of Sender ID is SPF Classic. The original SPF Classic
| specification was frozen in early January 2004. It has evolved in only
| minor details since then. It was submitted to the IETF in October 2004
| and is expected to be published as an experimental RFC. When it is
| published, MTA vendors are encouraged to update their implementations
| to match it. Vendors who implement SPF Classic can indicate that they
| are Sender ID compliant.
|
| The other half of Sender ID is the PRA check. MTA vendors may also
| wish to implement that half. Specifications describing the PRA and how
| it fits into Sender ID were submitted to the IETF in October 2004 as
| well.
'----
The SPF spec is frozen, which is why it does not offer a solution to
your dilemma. You would need to thaw it out before you could use the
new and scope-safe record. According to Meng, both the bounce-address
and the PRA SHOULD be used. Obviously, there is little concern
regarding a reputation assessment described in a diagram on Page 11 of
this paper.

Could the action being discussed be called anything than mail (related
record) abuse?

--
Terry Fielder
***@greatgulfhomes.com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085

Douglas Otis

2005-06-20 11:35:04 UTC

Post by Terry Fielder

Part of the pitch for the SPF syntax, during the transition from the
bounce-address to the PRA, included using the _exact_ syntax to avoid
causing a change to the existing record. It has become obvious, this
was a mistake from the point of view of the bounce-address-only
proponents. It is also clear from the onset of the requests to publish
SPF records, little consideration has been given to the potential
outcome when reputation is applied.

Although I repeatedly warned SPF does NOT prevent spoofing and that this
assumption is dangerous for those that share outbound MTA servers, this
caution was never heeded. The typical response from various proponents
has been, "It is the publisher's fault for not considering these
potential problems." It is also the proponent's fault for failing to
provide _any_ warning regarding these concerns.

It is rather outrageous to see statements like "Everyone and their dog
should publish SPF records." This advice should include, "provided you
and your dog control exclusive access to the authorized outbound MTA."
If the MTA is being shared, then you and your dog should be indemnified
by your outbound service provider against their not maintaining your
exclusive use of both the bounce-address and the PRA.

It is not surprising that SPF promoters don't care what problems they
may cause the average mailbox-domain owner. Often these promoters are
bulk email service providers or network service providers looking to
escape accountability when one of their customers abuses email. An
understandable goal and one safely achieved using email signatures,
rather than SPF.

With signatures, the providers would not alter signed messages nor
attempt to evaluate SPF. With SPF, providers would need to evaluate
user/mailbox-domain permissions for the bounce-address and the PRA, or
place their customers in serious peril. Signatures expect nothing from
the providers. Whereas, SPF expects much more from providers, without
providing any ramification when they fail these added duties.

Sender-ID wants to change Sender-Header handling in conflict with the
much safer signature scheme. SPF wants to change the bounce-address
handling and place providers at risk with its poor level of security.
The risk and incompatibility created by either SPF or Sender-ID is
without merit, when there is a much better and safer alternative
possible.

Remember, SPF is simply an historical document that attempts to capture
SPF as it was before Sender-ID had been adopted, according to Meng.
Sender-ID is the only active document relevant to the application of the
SPF record, in his view. Sender-ID now permits evaluation of both the
bounce-address and the PRA. It seems that the SPF classic group are
confused about the current relevance of their document. The problem of
requiring assurances for the PRA or publishing a record destined to be
refused seems of little concern.

To get a better understanding why SPF is historical, and that only
Sender-ID defines use of the SPF record read:
http://spf.pobox.com/whitepaper.pdf

-Doug

Douglas Otis

2005-06-20 11:33:12 UTC

Post by Terry Fielder

Greg Connor

2005-07-20 05:59:14 UTC

Post by Douglas Otis
For "Sender Policy Framework (SPF) for Authorizing Use of Domains in
E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt.
For "Sender ID: Authenticating E-Mail" the listed authors are J. Lyon,
and M. Wong. The "spf2.0/" record syntax was a product of the MARID WG
specifically addressing this very issue. As all the authors
participated in the MARID WG that identified this scope related
problem, and as both of these drafts also credit common authorship, it
would be impossible to say which draft is now authoritative for the
"v=spf1" record.

From the day of the SPF/Sender-ID merger in the interim meeting at
Qualcomm, it has been clear the SPF record would be utilized to evaluate
the PRA. Microsoft wanted to use their XML record, but the WG convinced
them to use the existing record syntax. This is why Meng Wong
eventually suggested the use of the "spf2.0/mfrom ..." record once the
licensing issue became a concern. This is history that can not be
changed. Especially by a third-party like IETF/IESG. You want the IESG
to say who made the mistake? There were so many in sequence.

As one who spent a fair amount of time working in the MARID working group,
I can honestly say I'm still disappointed that there was never a proposed
standard, only drafts and talking.

I wouldn't call any of those drafts or discussions "mistakes" but I
wouldn't credit them as being standards either. My belief, in the few
conversations I did have with MS folks, was that we were working toward a
common goal that was, in the end, never realized. The WG failed to produce
the output we were all expecting... we were left only with "Go ye forth and
experiment some more."

Technically, there is no official functional definition of what a TXT
record means other than "it contains text". So, no draft writer can claim
it's an exclusive domain. However, if I'm looking for propriety in whose
draft should or should not claim to make use of the records, I'm going to
look for prior art. I'm going to look for what people who actually
published the records *intended* them to be used for. It seems pretty
clear to me that people who published TXT records starting with v=spf1
intended them to be used *FOR SPF*. Any other interpretation seems
specious to me. Nothing output by MARID has reached any level of adoption
even approaching the level SPF was at even before MARID was convened.

Probably the worst "mistake" we made with MARID was allowing it to be
subjected to denial-of-service attacks, and I'm not talking about the DNS
variety. I'm talking about people who continually trotted out the same FUD
over and over, blatantly going over posting limits and outside of topics
requested by the chair, and repeatedly questioning what had already been
declared a rough consensus.

...

This depends upon which era is considered, and which draft the publisher
may have been reading.

...

The SPF spec is frozen, which is why it does not offer a solution to
your dilemma. You would need to thaw it out before you could use the
new and scope-safe record.

...

Speaking of FUD, thank you for the eloquent reminders as to why I haven't
opened the MXCOMP mail folder for nearly a year.

MARID failed it's primary goal, but most of the people involved are moving
ahead with other proposals. More power to them. I don't even think of
them as "competing" proposals. The best case would be if they all move
forward in some form or another.

I don't think it's productive to point to the actions taken by MARID and
say that those are the "official" versions of anything.

Anyway, best of luck with your... whatever it is you're doing. The only
real advice I have is, resist the temptation to tear down what other people
are building, and go build something interesting of your own. It's a lot
harder to build than to tear down, but you have a better chance of earning
respect in the long run.

Be well.

gregc

--
Greg Connor <***@nekodojo.org>

Douglas Otis

2005-07-20 15:12:25 UTC

Post by Greg Connor
Speaking of FUD, thank you for the eloquent reminders as to why I haven't
opened the MXCOMP mail folder for nearly a year.

I am surprised you consider a suggestion to permit use of a compatible
record (spf2.0) by SPF Classic (and Sender-ID) to be FUD. I have just
returned from a large promotional meeting attended by SPF proponents,
such as Meng Wong and Wayne Schlitt. On more than one occasion an
explanation was made that publishing the v=spf1 record would be used to
evaluate the PRA. I never heard anyone object, so I don't understand
how one can conclude what people intend when they publish this record.
I would have hoped you could understand why not permitting a record that
declares its scope has become a problem.

Post by Greg Connor
MARID failed it's primary goal, but most of the people involved are moving
ahead with other proposals. More power to them. I don't even think of
them as "competing" proposals. The best case would be if they all move
forward in some form or another.
I don't think it's productive to point to the actions taken by MARID and
say that those are the "official" versions of anything.

There are experimental versions of SPF Classic and Sender-ID with a few
still trying to find solutions for problems that remain with these
approaches. Two areas still wanting is a means to assert scope in SPF
classic to indicate that the PRA has not been evaluated and should not
be used. The other is a means to indicate the exclusive use of a domain
is or is not being assured by the server.

At this meeting there were companies that acknowledge the concern
created by such oversight and were providing domain owners their own
unique outbound IP address. When considering the shared server problem
together with the loss of forwarded email, it is hard not to think that
DomainKeys and DKIM are already well ahead on the solutions curve.

There is no spam or phishing solution without the use of email
reputation. The accrual of reputation demands authentication and not
just authorization, if to be fair. Saying that authorization is good
enough sounds too much to me like "let them eat cake" when knowing those
that care will have their own servers. Getting this right requires an
understanding that neither authorization nor authentication alone is a
solution.

The next step in this process is reputation, however this step can only
be safely made when there is an ability to authenticate the entity being
held accountable. Just calling it authentication is not productive,
when it is based upon an assumption that the server is not shared. I
find this a bad assumption and one that will create endless support
issues when exploited by the millions of zombies known to exist.

-Doug

Greg Connor

2005-07-20 19:55:25 UTC

Post by Douglas Otis
There are experimental versions of SPF Classic and Sender-ID with a few
still trying to find solutions for problems that remain with these
approaches. Two areas still wanting is a means to assert scope in SPF
classic to indicate that the PRA has not been evaluated and should not
be used. The other is a means to indicate the exclusive use of a domain
is or is not being assured by the server.

I don't know of a good way to objectively tell whether something is
experimental. Quite a number of people use SPF and don't intend to stop,
but it's still a minority in terms of the world population of domains and
mail servers. So, I guess the "experimental" label can be applied to
either usage, but in terms of numbers, SPF classic is clearly ahead in
terms of adoption.

I'm not sure exactly what is meant by "a means to indicate the exclusive
use of a domain is or is not being assured by the server". The spec is
pretty clear on what constitutes a "pass" vs. "unknown". I have been
suggesting to people for quite some time that they should use the "+" mode
if they control the MTA, or if they trust the MTA operators enough to take
responsibility for the MTA's actions.

For some domain owners, this could mean "the site uses SMTP AUTH and
doesn't allow spoofing of other domains". For others, they may be content
with "the site doesn't currently have an ongoing forgery problem". This
is a tradeoff the domain owner must decide for himself. If they don't
wish to take responsibility for the MTA, they should use "?" instead of
"+" to add it. We want to encourage everyone to move to the "+" column
eventually, but there is still quite a bit of value in narrowing the "?"
space from ?all to ?certain-MTAs -all. Every little bit helps.

I think we have been over the difference between "+" and "?" in the spec
before, so I'm puzzled as to why this is still often (very often) brought
up as a "fault". Do you really see it as a fault, or is it just a
convenient place to attack SPF because people often get confused about it?
Do you understand the difference between Pass and Neutral results?

(Last I checked CSV doesn't have a neutral or unknown mode. If I remember
right, the only way to signify "unknown" under CSV is not to publish. Of
course, you didn't say whether you are comparing SPF to CSV, or just
railing on SPF without a constructive counter-proposal.)

Post by Douglas Otis
There is no spam or phishing solution without the use of email
reputation. The accrual of reputation demands authentication and not
just authorization, if to be fair. Saying that authorization is good
enough sounds too much to me like "let them eat cake" when knowing those
that care will have their own servers. Getting this right requires an
understanding that neither authorization nor authentication alone is a
solution.

I think I would agree with that. But if there's any lesson I take away
from MARID, it's that the best is often the enemy of the good. Waiting to
solve one problem until we have enough tools to solve a larger number of
problems doesn't seem to be the best way forward. Some would look at the
problem space and say "This is huge and complicated... We have to approach
it in just the right way." I look at the problem space and say "This is
huge and complicated, so let's get started."

Post by Douglas Otis
The next step in this process is reputation, however this step can only
be safely made when there is an ability to authenticate the entity being
held accountable. Just calling it authentication is not productive,
when it is based upon an assumption that the server is not shared. I
find this a bad assumption and one that will create endless support
issues when exploited by the millions of zombies known to exist.

I understand what you mean here, and I do believe you are sincere, but I
don't agree with your characterization nor your conclusion. I should
probably go back and read the spec and see if the language explaining pass
vs. neutral is clear enough. If you have suggestions on how to make this
clearer so people aren't confused in the way you suspect they currently
are, I'm sure Wayne would welcome the feedback.

Thanks
gregc

--
Greg Connor <***@nekodojo.org>
on my squirrelmail right now

Douglas Otis

2005-07-21 05:18:12 UTC

Post by Greg Connor
I don't know of a good way to objectively tell whether something is
experimental.

This is the category assigned by the IETF.

Post by Greg Connor
I'm not sure exactly what is meant by "a means to indicate the exclusive
use of a domain is or is not being assured by the server".

While there have been several providers to offer domain owners their own
IP address for reputation protection, such providers will likely need to
acquire a server per 8 such domain owners, to justify the IP address
use.

While perhaps as much as 20% of the domain owners could acquire their
own IP address, this method of constraining outbound SMTP authorization
is expensive. What is not apparent is whether a server ensures that
shared domain use is not abused. At the meeting in the technical
section, an example had something similar to 'include:isp.net'. If
servers at isp.net handle large numbers of domains, and do not constrain
both the PRA and the bounce-address, then such an 'include' could become
reputation suicide.

Post by Greg Connor
The spec is pretty clear on what constitutes a "pass" vs. "unknown".

As there are many functions possible within the SPF script, it is
difficult to know what basic function is being attempted. Without
knowing this, what does 'pass' really mean? I would recommend creating
a structure that describes returning results in three categories based
upon the actual function completed:

- authorization
- authentication
- compliance

Post by Greg Connor
I have been suggesting to people for quite some time that they should
use the "+" mode if they control the MTA, or if they trust the MTA
operators enough to take responsibility for the MTA's actions.

You are advocating an undocumented convention that could not be
differentiated from existing use, but okay. If the mailbox-domain is
not constrained as indicated by the absence of '+', then results should
fall within the 'authorization' category. If the domain is constrained,
perhaps by specialized software, or exclusive use of an IP address, then
results could fall within the 'authentication' category.

Without knowing whether the domain is constrained, which normally it is
not, then holding the domain accountable for abuse would be unfair. A
'failure' result within the 'authorization' category could be used to
repudiate the source of the message only. However, a 'success' result
could not be used as a basis for reputation accrual. Alas, it is not
human nature to follow this practice. A recipient will still want to do
_something_ about abuse, even when it is only being 'authorized' by a
domain owner. As a result, these domain owners may become unfairly
blocked.

The domain owner should not have been held accountable, as they are
unable to protect themselves. Nor will the SPF system allow everyone to
protect themselves, which suggests it is okay to create a type of second
class email domain. This is where the phrase "let them eat cake" comes
to mind.

Post by Greg Connor
For some domain owners, this could mean "the site uses SMTP AUTH and
doesn't allow spoofing of other domains".

Yes that is possible, but this system keeps the domain owner in the
dark, and the administrator that MUST provide the security, anonymous
and in control of all evidence. Again human nature seems to suggest
that there will be many domain owners unfairly treated.

Post by Greg Connor
For others, they may be content with "the site doesn't currently have
an ongoing forgery problem". This is a tradeoff the domain owner must
decide for himself. If they don't wish to take responsibility for the
MTA, they should use "?" instead of "+" to add it. We want to
encourage everyone to move to the "+" column eventually, but there is
still quite a bit of value in narrowing the "?" space from ?all to ?
certain-MTAs -all. Every little bit helps.

I would say there is another option that should be considered. Not
publishing SPF records. Many recipients are rejecting '~' and '?' which
creates an immediate problem for the sender with forwarding issues that
depend upon this exploited feature. I doubt there are many service
providers willing to offer domain owners indemnification, should their
domain become abused, and the domain's reputation is subsequently
damaged.

Post by Greg Connor
I think we have been over the difference between "+" and "?" in the spec
before, so I'm puzzled as to why this is still often (very often) brought
up as a "fault". Do you really see it as a fault, or is it just a
convenient place to attack SPF because people often get confused about it?
Do you understand the difference between Pass and Neutral results?

I am attempting to clarify what is needed for the next step, while you
are focused on the mechanics that look past the basics. Step back and
think about the basic functions: authorization, authentication and
policy compliance. As I said, it appears the '~' and '?' are already
too heavily exploited to be of much use as shades of failure.

Post by Greg Connor
(Last I checked CSV doesn't have a neutral or unknown mode. If I remember
right, the only way to signify "unknown" under CSV is not to publish. Of
course, you didn't say whether you are comparing SPF to CSV, or just
railing on SPF without a constructive counter-proposal.)

I see DKIM and CSV as fair as safe paths to enabling name-based
reputation. Consider what is needed to perform the basic functions.
My comments come from a perspective different from most providers. A
perspective found dealing with angry senders; where error messages often
point to the wrong reputation service; for the sender, it does not
matter who created the reputation accrual error, they want someone to
call for restitution.

Post by Greg Connor

I still see CSV and DKIM as a way forward. I would have expect CSV to
come first however. CSV protects the network resources, and DKIM
protects the domain owners. There are different incentives for each
method, but in the end, they both can safely support a name-based
reputation system without unfairly causing harm.

Post by Greg Connor

If you look at the language for pass, you will find the word 'authorize'
accompanied by language that suggest this is good enough to hold the
entity accountable and to accrue a reputation. As I have said many
times, authorization is not good enough. HELO authentication carries to
much baggage to be really useful at defending resources, which is the
role it should play. I have never been shy at offering feedback. : )

-Doug

Greg Connor

2005-07-21 06:50:14 UTC

Post by Greg Connor
I'm not sure exactly what is meant by "a means to indicate the exclusive
use of a domain is or is not being assured by the server".

While there have been several providers to offer domain owners their own
IP address for reputation protection, such providers will likely need to
acquire a server per 8 such domain owners, to justify the IP address
use.
While perhaps as much as 20% of the domain owners could acquire their
own IP address, this method of constraining outbound SMTP authorization
is expensive. What is not apparent is whether a server ensures that
shared domain use is not abused. At the meeting in the technical
section, an example had something similar to 'include:isp.net'. If
servers at isp.net handle large numbers of domains, and do not constrain
both the PRA and the bounce-address, then such an 'include' could become
reputation suicide.

I'm not sure what having "your own IP address" has to do with either
authentication or authorization. Are you working under the misapprehension
that you need a separate IP address per domain name in order to turn on
SMTP AUTH and enforce proper use of identities?

A casual reader of the above might make the mistake of assuming that SPF
requires a static IP in order to work. It is strongly implied. If you
actually believe this, I can take the time to explain how SMTP AUTH and SPF
Pass results are related.

If you don't understand what I meant when I said "the site uses SMTP AUTH
and doesn't allow spoofing of other domains" then please ask for
clarification. If you DO understand what I meant, please stop spreading
misleading information.

Post by Greg Connor
The spec is pretty clear on what constitutes a "pass" vs. "unknown".

The SPF spec describes "pass" as "the action is authorized". It doesn't
describe authentication or compliance, as far as I know. I believe SPF is
a great tool for what it does, but it doesn't do everything. I think this
is OK... any tool claiming to do all of the above should be viewed with
skepticism... To me it seems a lot more likely that the problem space
will be covered by multiple tools.

I'm sorry, I think my initial explanation was not detailed enough. I was
assuming that since you spend a fair amount of time pointing out SPF's
faults, that you were familiar enough with the mechanisms in question to
understand my statement.

Here is some background necessary in order to understand the significance
of "pass" vs. "unknown" in the context of reputation.

"+" indicates that the mechanism results in a "pass". "+" is also the
default, so if you have a mechanism with no prefix, the "+" is understood.
+include:isp.net and include:isp.net are the same. If the mechanism
matches the situation, the result is "Pass". The receiver can proceed with
confidence in the identity (mfrom or helo). The action is considered
authorized, and the domain owner should be held accountable for the action
of the MTA.

"?" indicates that the mechanism results in a "neutral" result. The action
is neither explicitly authorized nor explicitly denied. The receiver
should proceed with whatever the default action is for domains not
protected by SPF.

Post by Douglas Otis
Without knowing whether the domain is constrained, which normally it is
not, then holding the domain accountable for abuse would be unfair. A
'failure' result within the 'authorization' category could be used to
repudiate the source of the message only. However, a 'success' result
could not be used as a basis for reputation accrual. Alas, it is not
human nature to follow this practice. A recipient will still want to do
_something_ about abuse, even when it is only being 'authorized' by a
domain owner. As a result, these domain owners may become unfairly
blocked.

Right, again I apologize for not explaining what I meant well enough. I
believe your first paragraph above is consistent with the "Pass" result and
the "+" modifier (or no modifier), and your second paragraph applies well
to the "neutral" result and the "?" modifier.

The difference between these two modes is as you say. "Pass" is the only
result I would really describe as "success". It implies that the domain
owner wants the privileges conferred by a Pass, and is willing to defend
the messages coming from that MTA with his reputation. They are one and
the same as far as SPF is concerned... it is meaningless to authorize a
message if you're not willing to stake your reputation.

Post by Greg Connor
For some domain owners, this could mean "the site uses SMTP AUTH and
doesn't allow spoofing of other domains".

I don't really draw a distinction between equipment I own or control, and
stuff done on my behalf by a vendor. The important distinction is not who
owns the equipment, but whether I trust the vendor/partner/employee/robot
in charge of doing it, and whether I trust them enough to stake my own
reputation.

A lot of ISPs are now requiring the use of SMTP AUTH within their networks,
but my experience has been that they don't block messages claiming to be
from various domains. Hopefully if enough users ask for this, they will
start matching up domains that I own and control with my name and password
for SMTP AUTH, and disallowing others from using domains they don't own. I
don't think it's a tough problem to solve, but currently they have no real
incentive to solve it. I think wider use of ip-based authorization will
put more pressure on them.

In the meantime, some domain owners may choose to give them a PASS anyway,
in effect staking their reputation on a service that may be mostly
spam-free and forgery-free right now, but may develop such problems in the
future, and they will deal with that if and when it happens.

Post by Greg Connor

Post by Douglas Otis
The next step in this process is reputation, however this step can only
be safely made when there is an ability to authenticate the entity
being held accountable. Just calling it authentication is not
productive, when it is based upon an assumption that the server is not
shared. I find this a bad assumption and one that will create endless
support issues when exploited by the millions of zombies known to
exist.

I understand what you mean here, and I do believe you are sincere, but I
don't agree with your characterization nor your conclusion. I should
probably go back and read the spec and see if the language explaining
pass vs. neutral is clear enough. If you have suggestions on how to
make this clearer so people aren't confused in the way you suspect they
currently are, I'm sure Wayne would welcome the feedback.

You stated a couple of times (though I snipped them for space conservation)
that you see CSV and DKIM as a valid path to authorization, authentication,
and reputation. Why do you feel that CSV+DKIM fulfills this goal, but
SPF-HELO+DKIM would not?

I readily admit that I don't understand CSV well enough to spend a lot of
time bashing it on various lists. Therefore, please don't assume I'm
bashing on CSV here. If the point of CSV is to provide confidence in the
HELO name, how is that functionally different from SPF used to check HELO?
- A domain owner publishes a record in DNS
- A receiver has a name and wishes to check it against the IP that
offered the name
- The receiver gets the DNS record and checks to see if the IP is
authorized
- If the IP is authorized, the receiver can proceed with confidence in
the HELO identity
It's my understanding that the above requirements can apply to either CSV
or SPF-HELO. I can guess that you probably don't agree with this, but I
still cannot fathom the reasons. Since SPF has been a frequent target for
folks to take pot-shots at such as "authorization without authentication is
not good enough", it's rather important to me to try and understand the
essence of this issue.

Thanks for taking the time to write.
gregc

--
Greg Connor <***@nekodojo.org>

Kjetil Torgrim Homme

2005-07-21 09:16:54 UTC

Post by Greg Connor
I'm not sure what having "your own IP address" has to do with
either authentication or authorization. Are you working under the
misapprehension that you need a separate IP address per domain
name in order to turn on SMTP AUTH and enforce proper use of
identities?

excuse my jumping in, but it seems like you and Doug can't understand
each other very well :-)

no. SPF authorises an IP-address to use a domain. that IP-address
may be authorised to use several other domains as well. it can also
handle other domains which haven't deployed SPF. these domains can be
owned by different entities, and SPF offers no protection against
abuse from the entities sharing your server. in fact, they will be
fully authorised to spew junk and destroy your reputation. so you
take your business elsewhere -- but it won't help. the reputation is
tied to your domain name. the only solution is to plea with others,
to wait, or to switch domain name.

contrast this with CSV. CSV authorises a server to send e-mail in
general, its administrator claims responsibility for handling abuse
complaints in a timely manner and so on. CSV says _nothing_ about the
domains used as sender addresses in the e-mail sent out by that
server. as a consequence there are no issues with forwarding, or
people using their Hotmail address even when sending via the
university server etc. it also means that if you happen to be hosted
by an irresponisible company, you can take your business elsewhere, to
a host which may already have good reputation. the bad reputation is
left behind with the bad server.

Post by Greg Connor
A casual reader of the above might make the mistake of assuming
that SPF requires a static IP in order to work.

well, it does require at least one IP address per entity wanting
distinct reputation. I'd say that's pretty close to requiring an IP
address per domain, but of course that's a judgement for each domain
operator to make.

Post by Greg Connor
You stated a couple of times (though I snipped them for space
conservation) that you see CSV and DKIM as a valid path to
authorization, authentication, and reputation. Why do you feel
that CSV+DKIM fulfills this goal, but SPF-HELO+DKIM would not?

DKIM handles the other piece, authorising the use of the domain (or
individual e-mail address) as a sender of e-mail. this is done by
adding cryptographically secure authentication to the message itself.
this leaves the authentication to the system generating the e-mail,
either at MTA or MUA level, and it survives forwarding through a chain
of servers (although there are some caveats still being worked out.)

--
hope this helps,
Kjetil T.

Frank Ellermann

2005-07-21 10:31:54 UTC

Post by Kjetil Torgrim Homme
SPF authorises an IP-address to use a domain.

[...]

Post by Kjetil Torgrim Homme
SPF offers no protection against abuse from the entities
sharing your server.

Yes, for that you would need "enforced submission rights"
as specified in RfC 2476(bis) option 6.1, or your own MTA.

The spec. is rather clear about this issue (chapter 10.4).

Post by Kjetil Torgrim Homme
take your business elsewhere -- but it won't help. the
reputation is tied to your domain name. the only solution
is to plea with others, to wait, or to switch domain name.

If you're worried about this problem you can use the "?"
(NEUTRAL) qualifier, and still have "-" (FAIL) for the rest
of the world.

Post by Kjetil Torgrim Homme
it does require at least one IP address per entity wanting
distinct reputation.

No, that's not the case. And for the HELO-part of SPF it's
very similar to what you said about CSV, for simple policies
mta.example.com. IN SPF "v=spf1 a -all"

CSV is unrelated to forgeries, it's a solid base to reputation
systems - with SPF hoping that MTAs really limit themselves to
simple HELO-policies is shaky (but not impossible).

DKIM has a problem with forgeries, you've to declare that you
_always_ sign your headers. SPF is in theory more flexible:

You only need to know the IPs. In fact excluding the worst
offenders with "-" (FAIL) and use "?" (NEUTRAL) for the rest
of the world could also help. I've not tested this approach,
I have a classic no-nonsense CIDR-based PASS or FAIL policy,
the original RMX idea, no special SPF-features. Bye, Frank

Alan DeKok

2005-07-21 18:15:24 UTC

in fact, they will be fully authorised to spew junk and destroy your
reputation. so you take your business elsewhere -- but it won't
help. the reputation is tied to your domain name.

So your reputation doesn't recover when you move the domain
elsewhere?

Wow, you hold grudges for a *long* time.

contrast this with CSV.

Which does something else entirely, so comparisons aren't really
appropriate.

it also means that if you happen to be hosted by an irresponisible
company, you can take your business elsewhere, to a host which may
already have good reputation. the bad reputation is left behind
with the bad server.

And no one, of coure, will make the connection between "bad IP" and
"your domain is at that IP", so it will be impossible for anyone to
decide that the IP's bad reputation will affect your domain's
reputation.

Where SPF ties reputations to domains, CSV ties it to IP's. Since
domains are hosted at IP's, it's not a terribly large leap of faith to
use CSV to tie reputation to domains, too. And CSV can't prevent this
leap, so we can guarantee that people will be using CSV to affect
domain reputation.

At that point, much of your argument against SPF applies to CSV.

Alan DeKok.

Arnt Gulbrandsen

2005-07-21 19:35:16 UTC

So your reputation doesn't recover when you move the domain elsewhere?
Wow, you hold grudges for a *long* time.

If you were a reputation service provider, would you wipe a domain's
slate clean just because it changed outgoing MX? If I were a spammer,
I'd get n+1 outgoing MXes where n is the number of changes you require
to forget my past misbehaviour, then I'd rotate them.

Arnt

Alan DeKok

2005-07-21 20:51:04 UTC

Post by Arnt Gulbrandsen

Post by Alan DeKok
Wow, you hold grudges for a *long* time.

If you were a reputation service provider, would you wipe a domain's
slate clean just because it changed outgoing MX?

If reputation doesn't change over time, it's abusive.

Ask the people who register new domains, and *then* discover that
the domain was used 3 years ago to send spam. They often find that
"reputation services" don't care that the domain has changed hands,
for precisely the reasons you've articulated.

The same applies to people who get assigned networks that were
previously used to send spam. Their traffic is blocked, and they get
told "too bad".

Abusive reputation services are not much better than spammers.

Alan DeKok.

Frank Ellermann

2005-07-21 23:48:52 UTC

If I were a spammer, I'd get n+1 outgoing MXes where n is the
number of changes you require to forget my past misbehaviour,
then I'd rotate them.

Makes sense. You'd also manage to change the FQDN used in HELO
when the old FQDN is "burnt". That's independent of CSV or SPF,
how do reputation systems handle it, start with "assume guilty"
for new FQDNs ?
Bye, Frank

P.S. FWIW, John's eplanation matches what I think how it could
work based on CSV or SPF-HELO. Won't help against backscatter
of course, but that's no bug, only a feature covered by one of
the other schemes like an SPF MAIL FROM FAIL policy / SES / ...

John Leslie

2005-07-21 22:42:58 UTC

in fact, they will be fully authorised to spew junk and destroy your
reputation. so you take your business elsewhere -- but it won't
help. the reputation is tied to your domain name.

So your reputation doesn't recover when you move the domain elsewhere?

Exactly. A 60-day review cycle is considered fast.

contrast this with CSV.

Which does something else entirely, so comparisons aren't really
appropriate.

Comparison of effects _is_ valid...

True, various reputation services _will_ screw things up in any
way we can imagine, and some we can't...

Where SPF ties reputations to domains, CSV ties it to IP's.

There's really no basis for such a statement.

CSV contains a well-defined structure for reputation services.
Authorization is _by_ the domain of the HELO string, and _of_ any
actions of the MTA using that HELO string. The IP address(es) are
only for authentication that he MTA using that HELO string is one
operating under the control of that domain.

The absolutely clear intent of CSV is to provide information
showing authorization and authentication by a _domain_ -- not by
some ISP which assigns IP addresses.

CSV cannot stop reputation services from tieing reputation to
IP addresses, but the information it provides is tied to domains.

Since domains are hosted at IP's, it's not a terribly large leap of
faith to use CSV to tie reputation to domains, too.

It is no leap at all: CSV information shows a responsible domain
(not a responsible IP address).

And CSV can't prevent this leap, so we can guarantee that people will
be using CSV to affect domain reputation.

Thank you. That is exactly our intent.

At that point, much of your argument against SPF applies to CSV.

I'll let others judge that. I read Kjetil's argument to be that
with SPF, your reputation will not quickly recover, and will inhibit
email "From" your domain for quite a while, whereas with CSV the
reputation which will suffer is that of the MTA sending it, and you
can immediately send email "From" your domain through a different
domain's MTA.

(Since the MTA is generally not visible to readers of your email,
they will be unaware of any change.)

--
John Leslie <***@jlc.net>

gconnor

2005-07-22 00:03:58 UTC

Post by Alan DeKok
Where SPF ties reputations to domains, CSV ties it to IP's.

There's really no basis for such a statement.
CSV contains a well-defined structure for reputation services.
Authorization is _by_ the domain of the HELO string, and _of_ any
actions of the MTA using that HELO string. The IP address(es) are
only for authentication that he MTA using that HELO string is one
operating under the control of that domain.
The absolutely clear intent of CSV is to provide information
showing authorization and authentication by a _domain_ -- not by
some ISP which assigns IP addresses.

The version of CSV that I reviewed (though it was some time ago) seemed pretty
clearly aimed at establishing a connection between the actions of an MTA and a
name -- the name used in HELO. However, there was no information about how to
generalize behavior of many hosts with different hostnames, all in the same
domain.

Thus you can build up a good reputation for "mail1.example.net" and a bad one
for "mail2.example.net", and neither of those is connected to the other. In
that scenario, "example.net" has no reputation, unless there are one or more
MTAs that announce themselves with "EHLO example.net".

Your message seems to suggest that you can take several hosts in the same
domain (as in "the domain of the HELO string" and not just "the HELO string")
so I'm wondering if this is now defined in CSV or if there's some other
document that tells how to do it. If my machine is called mail1.example.net,
it makes sense to consolidate the reputation info under "example.net"... but
if my machine is called mydomain.com, do my actions affect the reputation of
"com."? what about mail1.bbc.co.uk vs. client1.demon.co.uk?

If the reputation attaches to a single name and doesn't get consolidated over
multiple MTAs, what value is being added over just a list of IPs with their
own reputations? Actually, CSV would be worse in that case because the
spammer can use the current date in seconds as his HELO name, even with the
same domain suffix, and have a clean reputation every time. hmmm..

(I am of course open to the idea that I've missed something... if so please
just point me in the right direction...)

--
Greg Connor
***@nekodojo.org

Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"

Kjetil Torgrim Homme

2005-07-22 10:24:28 UTC

Post by gconnor
The version of CSV that I reviewed (though it was some time ago)
seemed pretty clearly aimed at establishing a connection between
the actions of an MTA and a name -- the name used in HELO.
However, there was no information about how to generalize behavior
of many hosts with different hostnames, all in the same domain.
Thus you can build up a good reputation for "mail1.example.net"
and a bad one for "mail2.example.net", and neither of those is
connected to the other. In that scenario, "example.net" has no
reputation, unless there are one or more MTAs that announce
themselves with "EHLO example.net".

in my experience it is no longer common for the outgoing SMTP server
to have the name of an e-mail domain in use. we had such a setup ten
years ago, but even then many thought it old fashioned to have a host
with the same name as the delegated domain. from RFC 2821:

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

(address literals obviously can't be used with CSV.) I don't think
this aspect of SMTP is going to be changed, and there is little
incentive to do so.

Post by gconnor
Your message seems to suggest that you can take several hosts in
the same domain (as in "the domain of the HELO string" and not
just "the HELO string") so I'm wondering if this is now defined in
CSV or if there's some other document that tells how to do it. If
my machine is called mail1.example.net, it makes sense to
consolidate the reputation info under "example.net"... but if my
machine is called mydomain.com, do my actions affect the
reputation of "com."? what about mail1.bbc.co.uk
vs. client1.demon.co.uk?

this is where SPF tries to find the zone cut and uses dozens of DNS
queries, but that won't help, since a spammer can just as easily
delegate himself arbitrarily many subdomains.

Post by gconnor
If the reputation attaches to a single name and doesn't get
consolidated over multiple MTAs, what value is being added over
just a list of IPs with their own reputations?

it's a practical issue. doing a SRV lookup based on the IP would mean
a lookup in in-addr.arpa. for many sites, adding non-PTR records to
their reverse zones would be excedingly difficult. many corporate
users can't even get their IP provider to update their PTR records to
be consistent. since CSV uses the HELO name as the basis, only
administrative access to the domain with the HELO name is needed to
publish CSV.

Post by gconnor
Actually, CSV would be worse in that case because the spammer can
use the current date in seconds as his HELO name, even with the
same domain suffix, and have a clean reputation every time.
hmmm..

he would need to add SRV records for each and every HELO name, but a
suitably savvy spammer (if such exists) could make a magic wildcard
syntax in the DNS server for this purpose. actually, _I_ want such a
wildcard to publish _negative_ SRV records for our workstations. as
it is, we would need to add 35296 negative SRV records to our zone to
fully implement CSV...

Post by gconnor
(I am of course open to the idea that I've missed something... if
so please just point me in the right direction...)

likewise.

--
Kjetil T.

John Leslie

2005-07-22 11:54:46 UTC

actually, _I_ want such a wildcard to publish _negative_ SRV records
for our workstations. as it is, we would need to add 35296 negative
SRV records to our zone to fully implement CSV...

CSV _has_ been updated to allow a domain to specify that any
subdomain lacking a specific SRV record is "not authorized". This,
however, is outside the central purpose of CSV -- which is to enable
bypassing "expensive" and sometimes-inaccurate other mechanisms.

(The revised spec does not require every CSV-compliant MTA to
search for that bit: we expect mechanisms to evolve for querying
databases of domains which set it.)

--
John Leslie <***@jlc.net>

Frank Ellermann

2005-07-22 20:23:49 UTC

Post by Kjetil Torgrim Homme
address literals obviously can't be used with CSV.

Nor with SPF, but MTAMARK could help (directly or
indirectly as source for SIQ or traditional DNS?L)

[...]

Post by Kjetil Torgrim Homme
this is where SPF tries to find the zone cut

That was never implemented and finally removed from
the spec. => no more zone cut in the SPF RfC

Post by Kjetil Torgrim Homme
dozens of DNS queries

More like one (q=ns), but as I said it was removed.
CSV uses in the worst case six queries instead of a
zone cut.

Post by Kjetil Torgrim Homme
a spammer can just as easily delegate himself arbitrarily
many subdomains.

Yes. The CSV idea is pretty irrelevant to fight abuse, it
is more about accelerated processing of white / grey MTAs,
not about intentionally black hats... Unless you're ready
to reject all mails from unidentified sources. Bye, Frank

John Leslie

2005-07-22 11:37:33 UTC

Post by gconnor

Post by John Leslie
CSV contains a well-defined structure for reputation services.
Authorization is _by_ the domain of the HELO string, and _of_ any
actions of the MTA using that HELO string. The IP address(es) are
only for authentication that he MTA using that HELO string is one
operating under the control of that domain.
The absolutely clear intent of CSV is to provide information
showing authorization and authentication by a _domain_ -- not by
some ISP which assigns IP addresses.

The version of CSV that I reviewed (though it was some time ago)

(It really hasn't changed much.)

Post by gconnor
seemed pretty clearly aimed at establishing a connection between the
actions of an MTA and a name -- the name used in HELO.

Exactly.

Post by gconnor
However, there was no information about how to generalize behavior of
many hosts with different hostnames, all in the same domain.

We do not consider that issue in-scope.

Undoubtedly, some reputation services will take on that task; and
a number of approaches come to mind. The most useful approaches would
seem to be those which merely gather domain-wide information to be
used when name-specific information is sparse.

Post by gconnor
Thus you can build up a good reputation for "mail1.example.net" and
a bad one for "mail2.example.net", and neither of those is connected
to the other.

This is exactly true, as far as CSV is concerned.

Post by gconnor
In that scenario, "example.net" has no reputation, unless there are
one or more MTAs that announce themselves with "EHLO example.net".

Correct, as far as CSV is concerned. Reputation services, however,
may aggregate available information for subdomains, and use it in
some fashion.

There has been no change: we still consider it out-of-scope.

My wording was (deliberately) vague, so as to cover both the
exact CSV meaning and some possible interpretations by reputation
services.

Post by gconnor
If my machine is called mail1.example.net, it makes sense to
consolidate the reputation info under "example.net"... but if my
machine is called mydomain.com, do my actions affect the reputation of
"com."? what about mail1.bbc.co.uk vs. client1.demon.co.uk?

Though we consider this issue out-of-scope, a likely implementation
by reputation services would be to carry it upwards to the registered
entity: thus stopping at mydomain.com, demon.co.uk, or (hopefully)
somecompany.city.st.us.

Post by gconnor
If the reputation attaches to a single name and doesn't get
consolidated over multiple MTAs, what value is being added over
just a list of IPs with their own reputations?

The granulatity match is better; and the (out-of-scope) aggregation
of subdomains is far easier.

Correction: with that practice, the spammer would have "no
reputation" every time. CSV intends that other measures be applied
in cases of "no reputation" -- one example being IP blacklists.

--
John Leslie <***@jlc.net>

Alan DeKok

2005-07-22 02:11:10 UTC

So your reputation doesn't recover when you move the domain elsewhere?

Exactly. A 60-day review cycle is considered fast.

Any review is better than no review. The original comment was
insinutating that no review was done.

Post by John Leslie
Comparison of effects _is_ valid...

Agreed.

Post by John Leslie
I read Kjetil's argument to be that with SPF, your reputation will
not quickly recover, and will inhibit email "From" your domain for
quite a while,

I'm not sure why that is, as the explanation wasn't clear to me.
Nothing in CSV or SPF that I can see indicates how quickly reputation
will recover. So assertions that reputation will recover more quickly
for one than the other are unwarranted.

Post by John Leslie
The absolutely clear intent of CSV is to provide information
showing authorization and authentication by a _domain_ -- not by
some ISP which assigns IP addresses.

...

Post by John Leslie
whereas with CSV the reputation which will suffer is
that of the MTA sending it, and you can immediately send email
"From" your domain through a different domain's MTA.

So... CSV ties reputations to domains, or to MTA's?

The confusion here is that there are multiple domains that may be
used for authorization. EHLO, and MAIL FROM. When CSV uses EHLO,
sending "MAIL FROM" a particular domain is invisible to CSV, because
it's not looking at MAIL FROM. And in that case, reputation is tied
to MTA, not to the "MAIL FROM" domain.

If CSV uses "MAIL FROM" for reputation, then it has pretty much the
same issue as any other proposal using that field.

Alan DeKok.

Kjetil Torgrim Homme

2005-07-22 10:51:50 UTC

Post by John Leslie
Exactly. A 60-day review cycle is considered fast.

Any review is better than no review. The original comment was
insinutating that no review was done.

for many users, 60 days might as well be never.

no one can tell how the reputation services for CSV will operate, but
we can look at the DNSBLs in use today. several of these have a
stated policy of never removing any IP addresses used for spamming.
e.g., SORBS requires the netblock to switch owners, _and_ the new
owner to donate USD 50 per IP address to charity to remove the
listing.

Post by John Leslie
I read Kjetil's argument to be that with SPF, your reputation
will not quickly recover, and will inhibit email "From" your
domain for quite a while,

I'm not sure why that is, as the explanation wasn't clear to me.
Nothing in CSV or SPF that I can see indicates how quickly
reputation will recover. So assertions that reputation will
recover more quickly for one than the other are unwarranted.

as the two reputations in CSV aren't connected, it is safe to say that
the recovery will be quick... for SPF, there is no telling, it is out
of the domain administrator's hands.

Post by Alan DeKok
So... CSV ties reputations to domains, or to MTA's?
The confusion here is that there are multiple domains that may
be used for authorization. EHLO, and MAIL FROM. When CSV uses
EHLO, sending "MAIL FROM" a particular domain is invisible to CSV,
because it's not looking at MAIL FROM. And in that case,
reputation is tied to MTA, not to the "MAIL FROM" domain.

correct. tying it to the MTA is what makes CSV deployable for just
about any e-mail provider, whereas SPF in most cases require large
changes both in infrastructure and in customer behaviour.

Post by Alan DeKok
If CSV uses "MAIL FROM" for reputation, then it has pretty much
the same issue as any other proposal using that field.

yes, I think it has been established by now that "MAIL FROM" can't be
used without breaking e-mail or being vulnerable to replay attacks.

--
Kjetil T.

Hector Santos

2005-07-22 12:07:23 UTC

----- Original Message -----

Post by Kjetil Torgrim Homme
correct. tying it to the MTA is what makes CSV deployable for just
about any e-mail provider, whereas SPF in most cases require large
changes both in infrastructure and in customer behaviour.

hmmm, I hate to get into dumb debates. But I can't help myself.

CSV does not address the TARGET problem of malicious transactions. It has
no practical value other than ENFORCE a new level of secured transactions
and this is only DOABLE within compliant systems.

In other words, the problem is the bad people. Not the Good people. This
was proven over and over again by implementators and data research
organizations. If you take any protocol and you analyze the results, you
will find that at both ends of spectrum, it will have low false positives
and low false negatives. See David Silver, VP of MarkMonitor presentation
at:

http://metahost.savvislive.com/microsoft/20050712/GS6_auth_scorecard.asx

In short:

Bad systems do not comply.
Good systems comply.

This is the fundamental issue that the "spammers, spoofers", etc, rely on.
What makes phishers a touch problem is that they LOOK like compliant systems
at the SMTP level. This is part of the "middle" segment, the ones you
can't catch, that David was referring to and it matches with all our
emperical statistics we have done as well.

Post by Alan DeKok
If CSV uses "MAIL FROM" for reputation, then it has pretty much
the same issue as any other proposal using that field.

yes, I think it has been established by now that "MAIL FROM" can't be
used without breaking e-mail or being vulnerable to replay attacks.

Not quite.

Our success with our AVS system is fundamental based on "SMTP compliance."

Over 60-80% of all transactions are BAD - that's a fact. there is no dispute
here and if anyone says otherwise at this point of time, they simply don't
know what they are talking about.

If SMTP requires that the MAIL FROM: be fundamentally required and correct,
then it should go without saying that it is INDEED a verifiable entity -
regardless of how you go about it and there are quite a few ways to do it.

This is different from the client domain (HELO/EHLO) where it is WRITTEN in
stone that it could be BAD and thus it not required to be correct for
accepting a transaction. But even then, there are new levels of
consideration that one can implement for client domain validation - i.e,
domain literal compliance, local machine domain spoofing.

We will implement any GOOD idea and their many reasons we haven't
implemented CSV. It just isn't a practical solution today. However, that
does not say that a closed net or group of related mail networks (vendor to
vendor, etc) can not use it, but we already have ways to address trusted
relationships. So it would be a WASTE of time to use CVS today.

Now if we totally revamped the industry and you enforced a new LEVEL of
client domain requirements, including A/R, then we can begin to use it.

But then we are still back at square one:

- How to address the TARGET problem of legacy, non-compliant
systems that the BAD people are basing their distribution on.

and that is the PROBLEM. If it was not, we would not be here today.

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

Kjetil Torgrim Homme

2005-07-22 13:18:02 UTC

Post by Hector Santos

Post by Kjetil Torgrim Homme
correct. tying it to the MTA is what makes CSV deployable for
just about any e-mail provider, whereas SPF in most cases
require large changes both in infrastructure and in customer
behaviour.

hmmm, I hate to get into dumb debates. But I can't help myself.

oh well, one man's dumb debate is enlightening for others (such as me :)

Post by Hector Santos
CSV does not address the TARGET problem of malicious transactions.
It has no practical value other than ENFORCE a new level of
secured transactions and this is only DOABLE within compliant
systems.

I don't think anyone believes that CSV will be much help in the
struggle against spam, but it will help establish clearer
responsibilities and accountability. we already reject half a million
delivery attempts daily based on bogus HELO values. CSV will increase
that hit rate (probably not by much, though), and remove some of the
ad hoc rules in our system.

Post by Hector Santos
In other words, the problem is the bad people. Not the Good
people. This was proven over and over again by implementators and
data research organizations. If you take any protocol and you
analyze the results, you will find that at both ends of spectrum,
it will have low false positives and low false negatives. See
http://metahost.savvislive.com/microsoft/20050712/GS6_auth_scorecard.asx
Bad systems do not comply.
Good systems comply.

that's not what I heard in the above talk. smart bad systems comply,
too. one example from the talk is that both "pfizer.com" and
"pfizre.com" publish SPF records.

the talk also emphasises a number of problems with managing SPF for
corporate users, e.g., coordinating the use of multiple domains across
departments. this is interesting since CSV and DKIM has no problems
with this and allows easy delegation of responsibility.

Post by Hector Santos
This is the fundamental issue that the "spammers, spoofers", etc,
rely on. What makes phishers a touch problem is that they LOOK
like compliant systems at the SMTP level. This is part of the
"middle" segment, the ones you can't catch, that David was
referring to and it matches with all our emperical statistics we
have done as well.

yes, until we get full deployment, the middle section will be a
problem. this is why it is critical to agree on a standard which is
deployable by everyone.

Post by Hector Santos

Post by Kjetil Torgrim Homme
yes, I think it has been established by now that "MAIL FROM"
can't be used without breaking e-mail or being vulnerable to
replay attacks.

no disagreement here!

Post by Hector Santos
If SMTP requires that the MAIL FROM: be fundamentally required and
correct, then it should go without saying that it is INDEED a
verifiable entity - regardless of how you go about it and there
are quite a few ways to do it.

sure. I was talking about going _beyond_ SMTP. we require the domain
name used in MAIL FROM to be e-mail routable (ie. have valid A or MX
record). you might say this goes beyond RFC 2821, but in any case
there is no need to formalise this behaviour. I think most will think
it is the natural thing to do.

Post by Hector Santos
This is different from the client domain (HELO/EHLO) where it is
WRITTEN in stone that it could be BAD and thus it not required to
be correct for accepting a transaction.

exactly, which is why we need an explicit method to cover for the
lee-way RFC 821 provided.

Post by Hector Santos
We will implement any GOOD idea and their many reasons we haven't
implemented CSV. It just isn't a practical solution today.

do you have any technical problems doing it?

Post by Hector Santos
However, that does not say that a closed net or group of related
mail networks (vendor to vendor, etc) can not use it, but we
already have ways to address trusted relationships. So it would
be a WASTE of time to use CVS today.

CSV is still in draft, so I understand fully that you're holding off.

Post by Hector Santos
- How to address the TARGET problem of legacy, non-compliant
systems that the BAD people are basing their distribution on.
and that is the PROBLEM. If it was not, we would not be here today.

CSV will help somewhat (see number of bad HELO above), but DKIM is
much closer to be a solution for that problem.

--
Kjetil T.

Douglas Otis

2005-07-22 17:01:39 UTC

Reputation systems will move away from reliance upon using the IP
address in favor of the domain name when made possible by DKIM, for
example. DKIM clearly provides authentication without requiring many
infrastructure alterations. One thing not protected is the network
resources. A reputation service can and often does offer a
significant level of resource protection however. With either DKIM
or Sender-ID there can be no resource protect that results from the
application of reputation following the acceptance of the message.

One key, fair, and safe requirement for any reputation system would
be the accrual of behavior be based upon authenticated identities.
Here is where CSV becomes vital. CSV allows the extension of name
based reputation into also protecting the network resources. I know
that SPF claims to be able to "authenticate" the HELO, but with SPF
Classic, it is all (which includes a list of problems) or nothing.
The high required minimum number of lookups for the SPF records
absolutely prevents this record from playing a resource protective
role. CSV not only does NOT need wildcards to express a domain-wide
policy, but expects this function can be done using a single lookup
prior to any further exchanges, including the message.

When there is a failure to find the CSV based off the HELO, then, as
an option, there is a means to quickly discover whether the domain
offers a CSV policy. A domain name provides a fair amount of
information. Reputation can assessed based upon this ancillary
information to hold the appropriate level accountable. There could
be methods that propagate accountability up the name tree, and I
would say that bad reputation always would move down the tree.

A school on a single T1 may tax the budget $450/month. Without
resource protection, the school may find that that this resource is
being consumed by a flood of spam in effect wasting this investment.
Here resource protection becomes vital. When perhaps 80% of domain
owners share servers, the use of IP addresses tends to paint with too
broad of a brush. To move into the use of name reputation to be more
selective about who the bad actors are, then CSV offers that
possibility. A CSV lookup failure will force the fail-over to the
use of IP address to assess reputation. It could be to your
customers advantage to not be tied to the IP address reputation. CSV
becomes a way to offer an alternative reputation specific for the
client. Even when the HELO is held static, this still permits an
authenticated name as a basis for reputation accrual.

CSV will hold the domain granted access or the administrator granting
access accountable. SPF however holds whoever authorized the server
accountable. Those that authorize the server are likely not
responsible for who has access or who uses their domain. Yes, it is
possible the server may force this restriction. There are also
domain owners that will not trust such restrictions, and will want
their own IP address that is never shared with other domains. I want
to see what email service provider will indemnify there customers
from others using their domain on the server.

-Doug

Alan DeKok

2005-07-22 21:58:04 UTC

Post by Kjetil Torgrim Homme
no one can tell how the reputation services for CSV will operate, but
we can look at the DNSBLs in use today. several of these have a
stated policy of never removing any IP addresses used for spamming.

The solution to abusive reputation providers is well-known, at least
outside of the computer world. See various "eco-friendly" logos, and
how their chain of responsibility (i.e. certification) is structured.

You need at least a two-level reputation service. One which
interacts with customers, and the other which certifies the reputation
services. This structure has been demonstrated to solve a lot of
issues with abusive and/or corrupt reputation services.

Alan DeKok.

Douglas Otis

2005-07-23 11:54:36 UTC

Post by Alan DeKok
You need at least a two-level reputation service. One which
interacts with customers, and the other which certifies the reputation
services. This structure has been demonstrated to solve a lot of
issues with abusive and/or corrupt reputation services.

There is a conflict of interests which may erode the integrity of what
is typically described as accreditation. When the revenue stream is
primarily from senders, then these services will likely respond to the
desires of the senders. When the revenue stream is primarily from the
recipients, then services will likely respond to the desires of the
recipients. There is often a large difference between these two
desires.

Having said that, there may be an additional role to supplement the
basic trustworthiness of the communication. Such a service could be
used in conjunction with recipient based services, as a check against
the sender based service. Verifying keys comes to mind which is
typically the role of a CA. A CA will normally worry about getting
paid, and by whom. They are typically more concerned about getting the
'by whom' part right to protect their reputation as a CA.

Rather than just using a lock icon to indicate security, each CA should
offer their own short-cut icon that prefixes the name being validated.
|
---------------------
| CA | example.com |
------------------------

This information should appear without expecting the user to investigate
the source of the certificate. These two pieces of information can be
used together. A CA run by the FDIC for example, should know who are
the banks. You as a consumer, may want to know what is the better bank
to do business with, which will require a different service that offers
information on behalf of the consumer rather than the bank.

-Doug

Alan DeKok

2005-07-23 17:12:21 UTC

Post by Douglas Otis
There is a conflict of interests which may erode the integrity of what
is typically described as accreditation. When the revenue stream is
primarily from senders, then these services will likely respond to the
desires of the senders. ...

Exactly. Which is why a two-level system solves a lot of those issues.

Did you have comments about a two-level system, or were you just
agreeing that one-level reputation systems are problematic?

Tying multiple first-tier reputation services together won't help.
The result is still a first-tier reputation service.

Alan DeKok.

Dave Crocker

2005-07-24 06:52:05 UTC

I would hope that reputation services accessed with CSV's DNA are not "for" CSV.

CSV provides a query mechanism, but what is significant about reputation ratings
is not the access method but the nature of the identity being assessed and the
policies for assessing it.

The identity that CSV covers is the administrator of a host name that is cited
by the client SMTP. More simply, CSV involves the identity of an MTA operator.

It is not an accident that CSV targets the same kinds of identities for which
there is the most experience with white- and black-lists. Although they use IP
Addresses, they pertain to operations identities, not author identities.

Hence, it is certainly reasonable to look at the range of existing white- and
black-list operations and project that their considerable variation in
assessment policies would be similar to the listing services that might be
queried with CSV's DNA.

Post by Kjetil Torgrim Homme
as the two reputations in CSV aren't connected, it is safe to say that
the recovery will be quick...

No doubt my confusion is from not reading this thread carefully enough, but I do
not know what "two" reputations are being referenced. CSV deals with one
identity, namely the host name provided in the client smtp's helo/ehlo command.

Post by Alan DeKok
If CSV uses "MAIL FROM" for reputation, then it has pretty much
the same issue as any other proposal using that field.

yes, I think it has been established by now that "MAIL FROM" can't be
used without breaking e-mail or being vulnerable to replay attacks.

At some point, having detailed discussion about a specification ought to presume
that participants have read the specifications.

d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net

Kjetil Torgrim Homme

2005-07-24 13:17:33 UTC

no one can tell how the reputation services for CSV will operate, [...]

I would hope that reputation services accessed with CSV's DNA are not "for" CSV.
[...]
The identity that CSV covers is the administrator of a host name that is cited
by the client SMTP. More simply, CSV involves the identity of an MTA operator.

well, perhaps. it seems to me that the CSV-DNA spec is a bit
schizophrenic on this point. it makes sure there will be no future
conflicts with similar schemes for other services (e.g., HTTP servers),
but on the other hand it's specifically tailored to client SMTP
("_VOUCH._SMTP" etc.). the EHLO domain name can be chosen relatively
arbitrarily, and you should be careful not to claim that reputable use
of the EHLO name extends to other services. the method of ascertaining
the name is an inextricable part of the authenticated identity.

more relevant to the discussion, if DNA can be applied to identities
established with mechanisms other than the implied CSV-CSA, this MUST in
my humble opinion be tagged in the accreditation record with a service
different from "MARID", and as such the interpration will be out of
scope for the CSV-DNA specification. we do not want to (potentially)
repeat the MAIL FROM vs. PRA mistake, do we?

as the two reputations in CSV aren't connected, it is safe to say that
the recovery will be quick...

the scenario was that a domain owner had chosen an e-mail provider with
bad reputation for its MTA name. if the domain owner switches e-mail
provider, the new provider's MTA name will be completely independent,
and the domain owner's sent e-mail will instaneously be rid of the bad
reputation.

Post by Dave Crocker
At some point, having detailed discussion about a specification ought to presume
that participants have read the specifications.

I'm sorry, I have only read the specifications, and have not followed
the discussion on mailing lists. I guess I should jump in and ask for
clarifications to the text where I feel it's needed.

--
Kjetil T.

Dave Crocker

2005-07-24 17:23:36 UTC

Post by Kjetil Torgrim Homme
but on the other hand it's specifically tailored to client SMTP
("_VOUCH._SMTP" etc.). the EHLO domain name can be chosen relatively
arbitrarily, and you should be careful not to claim that reputable use
of the EHLO name extends to other services.

that might be why the _vouch qualifies (is specifically linked to) _smtp.

Post by Kjetil Torgrim Homme
if DNA can be applied to identities
established with mechanisms other than the implied CSV-CSA, this MUST in
my humble opinion be tagged in the accreditation record with a service
different from "MARID", and as such the interpration will be out of
scope for the CSV-DNA specification. we do not want to (potentially)
repeat the MAIL FROM vs. PRA mistake, do we?

I've read this paragraph several times. I am simply not understanding it. At
the least, I have no idea what the reference to tagging with a service different
from marid means.

Post by Kjetil Torgrim Homme
as the two reputations in CSV aren't connected, it is safe to say that
the recovery will be quick...

That's why the helo/ehlo name is associated with the MTA operator. Your
phrasing suggests that the "domain owner" is somehow separate from the "email
provider", whereas the ehlo name IS the email provider.

d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net

Kjetil Torgrim Homme

2005-07-24 18:10:00 UTC

that might be why the _vouch qualifies (is specifically linked to) _smtp.

yes, but it doesn't link it to EHLO. there are other identities which
can be used to for SMTP clients. if there isn't, why did you object
when I implied CSV-DNA only can be used with CSV-CSA?

I've read this paragraph several times. I am simply not understanding it. At
the least, I have no idea what the reference to tagging with a service different
from marid means.

since I clearly isn't very good at explaining myself, let's start with
first principles. we have an domain name which is authenticated somehow
whose reputation we want to check. we look up PTR records, and as per
CSV-DNA, these begin with "_vouch._smtp". at this point, we know the
pointers should link to CSV-DNA compliant reputation services. we do
not know whether the name space of our authenticated domain name matches
the name space of identities employed by the reputation service. this
name space must be declared in the TXT RR, and it's the very first field
in a record. the draft uses the term "service" rather than "name
space", however. draft -02 says the service name MUST be "MARID", but
it does not identify the name space used. being part of the CSV suite,
it is natural to ASSUME the CSV-CSA name space is used, but as far as I
can tell, the specification is entirely silent on this subject.

now, you were claiming CSV-DNA could be used with other mechanisms, and
therefore name spaces, than CSV-CSA: "I would hope that reputation
services accessed with CSV's DNA are not "for" CSV."

I don't think that is true with -02 of the draft, since those
accreditation records necessarily would have to break a MUST, namely the
name of the service, or else risk misinterpretation of the record.

avoiding this problem is easy, the accreditation records should include
a fixed word identifier as a preamble (say "DNA"), so that it is clear
that
DNA,MARID,1,A
and
DNA,MX,1,A
both should be handled with the semantics of CSV-DNA (the "MX" name
space is just an example and at this time unspecified). the current
alternative is
MARID,1,A
and
MX,1,A
leaving the latter completely undefined, requiring its specification to
copy elements from the CSV-DNA document rather than just build upon it.

(the service name "MARID" is not appropriate, btw, it really should be
"CSA" to avoid unnecessary confusion.)

Post by Kjetil Torgrim Homme
the scenario was that a domain owner had chosen an e-mail provider with
bad reputation for its MTA name. if the domain owner switches e-mail
provider, the new provider's MTA name will be completely independent,
and the domain owner's sent e-mail will instaneously be rid of the bad
reputation.

I don't think it's worthwhile to try explain this further, I suggest you
just go back and read the thread rather than have me rehash it here.

--
Kjetil T.

Dave Crocker

2005-07-24 18:39:31 UTC

Post by Kjetil Torgrim Homme
avoiding this problem is easy, the accreditation records should include
a fixed word identifier as a preamble (say "DNA"), so that it is clear
that
DNA,MARID,1,A
and
DNA,MX,1,A

I think that you are confusing the semantics with the mechanism. DNA provides a
mechanism for reporting some information. The semantics exist outside the
mechanism.

1. The client-smtp reputation/accreditation assessment that is associated with a
particular domain name exists in its own right, independent of the mechanism
used (eg, DNA) to report it.

2. A particular client choose to declare itself associated with that domain
name. CSA is one way to make that declaration.

You are suggesting that the assessment information be labeled according to the
mechanism used to communicate it. That's not a good idea.

The assessment does not depend on the reporting mechanism. The assessment
information certainly *does* need to be careful in the way it specifies the
identity and labeling what is being assessed, but it should not specify how it
is reported.

d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net

Kjetil Torgrim Homme

2005-07-24 19:10:41 UTC

I think that you are confusing the semantics with the mechanism. DNA provides a
mechanism for reporting some information. The semantics exist outside the
mechanism.

okay, let's say "MARID" denotes "DNA", but that leaves no method of
declaring name space.

Post by Dave Crocker
1. The client-smtp reputation/accreditation assessment that is associated with a
particular domain name exists in its own right, independent of the mechanism
used (eg, DNA) to report it.

there is no single correct definition of "domain name", just look at the
discussions here suggesting it can be determined based on reverse DNS,
MAIL FROM, PRA or EHLO, or any number of other methods. declaring that
_any_ method of authentication is equally valid is a recipe for
disaster. the accreditation record must declare stringently what it
covers.

Post by Dave Crocker
2. A particular client choose to declare itself associated with that domain
name. CSA is one way to make that declaration.

yes. when there are many methods, the client may choose to point to a
reputation service which has accrued reputation based on some other name
space.

Post by Dave Crocker
You are suggesting that the assessment information be labeled according to the
mechanism used to communicate it. That's not a good idea.
The assessment does not depend on the reporting mechanism. The assessment
information certainly *does* need to be careful in the way it specifies the
identity and labeling what is being assessed, but it should not specify how it
is reported.

not the reporting mechanism per se, but the name space used is a crucial
part of the identity.

CSV-DNA must either be locked to CSV-CSA, or it must explicitly cater
for other name spaces.

--
Kjetil T.

John Leslie

2005-07-26 22:31:58 UTC

Post by Dave Crocker
I think that you are confusing the semantics with the mechanism.
DNA provides a mechanism for reporting some information. The
semantics exist outside the mechanism.

okay, let's say "MARID" denotes "DNA", but that leaves no method of
declaring name space.

"MARID", you should recall, stands for "MTA Authorization Records
in DNS", which is exactly the subject of DNA. So "MARID" denotes the
subject matter; DNA specifies how the reporting is done.

Post by Dave Crocker
1. The client-smtp reputation/accreditation assessment that is
associated with a particular domain name exists in its own right,
independent of the mechanism used (eg, DNA) to report it.

there is no single correct definition of "domain name",

Actually, DNS defines it quite exactly. That is the context here.

Post by Kjetil Torgrim Homme
just look at the discussions here suggesting it can be determined
based on reverse DNS, MAIL FROM, PRA or EHLO, or any number of other
methods.

There are a number of fields which contain domain-names. The DNA
mechanism could in principle be applied to any of them. In fact, we
initially wrote DNA such that it could be widely applied; only later
did we limit it to the HELO field and CSV.

Post by Kjetil Torgrim Homme
declaring that _any_ method of authentication is equally valid is
a recipe for disaster.

I can't think of anyplace that has been declared.

Post by Kjetil Torgrim Homme
the accreditation record must declare stringently what it covers.

DNA has declared that as stringently as we believe appropriate.
Beyond that, it's up to each accreditation service to declare the
exact meaning of their accreditation.

(There is some ongoing discussion about recommending temporary
errors, but it's unlikely to reach consensus. OTOH, there is consensus
that _reputation_ services should have a way to recommend temporary
errors and/or greylisting.)

Post by Dave Crocker
2. A particular client choose to declare itself associated with
that domain name. CSA is one way to make that declaration.

yes. when there are many methods, the client may choose to point
to a reputation service which has accrued reputation based on some
other name space.

In CSV, sending SMTP client domains point to _accreditation_ services.
The receiving SMTP server would be the party using reputation services.
We've tried to keep that distinction clear through the CSV specs.

Post by Dave Crocker
You are suggesting that the assessment information be labeled
according to the mechanism used to communicate it. That's not a
good idea.
The assessment does not depend on the reporting mechanism. The
assessment information certainly *does* need to be careful in the
way it specifies the identity and labeling what is being assessed,
but it should not specify how it is reported.

not the reporting mechanism per se, but the name space used is a
crucial part of the identity.
CSV-DNA must either be locked to CSV-CSA, or it must explicitly cater
for other name spaces.

DNA is locked to CSA, though a similar mechanism could easily cater
to other name-spaces.

It might help to point out that in section 6 of the DNA spec, we
intended that in "Name: <domain being checked>.<Accreditation Service>"
"<Accreditation Service>" is not necessarily the name of the service
provider: if the same provider provides different accreditation services
they might well choose to use subdomains for different services. We
believe there is ample room for DNA-like mechanisms covering names
obtained from other sources than HELO strings. We do not believe there
is any need to limit how these might be specified and reported.

--
John Leslie <***@jlc.net>

Kjetil Torgrim Homme

2005-07-27 12:23:45 UTC

Post by Kjetil Torgrim Homme
okay, let's say "MARID" denotes "DNA", but that leaves no method of
declaring name space.

"MARID", you should recall, stands for "MTA Authorization Records
in DNS", which is exactly the subject of DNA. So "MARID" denotes the
subject matter; DNA specifies how the reporting is done.

okay, I thought "MARID" was dead and that references to it were
obsolete. in any case, I think it's better to use "how it is done" as
the tag, since the tag identifies exactly that for an implementation.
if you envision other methods later, it's prudent to change it to say
both "MARID" and "DNA". or just "DNA".

Post by Kjetil Torgrim Homme
there is no single correct definition of "domain name",

Actually, DNS defines it quite exactly. That is the context here.

the draft does not say so. it is common usage to say "domain name"
about the name of the zone, and "host name" about entries in that zone.
I therefore think "domain name" should be explicitly defined (with a
reference to RFC 1034).

Post by Kjetil Torgrim Homme
just look at the discussions here suggesting it can be determined
based on reverse DNS, MAIL FROM, PRA or EHLO, or any number of other
methods.

that's fine. the problem is that the accreditation service can't say
which are valid, or even which service it has evaluated. an SMTP client
can point to an accreditation service which validates web content on the
same domain name. "_VOUCH._SMTP" allows the client system to point to a
accreditation service specific to SMTP, and it could also add a
(hypothetical) "_VOUCH._HTTP" in cases where there's running a web
server on the same host. which of these records were used, is not known
to the accreditation service, it operates blind.

Post by Kjetil Torgrim Homme
declaring that _any_ method of authentication is equally valid is
a recipe for disaster.

I can't think of anyplace that has been declared.

it has been declared by omission.

Post by Kjetil Torgrim Homme
the accreditation record must declare stringently what it covers.

DNA has declared that as stringently as we believe appropriate.
Beyond that, it's up to each accreditation service to declare the
exact meaning of their accreditation.

then you need to give them the capability.

Post by Dave Crocker
2. A particular client choose to declare itself associated with
that domain name. CSA is one way to make that declaration.

yes. when there are many methods, the client may choose to point
to a reputation service which has accrued reputation based on some
other name space.

sorry about the sloppy usage, but please explain the difference. the
word "reputation" is only used twice in the specs, and not in what
appears to be a terminology establishing context.

Post by Kjetil Torgrim Homme
not the reporting mechanism per se, but the name space used is a
crucial part of the identity.
CSV-DNA must either be locked to CSV-CSA, or it must explicitly cater
for other name spaces.

DNA is locked to CSA, though a similar mechanism could easily cater
to other name-spaces.

Dave Crocker doesn't seem to agree with you, which to me clearly
indicates the spec needs to be more explicit on this point.

Post by John Leslie
It might help to point out that in section 6 of the DNA spec, we
intended that in "Name: <domain being checked>.<Accreditation Service>"
"<Accreditation Service>" is not necessarily the name of the service
provider: if the same provider provides different accreditation services
they might well choose to use subdomains for different services. We
believe there is ample room for DNA-like mechanisms covering names
obtained from other sources than HELO strings. We do not believe there
is any need to limit how these might be specified and reported.

since the DNA spec disallows reuse of the spec with a different name
space (the record MUST say "MARID", and you now clarified "DNA is locked
to CSA"), I'd say it limits future usage significantly.

the fix is simple: introduce a name space identifier to the
accreditation record.

--
Kjetil T.

John Leslie

2005-07-28 10:11:35 UTC

Post by John Leslie
"MARID", you should recall, stands for "MTA Authorization Records
in DNS", which is exactly the subject of DNA. So "MARID" denotes the
subject matter; DNA specifies how the reporting is done.

okay, I thought "MARID" was dead and that references to it were
obsolete.

The MARID Working Group has been closed. That doesn't automatically
make references to it obsolete; however, it does suggest that there
might be a more appropriate string to tag the DNA accreditation TXT RR.

Post by Kjetil Torgrim Homme
in any case, I think it's better to use "how it is done" as the tag,
since the tag identifies exactly that for an implementation.

"How it is done" doesn't covey much (to me, anyway). It's really
just a validity check, anyway, since the position of the TXT record
in DNS basically defines its meaning. And, as I said, the exact meaning
must be assigned by the accrediting organization.

(Recall that CSA completely answers the question of whether the
sending SMTP client is authorized by the domain cited in the HELO: the
question addressed by accreditation is whether that domain has policies
and practices which "adequately" protect against abusive emails being
sent.)

Post by Kjetil Torgrim Homme
there is no single correct definition of "domain name",

Actually, DNS defines it quite exactly. That is the context here.

Someone else is going to have to weigh in here: I don't understand
Kjetil's point, so I can't propose text.

Post by Kjetil Torgrim Homme
just look at the discussions here suggesting it can be determined
based on reverse DNS, MAIL FROM, PRA or EHLO, or any number of other
methods.

that's fine. the problem is that the accreditation service can't say
which are valid, or even which service it has evaluated.

Quite the contrary: only the accreditation service _can_ say what
service it has evaluated. The expectation in DNA is that the operation
of a sending SMTP client is being evaluated; but DNA cannot enforce it.
It is up to reputation services to determine whether the evaluation by
each accreditation service is useful for its purposes.

Where the domain-name may have been found is quite immaterial. DNA
states that the HELO string shall be treated as identification of the
management of the SMTP client which sends it, subject to verification
through DNS lookup of SRV records that the domain in question authorizes
a client at that IP address to claim that association.

But for purposes of accreditation, the service doing accreditation
is expected only to accredit the policies and practices of the
management. If it is asked about a name obtained some other way, it
cannot be aware of how that name was obtained.

We are well aware that accreditation/reputation issues arise for
the various flavors of SPF: the DNA spec does not intend to make any
statement about how such accreditation/reputation issues might be
handled.

(IMHO, if there is an issue to be raised of confusion with SPF
reputation, it sits with the "_VOUCH._SMTP" substring in the PTR lookup,
not with the tag string of the accreditation record itself. And I'm
prepared to defend the "_VOUCH.-SMTP" choice, since the SMTP protocol
covers transport, not message content.)

Post by Kjetil Torgrim Homme
an SMTP client can point to an accreditation service which validates
web content on the same domain name. "_VOUCH._SMTP" allows the client
system to point to a accreditation service specific to SMTP, and it
could also add a (hypothetical) "_VOUCH._HTTP" in cases where there's
running a web server on the same host. which of these records were
used, is not known to the accreditation service, it operates blind.

I entirely agree. (You make my point, I think...)

(It is possible that something within the text of Section 4 of the
DNA spec is confusing folks here. I will point out that the "_VOUCH._SMTP"
substring of the Target clarifies that the PTR record in question is to
recommend an accreditation service to check for DNA purposes, and that
other PTR records may also exist at the same position in the DNS tree.
DNA does not require that any actual query be done to that Target string,
but such a query would be expected to aid a in finding the explanation
of what is being accredited.)

Post by Kjetil Torgrim Homme
the accreditation record must declare stringently what it covers.

DNA has declared that as stringently as we believe appropriate.
Beyond that, it's up to each accreditation service to declare the
exact meaning of their accreditation.

then you need to give them the capability.

I fail to see how we could "give" or "take away" such a capability.

Post by Kjetil Torgrim Homme
CSV-DNA must either be locked to CSV-CSA, or it must explicitly
cater for other name spaces.

DNA is locked to CSA, though a similar mechanism could easily cater
to other name-spaces.

Dave Crocker doesn't seem to agree with you, which to me clearly
indicates the spec needs to be more explicit on this point.

Someone else will have to propose text to make this more explicit.
(Dave can speak for himself if he disagrees with anything I've posted.)

Post by John Leslie
It might help to point out that in section 6 of the DNA spec, we
intended that in "Name: <domain being checked>.<Accreditation Service>"
"<Accreditation Service>" is not necessarily the name of the service
provider: if the same provider provides different accreditation
services they might well choose to use subdomains for different
services. We believe there is ample room for DNA-like mechanisms
covering names obtained from other sources than HELO strings. We
do not believe there is any need to limit how these might be specified
and reported.

since the DNA spec disallows reuse of the spec with a different name
space (the record MUST say "MARID", and you now clarified "DNA is
locked to CSA"), I'd say it limits future usage significantly.

The meaning of the accreditation record is delineated by its position
in the DNS tree, not its introductory tag.

Post by Kjetil Torgrim Homme
the fix is simple: introduce a name space identifier to the
accreditation record.

I can't imagine any way to define such a "name space identifier"
which would do the job half as well as its position in the DNS tree.
Nor, IMHO, should we make any pretense we can do so.

--
John Leslie <***@jlc.net>

John Leslie

2005-07-28 10:52:35 UTC

(Second try: I'm trying to adjust myself to Paris time; it's not
working well ;^)

okay, I thought "MARID" was dead and that references to it were
obsolete.

Post by Kjetil Torgrim Homme
in any case, I think it's better to use "how it is done" as the tag,
since the tag identifies exactly that for an implementation.

Post by Kjetil Torgrim Homme
there is no single correct definition of "domain name",

Actually, DNS defines it quite exactly. That is the context here.

Someone else is going to have to weigh in here: I don't understand
Kjetil's point, so I can't propose text.

Post by Kjetil Torgrim Homme
just look at the discussions here suggesting it can be determined
based on reverse DNS, MAIL FROM, PRA or EHLO, or any number of other
methods.

that's fine. the problem is that the accreditation service can't say
which are valid, or even which service it has evaluated.

Post by Kjetil Torgrim Homme
the accreditation record must declare stringently what it covers.

DNA has declared that as stringently as we believe appropriate.
Beyond that, it's up to each accreditation service to declare the
exact meaning of their accreditation.

then you need to give them the capability.

I fail to see how we could "give" or "take away" such a capability.

Post by Kjetil Torgrim Homme
CSV-DNA must either be locked to CSV-CSA, or it must explicitly
cater for other name spaces.

DNA is locked to CSA, though a similar mechanism could easily cater
to other name-spaces.

Dave Crocker doesn't seem to agree with you, which to me clearly
indicates the spec needs to be more explicit on this point.

Someone else will have to propose text to make this more explicit.
(Dave can speak for himself if he disagrees with anything I've posted.)

Post by John Leslie
It might help to point out that in section 6 of the DNA spec, we
intended that in "Name: <domain being checked>.<Accreditation Service>"
"<Accreditation Service>" is not necessarily the name of the service
provider: if the same provider provides different accreditation
services they might well choose to use subdomains for different
services. We believe there is ample room for DNA-like mechanisms
covering names obtained from other sources than HELO strings. We
do not believe there is any need to limit how these might be specified
and reported.

since the DNA spec disallows reuse of the spec with a different name
space (the record MUST say "MARID", and you now clarified "DNA is
locked to CSA"), I'd say it limits future usage significantly.

The meaning of the accreditation record is delineated by its position
in the DNS tree, not its introductory tag.

Post by Kjetil Torgrim Homme
the fix is simple: introduce a name space identifier to the
accreditation record.

John Leslie

2005-07-22 11:43:42 UTC

Post by John Leslie
I read Kjetil's argument to be that with SPF, your reputation will
not quickly recover, and will inhibit email "From" your domain for
quite a while,

Agreed. The essential argument has been that CSV's reputation is
more granular: it's the reputation of the MTA (or group of MTAs)
which will suffer, not the reputation of the domain listed in the
"From" address. Thus, you don't need to wait for the reputation to
recover: you can simply change MTAs to one with a good reputation.

Post by Alan DeKok
The confusion here is that there are multiple domains that may be
used for authorization. EHLO, and MAIL FROM. When CSV uses EHLO,
sending "MAIL FROM" a particular domain is invisible to CSV, because
it's not looking at MAIL FROM. And in that case, reputation is tied
to MTA, not to the "MAIL FROM" domain.

Exactly.

Post by Alan DeKok
If CSV uses "MAIL FROM" for reputation, then it has pretty much the
same issue as any other proposal using that field.

CSV never pays any attention to MAIL-FROM.

--
John Leslie <***@jlc.net>

Dave Crocker

2005-07-21 23:59:16 UTC

Post by Alan DeKok
Where SPF ties reputations to domains, CSV ties it to IP's. Since
domains are hosted at IP's

CSV uses host domain names, to identify client MTAs.

That client's IP address is derived during the authentication phase, but the
domain name is the identity used for CSV processing, including the Domain Name
Accreditation portion.

d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net

Alan DeKok

2005-07-22 01:36:45 UTC

Post by Alan DeKok
Where SPF ties reputations to domains, CSV ties it to IP's. Since
domains are hosted at IP's

CSV uses host domain names, to identify client MTAs.

The comment I was addressing discussed CSV tying reputation to IP's,
which is all I was responding to.

Post by Dave Crocker
That client's IP address is derived during the authentication phase,
but the domain name is the identity used for CSV processing,
including the Domain Name Accreditation portion.

Which sort of negates the original comment that claimed SPF has a
problem because it ties reputation to domains, whereas CSV doesn't
have that problem.

Alan DeKok.

Dave Crocker

2005-07-22 04:55:03 UTC

Post by Dave Crocker
CSV uses host domain names, to identify client MTAs.

The comment I was addressing discussed CSV tying reputation to IP's,
which is all I was responding to.

CSV uses domain names, to refer to accreditation information. It does not use
IP Addresses.

d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
]

Alan DeKok

2005-07-22 17:15:04 UTC

Post by Alan DeKok
The comment I was addressing discussed CSV tying reputation to IP's,
which is all I was responding to.

CSV uses domain names, to refer to accreditation information. It does not
use IP Addresses.

Once again: using the assumptions of the original poster (however
right or wrong), I showed that the original argument was invalid.

You appear to have concluded that my quoting of those assumptions
means I believe them. This conclusion is illogical.

If I quote the Bible, will you tell people I think I'm Jesus Christ?

Alan DeKok.

Scott Kitterman

2005-07-21 14:43:43 UTC

-----Original Message-----
Sent: Thursday, July 21, 2005 1:18 AM
Subject: Re: [spf-help] Re: SPF and SenderID
I would say there is another option that should be considered. Not
publishing SPF records. Many recipients are rejecting '~' and '?' which
creates an immediate problem for the sender with forwarding issues that
depend upon this exploited feature.

I'm curious what the basis for this statement is. Do you have statistics?

As a domain owner that relies entirely on shared MTAs, many of which are
vulnerable to cross user forgery, almost all mail that comes from my domain
(including this message) gets a Neutral ("?") result. It's been this way
for more than a year. So far, I've had one mail rejection as a result. I
contacted that person via another channel and they thanked me for pointing
out that they had set up their system wrong. Based on my experience, I
would say that no one is rejecting mail due to a Neutral result.

In addition to my personal experience, I also help handle submissions to the
SPF web site. In the approximately 1,000 submissions we've had in the last
6 months there haven't been ANY that were caused by a Neutral rejection. If
this were a common phenomenon, I believe that people would be complaining.

WRT to softfail ("~"), it's a little different, there we are seeing
submissions that relate to rejections on a softfail result. The numbers are
small (I find 15 out of 1,073), but it does happen. This is also entirely
unrelated to the question of should a domain owner that is using a shared
server that has the potential to be subject to cross-user forgery give a
Neutral result. I thought that was the topic we were on.

I've done this for a long time and it works for me.

Scott Kitterman

Douglas Otis

2005-07-22 17:04:50 UTC

Post by Scott Kitterman

Post by Douglas Otis
I would say there is another option that should be considered. Not
publishing SPF records. Many recipients are rejecting '~' and '?' which
creates an immediate problem for the sender with forwarding issues that
depend upon this exploited feature.

I'm curious what the basis for this statement is. Do you have
statistics?

No statistics. I am repeating comments I have heard from
administrators at the meeting. When perhaps a fraction of a percent
of non-abusive domains publish these records, saying 'many' would of
course be like describing the fleas of a flea. It was not clear if
this was the result of some type of reputation response due to abuse
of the '?', which effectively says 'never mind'. If you feel this to
be in error then '?'. It does follow that I had expected and would
be a natural response when seeing this as means to prevent the
exploit of a neutral result.

-Doug

Scott Kitterman

2005-07-25 02:16:59 UTC

-----Original Message-----
Sent: Friday, July 22, 2005 1:05 PM
To: Scott Kitterman
Cc: MARID
Subject: Re: [spf-help] Re: SPF and SenderID

Post by Scott Kitterman

I'm curious what the basis for this statement is. Do you have
statistics?

Some recent statistics posted on spf-discuss showed, IIRC, that Neutral was
not a strong spam sign. Roughly half of Neutral results were classified Ham
and roughtly half as Spam. Given that most e-mail being sent today is Spam,
Neutral results actually make a very poor indicator for Spam.

There are some popularly forged domains for which this is not true. There
was also some recent discussion about strategies to deal with this. I don't
recall anyone advocating outright rejection of all messages with Neutral
results. The sensible strategy seemed to set thresholds and start to reject
once a certain number had been received in a certain period.

Softfail was a decent indicator of forged spam, much different than Neutral
as I recall.

Scott Kitterman

Hector Santos

2005-06-15 16:40:03 UTC

----- Original Message -----
From: "Douglas Otis" <***@mail-abuse.org>
To: <spf-***@v2.listbox.com>
Cc: "IMB Recipient 1" <***@equinoccio.com>;
<ietf-***@imc.org>
Sent: Wednesday, June 15, 2005 10:29 AM
Subject: Re: [spf-help] Re: SPF and SenderID

Post by Frank Ellermann
MS tried to pull the stunt that v=spf1 is by default a
part of PRA. This is a lie, the IESG knows that it's a
lie, so senderid-lyon-core-01 can never pass as an RfC.
Bye, Frank (Cc: mxcomp)

First, thanks for not writing a thesis on the subject.

Second..................

Oh stop it Doug.

Sender-ID will go down in the annals of computer history as yet another
PAYLOAD "Get Pass the Door" security exploit that Microsoft pushes upon the
industry in the name of non-existence "virtual email security innovation."

It does not qualify as part of the "Trust Worthy Initiative" and Gates will
put another foot in his mouth if he claims it is.

Sender-ID is an unreliable PAYLOAD protocol and this is NOT want the
industry is looking for. So you can keep down this ad-nausem path of
knocking SPF every which way but loose, those who support Sender-ID will
suffer scalarbility consequences of getting killed with higher bandwidth
payloads. Hackers will BLAST away higher payloads just to help create the
scale issues. Customers who "just do it" because its part of the MS package
will then begin to blame MS as to why they didn't concentrate on a TRANSPORT
solution BEFORE THE JUNK is transferred I predict corporate mal-practice
and negligence suits because MS was very aware of the consequences.

If our customers want it, they will have to add it via MAIL FILTER hooks. We
will not take responsibility for fuzzy 2822 mail analysis technique and we
will NOT de-emphasize the R&D required for 2821 methods. Our system is
nearly 90-98% spam proof purely based on 2821 transactions.

Do you really understand the issue? I really don't think you do. It is
quite simple. A SPF FAIL is a FAIL. PERIOD. SENDER-ID is saying to NOT
accept this response and to ACCEPT the PAYLOAD to do more checking on
INFORMATION that MAY NOT be there and if was, the end results can just be as
POOR in trust.

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

Dean Anderson

2005-06-15 23:05:25 UTC