Subject: Re: [mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Jan 2009 15:44:32 -0800

On Jan 9, 2009, at 12:48 PM, Lisa Dusseault wrote:

> Hi Doug,
>
> Does anybody support your review of sender-auth-header, to the point  
> of believing that the document should not be published?  So far you  
> are still very much in the rough part of rough consensus.
>
> thanks,
> Lisa
>
> On Wed, Jan 7, 2009 at 1:14 PM, Douglas Otis <[email-masked]>  
> wrote:
>
>> Murray,
>>
>> There has been progress, but a few extremely critical security  
>> related areas still need to be addressed.
>>
>> I have posted a draft that reviews the sender-auth-header draft.
>>
>> The text and html versions are available at:
>>
>> http://www.ietf.org/internet-drafts/draft-otis-auth-header-sec-issues-00.txt
>> http://www.sonic.net/~dougotis/id/draft-otis-auth-header-sec-issues-00.html

Funny that you describe your concern as involving rough consensus.   
The draft itself can't decide when it should stop pretending about  
what defines authentication, and remains remains contradictory on this  
critical subject.

It states that only _authenticated_ information should be included  
within the "Authentication-Results" header for either Sender-ID or  
SPF.  At the same time, the draft defines Sender-ID and SPF as being  
an authorization method and _not_ the authentication of the domain.    
In fact, there is no way to know whether Sender-ID results were based  
upon SPF version 1 records in its current form, or whether a domain  
even intended positive results to affirm its identities, or whether  
just negative results of a Mail From were intended to mitigate back- 
scatter.  This leaves the issue of authentication itself clearly in  
the rough.

In addition, there is also the matter of encouraging the use of  
dangerous local-part macros when one wishes to obtain email-address  
annotations.  At least the Sender-ID specification states local-parts  
are _not_ verified.  What is providing the authorization remains  
unknown for SPF, even though the local-part is ignored in Sender-ID.   
In addition, there is no consensus between either Sender-ID or SPF as  
to which elements of a message are to be used to access version 1  
records.  Clearly, scoping issues are also in the rough.   
Nevertheless, this header is willing to label results of this mess  
"Authentication-Results".

The remedy being sought is to replace the local-part of the  
"authorizing" email-address with a converted string representing the  
IP address of the SMTP client that is being authorized.  This allows  
the authenticated origin of a message to be vetted, in addition to  
what _might_ be an authorizing domain.  A fair compromise.

While there are influential proponents of this draft, this draft and  
the experimental SPF and Sender-ID RFCs remain dangerous as written.   
With a few minor modifications, the Authentication-Header draft would  
become much safer.  Satisfying those that represent influential  
special interests should not cause the IETF to dismiss their  
stewardship role.   We all know there is money to made picking up the  
pieces, but there are more productive ways to make a living.

-Doug 
   
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Sat, 10 Jan 2009 00:31:20 -0800

>scatter.  This leaves the issue of authentication itself clearly in

Section 1.5.2 of the draft explains why Sender-ID and SFP is 
supported by this header field.  In a nutshell, it's about using a 
single header field instead of creating separate header fields for 
each mechanism.  According to the IESG Note in RFC 4406, Sender-ID 
participants should consider the advice given in Section 3.4 of that 
RFC to avoid the interoperability problem you mentioned.

It's nearly two years since these two specifications have been 
published.  If you believe that these two experiments are a failure, 
then post your observations so that a decision can be taken.  In my 
opinion, this would be through a Sender-ID and SPF discussion and 
not  one about this header field.

>records.  Clearly, scoping issues are also in the rough.

Section 2.4.3 of the draft covers SPF and Sender-ID Results.  I don't 
see any encouragement for the use of local-part macros in there.

>what _might_ be an authorizing domain.  A fair compromise.

Are there any implementations of the technique you are 
suggesting?  The feedback received from other implementors showed 
that they neither use the above technique nor do they support your 
point of view.

>pieces, but there are more productive ways to make a living.

Getting back to draft-otis-auth-header-sec-issues-00, Section 1 of 
the document encourages blocking the SMTP client IP address instead 
of blocking all mail from a domain.  This can lead to more than one 
domain being blocked when there are several domains hosted on the 
same IP address.

In discussions on the mail-vet discuss mailing list, some of your 
comments could, maybe erroneously, be interpreted as saying that the 
proposed header field is a barrage of marketing efforts for Sender-ID 
and SPF even though the proposal for the header field was spurred 
during the Domainkeys and DKIM work.  The proposed header field was 
discussed at IETF 70 during the DKIM Working Group session [1].  If 
there was any push to satisfy those that represent special interests, 
I am not aware of it.

As for your concerns about the IESG (I gather that you meant IESG and 
not IETF) stewardship role, I'll point to the fact that the IESG did 
not rubber stamp the specification for the proposed header during 
their evaluation.  The record shows that they raised several 
questions about it.

Regards,
-sm

1. http://www.ietf.org/proceedings/07dec/slides/dkim-0/dkim-0.ppt

---

From: TSG <[email-masked]>
Date: Sun, 11 Jan 2009 14:42:20 -0800

Douglas Otis wrote:
> just negative results of a Mail From were intended to mitigate 
> back-scatter.  This leaves the issue of authentication itself clearly 
> in the rough.
>
I suggest that the Technological sense of Authentication is irrelevant 
here. The real issue is what the Court's and those stuck using these 
protocols are forced to do to prove their actions. As such its the 
Court's Authentication Schema's that should be relied on here rather 
than what we as technologists would prefer.
> what _might_ be an authorizing domain.  A fair compromise.
Except that there is no way with the proposed model to prove that IP 
address is accurate and not being spoofed.
> stewardship role. 
The IETF is a steward of nothing. Its a Standards Platform and 
management process to create 'open and fair' internet standards.
> We all know there is money to made picking up the pieces, but there 
> are more productive ways to make a living.
>
> -Doug _______________________________________________
> Ietf mailing list
> [email-masked]
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM
>
>

---

From: Doug Otis <[email-masked]>
Date: Mon, 12 Jan 2009 18:53:20 -0800

On Jan 10, 2009, at 12:31 AM, SM wrote:

>> [...]
>> This leaves the issue of authentication itself clearly in the rough.
>

Many considered the IESG note to offer poor advice and it was limited  
to whether a message is accepted.  RFC 4406 recommends ignoring the  
stated scope of RFC 4408 records, and to add records explicitly  
supporting RFC 4406 which may produce negative results.  This was  
intended to overcome RFC 4406's scope modifications.  As such, a  
conflict between RFC 4408 and RFC 4406 remains.

The IESG warning, whether heeded or not, does not correct the issue  
regarding annotations that depend upon the kucherawy-sender-auth- 
header draft.  This draft describes Sender-ID or SPF as Authentication- 
Results "authenticating" a domain, while omitting the IP address of  
the SMTP client.  This prevents compliance with section 4.1 reputation  
check of an authenticated message origination that is needed to  
mitigate highly disruptive and injurious situations.

> not  one about this header field.

A concern remains about the label applied in the message by the  
kucherawy-sender-auth-header draft,  and its omission of critical  
origination information.  In one place the draft admits Sender-ID is  
_not_ about authentication, but then describes Sender-ID and SPF as  
authenticating.  The draft assumes the domain represents the  
origination of the message, rather than the IP address of the SMTP  
client.  At least the IP address has been weakly authenticated by TCP  
interaction, which is not true for the domain.

>> annotations.  []
> Section 2.4.3 of the draft covers SPF and Sender-ID Results.  I  
> don't see any encouragement for the use of local-part macros in there.

Section 2.4.3.  SPF and Sender-ID Results
...
,---
If the retrieved sender policies used to evaluate [SPF] and [SENDERID]  
do not contain explicit provisions for authenticating the local-part  
(see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported  
along with results for these mechanisms SHOULD NOT include the local- 
part.
'---

Placement within the authentication header has been made dependent  
upon an undefined and unsupported notion as to whether a local-part  
had been used to obtain authorization.  (Assuming this is what the  
draft meant when incorrectly using the word authenticating.)  Current  
record parsing libraries do not support qualifications made by Section  
2.4.3.   Since local-part macros are almost never used, and can be  
dangerous when allowed, the draft should not institute this dubious  
feature, and should preclude inclusion of the local-part instead.

>> "authorizing" email-address with a converted string representing  
>> the IP address of the SMTP client that is being authorized.  This  
>> allows the authenticated origin of a message to be vetted, in  
>> addition to what _might_ be an authorizing domain.  A fair  
>> compromise.
>
> Are there any implementations of the technique you are suggesting?   
> The feedback received from other implementors showed that they  
> neither use the above technique nor do they support your point of  
> view.

Are you recommending coercion to resolve conflicts?  Not all SMTP  
clients restrict the use the PRA, and yet some inbound provider can  
apply Sender-ID checks against a PRA that authorized the SMTP client  
with a version 1 SPF record.  When a fraudulent PRA headers appear to  
have been from a domain publishing RFC 4408 records, should all  
messages that then appear to be from this domain be blocked until they  
publish RFC 4406 records?  How else is this problem to be handled?

Not everyone believes they MUST, or even SHOULD, publish RFC 4406  
records when publishing RFC 4408 records.  It is not common for an MTA  
to restrict the use of a PRA, although the SMTP client must be trusted  
to protect the PRA.  By including the IP address of the SMTP client, a  
reputation check of the SMTP client allows its Sender-ID "pass"  
results to be ignored when it fails to protect the PRA. This could  
avoid the need to block an entire domain publishing just version 1 RFC  
4408 records.   Why preclude an important option, and a necessary  
check as stated in section 4.1?  There has never been any reasonable  
justification for omitting the IP address of the SMTP client.  This IP  
address must be passed to the SPF record evaluation process!

> [...]

It might be that Sender-ID pass results needs to be ignored whenever  
it has been determined that the SMTP client fails to protect PRAs.  In  
addition, when access to the SMTP client has been compromised, often  
other servers continue to operate.  When the kucherawy-sender-auth- 
header draft enables confidence artist's an easy exploit with  
unrestricted PRAs, there will be a need to report support of Sender-ID  
by SMTP client.

> proposed header field is a barrage of marketing efforts for Sender- 
> ID and SPF even though the proposal for the header field was spurred  
> there was any push to satisfy those that represent special  
> interests, I am not aware of it.

This draft adopted the erroneous, overstated, and misleading  
terminology used by those marketing email path registration.   
Importantly, the recommended remedy allows annotating a message to  
remain complaint with section 4.1 which states the reputation of the  
_authenticated_ origin of the message be checked first.  Once again,  
only the IP address of the SMTP client will have been (weakly)  
authenticated by way of the TCP exchange.  If the IP address is in  
doubt, so is any authorization of that address.

Most domain checks occur when visiting a web page.  From there, use of  
folder placement utilities can eliminate much of the need for domain  
reputation checks to guard against look-alike exploits.  By including  
both the domain and the IP address of the SMTP client in the  
authentication-results, the annotation application can decide whether  
folder placement removes a need to check the domain reputation, but it  
should always check the reputation of the SMTP client.

> As for your concerns about the IESG (I gather that you meant IESG  
> and not IETF) stewardship role, I'll point to the fact that the IESG  
> did not rubber stamp the specification for the proposed header  
> during their evaluation.  The record shows that they raised several  
> questions about it.

Being an idealist hoping that both IESG and the IETF do not knowingly  
accept negligently misleading drafts that enable confidence artists  
exploits, DDoS attacks, or that have a potential to be highly  
disruptive, it would be both. :^)

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jan 2009 18:53:20 -0800

Doug Otis wrote:
> [SPF/Sender ID debate omitted]

The draft points out in its Security Considerations (section 7.7) that issues
which may exist in the message evaluation methods it covers apply here as
well, and admonishes implementors to be aware of them.  The context of
this draft is not the place to re-open those old debates.

That this draft names SPF and Sender-ID as current methods does not
endorse or promote them.  The text is explicit about this as well (top of
section 4).  It merely acknowledges that they exist and are popular, and
thus enables the transmission of the output of those evaluations for sites
that use them.

> [...]  while omitting the IP address of

No, it doesn't.  An implementation can be perfectly compliant in other ways,
such as doing the reputation evaluation (be it IP or domain name) at the
border MTA.  There are a lot of good reasons for doing it that way too
discussed in the draft (and, in fact, reasons not to do it elsewhere).

> had been used to obtain authorization.  [...]

Your assertion presupposes no SPF implementation knows, or is capable of
knowing, whether or not it expanded a local-part macro.  Even if the former
is true, it's hardly a difficult thing to add, and the user of an SPF module
can easily err on the side of safety and assume that it wasn't in either
case.  The normative text in this draft covers that possibility.

>> neither use the above technique nor do they support your point of

I'd really like an answer to that question as well, since the work in the
draft is based on a number of real-world implementations that simply don't
do it the way you envision.  You seem, however, to prefer to dodge that
challenge.

> By including the IP address of the SMTP client, a
> results to be ignored when it fails to protect the PRA.

..which could be done at the border MTA, as it has the IP address of the
SMTP client.

Why do you insist that there is a need to repeat at the MUA work that's
already been done at the border MTAs (where experience suggests it belongs)?

> Why preclude an important option, and a necessary

It's not precluded, it's explicitly required.  It's just not the way you'd
like it done.

> _authenticated_ origin of the message be checked first.

You seem to be reading more into that language than exists.  Section 4.1 says
the reputation has to be checked, but makes no assertion that it has to be
checked at the MUA.  In fact, the draft contains a substantial amount of
guidance about the fact that such an architecture is possibly even detrimental.

Moreover, the "issues" rebuttal draft you posted contradicts itself.  For
example, your section 1 claims: "While there are cases where a domain is
controlled by a bad actor, often use of the bad domain is brief."  This is an
argument against your own proposed remedy.  The claim implies that timely
evaluation of reputation, i.e. when the message is in transit, is important.
Users, however, might read the delivered messages hours or even days later.
It follows that the active part of mail delivery (the MTAs), rather than the
passive part (the MUAs), is where such evaluations must be done.  Thus, doing
such evaluations when the MUA opens the message are not very valuable.  Your
remedy, therefore, contradicts one of your premises.

Finally, I'm afraid your theories about the motivations of this draft's
proponents are rather contrived.

Some of the issues you brought up regarding the draft, as well as the
results of the IESG review (which dealt with guidance language rather than
technological issues), were incorporated into its most recent versions.
You've been pushing this stuff, i.e. the remainder of your concerns, for
months now without any substantive support on any of the lists to which you
keep sending them, including during IETF Last Call which ended more than a
month ago.

Now, can we please, please move on?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jan 2009 18:53:20 -0800

[Apologies for the double-send; the headers got munged by my editor. -MSK]

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 13 Jan 2009 06:52:21 -0800

Murray S. Kucherawy wrote:
> endorse or promote them. 

Murray,

While I think no response was necessary, since Doug's note continues to utter 
the same concerns he always has, if you really felt compelled to respond, I wish 
you note had ended here.

There is no benefit in responding to material that is outside the scope of this 
effort, is not new and has no support.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Tue, 13 Jan 2009 09:02:07 -0800

Hi Doug,
At 18:53 12-01-2009, Doug Otis wrote:
>along with results for these mechanisms SHOULD NOT include the local- part.

"SHOULD NOT" is not an recommendation to do something.

>Are you recommending coercion to resolve conflicts?  Not all SMTP

The question I asked was about implementations.  I'm at a lost as to 
why you see that as recommending coercion.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Jan 2009 19:15:42 -0800

On Jan 12, 2009, at 6:53 PM, Murray S. Kucherawy wrote:

>> [...]  while omitting the IP address of the SMTP client.  This  
>> prevents compliance with section 4.1 reputation check of an  
>> authenticated message origination that is needed to mitigate highly  
>> disruptive and injurious situations.
>
> No, it doesn't.  An implementation can be perfectly compliant in  
> other ways, such as doing the reputation evaluation (be it IP or  
> domain name) at the border MTA.

The IP address of the SMTP client, as seen at the border, may not be  
captured by trace headers, nor are there reliable methods for  
selecting the border traces.  The goal of the Authentication-Results  
header is to permit subsequent annotations based upon its content  
regarding a message's origination.  Section 4.1 correctly recommends  
checking the reputation of the message's authenticated origination  
prior to applying annotations (revealing results).  Annotations  
regarding a message's origination represents a critical security  
function that should be treated separately from whether a message is  
to be accepted.

Unfortunately, the Authentication-Results header offers no reputation  
information, nor does it offer the authorization record type it relied  
upon, nor does it reveal the authenticated source of the message.   
Reputations of SMTP clients pertaining to what annotations are safe  
can indicate whether Mail From or PRA use appears to be restricted.   
This information can thereby provide non-disruptive methods to  
mitigate conflicts between RFC 4406 and RFC 4408.  The conflict may  
otherwise lead to dangerous annotations achieved by confidence artists  
that can easily take advantage of the significant difference between  
offering authorization and being authenticated, and how SPF records  
were intended to be used.

Ultimately, the application applying annotations must ensure the  
information captured by an Authentication-Results header is supported  
by the reputation of the parties involved.  For Sender-ID or SPF, this  
would be both the SMTP client and the inbound server adding the  
Authentication-Results header.  Checking the reputations of a domain  
offering the authorization might provide an indication of being a look- 
alike attack, but guarding against this risk is best handled at the  
border MTA, or through folder placements, and not by selective  
annotations as the draft suggests.

>  There are a lot of good reasons for doing it that way too discussed  
> in the draft (and, in fact, reasons not to do it elsewhere).

Reputation checks at the border are important, but they normally  
pertain to whether a message is to be accepted, and seldom are about  
which annotation is safe to apply.

Domain checks are unable to deal with compromised access in a non- 
disruptive manner, nor can domains selectively permit annotations  
based upon what the SMTP client may or may not protect.  When an SMTP  
client is found to not protect a particular scope, the lack of  
protection may impact what is safe to annotate for thousands of  
domains.  However, these domains can not be readily ascertained  
because SPF does not offer reverse listings. :^(

> Your assertion presupposes no SPF implementation knows, or is  
> capable of knowing, whether or not it expanded a local-part macro.   
> Even if the former is true, it's hardly a difficult thing to add,  
> and the user of an SPF module can easily err on the side of safety  
> and assume that it wasn't in either case.  The normative text in  
> this draft covers that possibility.

Having a message noticed and read is improved by gaining greater  
annotations and this represents a very strong incentive.  The  
currently unsupported (and fairly recent annotation qualification)  
along with a natural desire to obtain greater annotation will have the  
effect of promoting the use of dangerous local-part macro mechanisms.   
These macros are able to generate an unlimited number of different DNS  
transactions by exploiting cached SPF records.  The SPF macro  
mechanism offers a free DNS attack while spamming!

> I'd really like an answer to that question as well, since the work  
> in the draft is based on a number of real-world implementations that  
> simply don't do it the way you envision.  You seem, however, to  
> prefer to dodge that challenge.

There are systems now that can offer feedback within a few hundred  
seconds of an exploit.  Without much effort, this can be tailored to  
offer specific information regarding the identities used in phish that  
might otherwise qualify for annotations.  A dynamic reputation system  
by domain would be much more perilous, since just one astray server  
can affect all messages for all domains it might handle.  :^(

>> By including the IP address of the SMTP client, a reputation check  
>> of the SMTP client allows its Sender-ID "pass" results to be  
>> ignored when it fails to protect the PRA.
>
> ..which could be done at the border MTA, as it has the IP address of  
> the SMTP client.

While a reputation check might be done at the border, this would  
represent the efforts of a separate entity that makes no claim about  
checking reputations, nor does the draft require this check before  
adding the Authentication-Results header.  Only the application  
annotating the message is expected to making the check.  This  
represents a very dangerous loophole.

> Why do you insist that there is a need to repeat at the MUA work  
> that's already been done at the border MTAs (where experience  
> suggests it belongs)?

Either the Authentication-Results header captures the IP address of  
the SMTP client, and permits annotation applications a means to make  
their own annotation reputation check, or the Authentication-Results  
header should capture essential reputation information prior to adding  
this header.  A reputation indicating the SMTP client does not  
restrict the use of PRA may not cause the rejection of a message.   
However, this reputation information can squelch annotations without  
much disruption.  Unfortunately, this information is not assured to  
have been checked or what needs to be checked passed on to the  
annotation application.  The draft was written to expect two separate  
entities to:

1) Accept messages at the border (likely based on some type of general  
abuse reputation), and apply methods like Sender-ID or SPF.

2) Check authenticated message origination results reputation, and  
then conditionally reveal these results.

Appendix D overstates origination results reputation query concerns.   
It also assumes this check will cause message rejection, rather than  
affect the application of annotations as intended.  Acceptance rates  
at border MTAs should preclude overtaxing reputation services related  
to multiple recipients within the same domain.  Limitations imposed by  
corporate firewalls are normally resolved appropriately (caching and  
the like) by security related applications.

>> Why preclude an important option, and a necessary check as stated  
>> in section 4.1?  There has never been any reasonable justification  
>> for omitting the IP address of the SMTP client.  This IP address  
>> must be passed to the SPF record evaluation process!
>
> It's not precluded, it's explicitly required.  It's just not the way  
> you'd like it done.

When some SMTP client allows access that "spoofs" unrestricted PRAs,  
should annotations be inhibited for:

A) all domains handled by the SMTP client? (most disruptive.)

B) the domains currently spoofed (perhaps due to the misapplication of  
Sender-ID.) (drafts view?)

C) all domains handled by the SMTP client until the problem is  
corrected? (most effective and least disruptive.)

>> remain complaint with section 4.1 which states the reputation of  
>> the _authenticated_ origin of the message be checked first.
>
> You seem to be reading more into that language than exists.  Section  
> 4.1 says the reputation has to be checked, but makes no assertion  
> that it has to be checked at the MUA.  In fact, the draft contains a  
> substantial amount of guidance about the fact that such an  
> architecture is possibly even detrimental.

Applications applying annotations must make the reputation check.  The  
remedy being sought is to mitigate detrimental effects caused by the  
omission of the origination of the message essential for the check.

> Moreover, the "issues" rebuttal draft you posted contradicts  
> itself.  For example, your section 1 claims: "While there are cases  
> where a domain is controlled by a bad actor, often use of the bad  
> domain is brief."  This is an argument against your own proposed  
> remedy.

While reputations for a domain that offers SPF authorizations can be  
acquired, these are not authenticated identifiers.   Negative  
reputations against unauthenticated use of a domain can prove  
extremely disruptive.  Blocking a problem at its authenticated source  
provides the least disruption.  In addition, delays while attempting  
to gain confirmation of the domain's involvement is likely cause  
actions to be too slow to offer protection.  :^(

> The claim implies that timely evaluation of reputation, i.e. when  
> the message is in transit, is important. Users, however, might read  
> the delivered messages hours or even days later. It follows that the  
> active part of mail delivery (the MTAs), rather than the passive  
> part (the MUAs), is where such evaluations must be done.  Thus,  
> doing such evaluations when the MUA opens the message are not very  
> valuable.  Your remedy, therefore, contradicts one of your premises.

Reputation schemes can indicate a timeframe.  Not blocking at the  
domain also allows affected parties to inform recipients of recent  
security breaches.  Blocking at the domain will not allow security  
notifications from the affected domain. :^(

> Finally, I'm afraid your theories about the motivations of this  
> draft's proponents are rather contrived.

My apologies if you were offended, although I did not make any  
specific conjectures.  It was tempting to conjecture, like talking to  
one's self, when merits of a concern are not addressed.  I'll try to  
improve.

> Some of the issues you brought up regarding the draft, as well as  
> the results of the IESG review (which dealt with guidance language  
> rather than technological issues), were incorporated into its most  
> recent versions.
>
> You've been pushing this stuff, i.e. the remainder of your concerns,  
> for months now without any substantive support on any of the lists  
> to which you keep sending them, including during IETF Last Call  
> which ended more than a month ago.

Since that, the draft morphed when the draft attempted to address the  
expressed concerns.  For example, the conditional use of the local- 
part for SPF.  Unfortunately, the change is likely to have made the  
problem much worse. :^(

> Now, can we please, please move on?

Sorry for affecting the process, but this draft will create problems  
that can be avoided.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Jan 2009 11:45:36 -0800

> "SHOULD NOT" is not an recommendation to do something.

Someone marketing their services using email will read this as saying  
"Unless local-part macros are included within the SPF record,  
annotations will be limited. To be noticed, local-part macros are  
required."  An earlier draft published an example of a local-part  
exploits leveraging cached SPF records.  The exploit is able to  
sustain sizable attacks while utilizing little of the attackers  
resources, beyond the sending of email.  The more a DNS cache is  
inundated, the more effective the attack becomes.  :^(

> why you see that as recommending coercion.

Since the IP address of the SMTP client is omitted in the  
Authentication-Results header, domains must be assessed on a fairly  
static basis.  Using domains in the case of SPF or Sender-ID increases  
the number of assessments by more than an order of magnitude, that  
will also need to rely on the actions of many additional entities.   
The indirection of domain assessment significantly impairs effective  
responses to PRAs being exploited.  The exploit may have been enabled  
by compromised access, or imprudent record use by some inbound  
provider, neither directly be controlled by the domain.  As recipients  
fall prey, mounting damages will likely have a coercive effect.  Since  
assessment of the SMTP client is precluded by the Authentication- 
Results header, this eliminates practical, prompt, and comprehensive  
assessments, and places recipients at much greater risk.  The omission  
shields providers from being held accountable by pointing to some  
domain, rather than toward the likely source of a problem.  This  
indirection comes at the expense of recipient security.  Too bad  
security and authentication appears to have lost its meaning. :^(

-Doug