Subject: [ietf-dkim] New Issue: Threat-00 Limiting the scope of trust

From: Douglas Otis <[email-masked]>
Date: Wed, 1 Feb 2006 10:32:57 -0800

,---
| 1.  Introduction
| ...
| Once the attesting party or parties have been established, the
| recipient may evaluate the message in the context of additional
| information such as locally-maintained whitelists, shared reputation
| services, and/or third-party accreditation.  The description of these
| mechanisms is outside the scope of this effort.  By applying a
| signature, a good player enables a verifier to associate a positive
| reputation with the message, in hopes that it will receive
| preferential treatment by the recipient.
'---

As related to the goals established within the introduction, perhaps  
there could be a section on issues related to the establishment of  
trust based upon the DKIM signature.  This added section could deal  
with issues related to MUA keys, or a population of users within a  
domain where it is not practical to implement a level of vetting  
needed to retain trust (a positive reputation).  This issue of trust  
is important, as perhaps the only _safe_ indication that can be  
conveyed to the recipient would be whether the domain has a  
trustworthy reputation.

An indication that an email-address is within a signing-domain can be  
obtained by any bad actor.  Reliance upon a "within the signing- 
domain" indication necessitates perilous examinations of the email- 
address and knowledge of the domain name hierarchy.  Conversely,  
marking a message as "trustworthy" based upon the reputation of the  
signing-domain could not be obtained by any bad actor and does not  
require careful examination of the email-address.  There could be  
standards established for trustworthy lists where the signing domain  
must also have a CA Certificate suitable for commerce, for example.

A message being marked as Trustworthy should require two elements:

  - Good Reputation of the signing-domain's trustworthiness
  - Specific assertion by the signing-domain the message is trustworthy

This added signing-domain assertion could enable critical  
communications from key personnel within the domain to send messages  
marked as trustworthy to users within the domain.  However, untrusted  
users within the domain (perhaps using a free email account) could  
(and should) be excluded from having their messages marked as  
trustworthy.  This would shield these domains from the actions of  
poorly vetted users, while still retaining an ability to have  
critical messages receive a "trustworthy" marking.  Large  
institutions may also desire a means to segregate messages from  
contractors or temporary workers to further ensure their trustworthy  
reputation is protected.  Perhaps users with a delegated private key  
within their MUA would be excluded from receiving a trustworthy  
marking due to the prevalence of compromised systems.  The signing- 
domain assertion of trustworthiness could be a binary flag within the  
DKIM Key, for example.

It is not practical to attempt to compile reputations for an  
unlimited number of email-addresses or messages signatures.  However,  
by allowing the domains to exclude less trustworthy users,  
independent of the email-address, would allow a simple list of  
trustworthy domains to be maintained.  The same email-address may be  
trustworthy when signed by the MSA, but not when signed by the MUA,  
for example.

-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Feb 2006 07:11:22 +0100

> | preferential treatment by the recipient.

Thanks for pointing that out, it's wrong:  A player, good, bad,
or ugly, enables a verifier to associate any kind of reputation
with the message, not only positive.  DKIM will backfire and
hopefully educate some of the more ugly players.  I like that.

                          Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 2 Feb 2006 14:38:04 -0800

A follow on:

Suggested text for a trust section.  This section is rather long,
but several DKIM specific threat concerns were not previously
covered.

5.  Retaining Trust with DKIM Signatures

A required retention of trust by an email source protects email's
utility as an efficient form of communication.  Often "block-listing"
is a method of ostracism used for email sources that have been
identified as violating a trust.  Email sources being block-listed
often have not adhered to an "opt-in" criteria for the distribution
of bulk email.  With DKIM, the message envelope is excluded from the
message signature for compliance with the SMTP store-and-forward
delivery strategy.  Therefore, a DKIM signature precludes an
assessment of the number, the return-path, and the intended
recipients associated with the signing domain of a message.  Omission
of the message envelope therefore necessitates a different evaluation
paradigm than that of a typical "opt-in" criteria when assessing the
trustworthiness of the signing-domain.

The DKIM signature offers no assurances related to number of
messages, the intended recipients, or the return-path, which are
often criteria used to assess abusive email sources.  The assurance
provided by the verification of the DKIM signature is limited to the
domain of the initial email source and the encompassed message
content.  Regardless of the number of messages, and those sent to
recipients that never expressed a desire for their receipt, such
behavior can not be attributed to the signing domain.  The assurance
provided by the DKIM signature is strictly limited to the initial
domain and the nature of the message's content.  Messages of a
criminal nature, encompassing a deceptive header field, or offering
misleading links provides the limited basis for assessing a violation
of trust.

Evaluating a message's content compared to the message's initial
domain represents both a labor and computer intensive process.
Nevertheless, a DKIM signature should reduce the errors involved with
such an evaluation of individual messages.  Following a message
evaluation, any resulting assurances conveyed to the recipient should
preclude those messages from unknown signing domains which might be
controlled by a bad actor.  Rather than presuming a domain is
trustworthy until proven otherwise as with block-listing, a vetted
list of trusted signing domains should qualify assurances conveyed to
the recipient.  A reputation system will be unable to respond fast
enough to deter abuse of a "trusted" message status.

A safe indication conveyed to a recipient would be an assurance that
a message source is from a "trusted" signing domain.  An indication
that an email-address is within a signing domain can be accomplished
by any bad actor controlling a signing-domain.  Any email-address
related assurances would dangerously presume the recipient is capable
of a rather perilous examination of the email-address, and also that
the recipient has knowledge of the domain name hierarchy.  Retaining
trust demands extremely stringent control of all messages which may
receive an assurance of trust.  Even one signed message can be
replicated a billion-fold and sent rapidly anywhere by an army of
zombie computers.

Not all users sending messages from an email-address domain may be
trustworthy enough to meet the stringent requirements needed for
retaining trust.  There should be a method, perhaps with a flag
within the DKIM key, to indicate whether the signing domain itself
considers the source of the message to be trustworthy.  This trust
assertion mechanism would provide a means for a domain to retain
their trustworthy assessment, while still signing all messages.
Messages sent from trustworthy domains, but where the key is not also
marked trustworthy, should not convey an assurance of trust to the
recipient unless overridden by a local database maintained by the
recipient.

A signing domain may consider private keys within traveling
employee's laptop at too great of risk to allow the key to be
evaluated as trustworthy.  When the private key becomes stolen, until
discovered, and for as long as the TTL of the key allowed retention
within a cache, a bad actor could send deceptive messages creating
significant damages, especially when assurances of trustworthiness
are being relied upon.  In the case of the traveling employee while
away from the office, their messages would not be marked as
trustworthy.  However, the same employee and associated email-address
could be marked as trustworthy when sent from the office.

Providers offering low cost or free services will not be able to
adequately vet their many users, who often number in the millions.
This same provider may wish to send messages from the same domain and
have these messages receive a trustworthy evaluation.  Perhaps these
would be messages from a system administrator indicating that the
user's system appears compromised or that their payment information
is no longer valid.  The use of a trusted/non-trusted key would
permit the signing domain to both retain their trustworthy status and
other users within the same domain would be unable to spoof their own
customers with "trusted" messages.

In addition to the MDA marking messages as "trusted", the recipient's
MUA could also perform a similar function based upon a locally
maintained list of trustworthy sources.  This locally maintained list
could include additional information beyond just the domain name
itself to elevate the level of trust for specific email sources.
This additional information may relate to the account used to access
the signing domain and possibly the purported role of the signing
domain.  Sources for this locally maintained list would be confirmed
by some out-of-band method.  Without the purported role of the
signing domain noted within the signature, maintenance of a local
list would likely involve the nuisance of resolving apparent
conflicts when the same email-address appears from both MSAs and
mediators, such as list-servers.

Due to the cost related to evaluating a DKIM signing domain's
violation of trust, the use of "trusted" keys should be limited to
transactional messages having unique signatures sent to specific
recipients.  When message replay abuse becomes problematic, the
recipient involved could be excluded in the future from receiving
"trusted" messages as one possible preventative.  With the high cost
of evaluation and the inability to associate the message envelope
information with the signing domain, there should be no expectation
whatsoever that DKIM offers a means to abate common spam.  A white-
list of signing domains should not cause a bypassing of normal checks
for messages using keys not also marked as "trusted".

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 03 Feb 2006 04:05:07 +0100

Douglas Otis wrote:

> Often "block-listing" is a method of ostracism used for
> email sources that have been identified as violating a
> trust.

s/a method of ostracism//

> Email sources being block-listed often have not adhered
> to an "opt-in" criteria for the distribution of bulk email.

There are many reasons for black-listing, irrelevant for DKIM.

> Therefore, a DKIM signature precludes an assessment of the
> number, the return-path, and the intended recipients
> associated with the signing domain of a message.

DKIM does not preclude an assessment of the envelope and/or
sending IP with other means.

> Omission of the message envelope therefore necessitates a
> different evaluation paradigm than that of a typical
> "opt-in" criteria when assessing the trustworthiness of
> the signing-domain.

That's not the case.

> messages, the intended recipients, or the return-path, which
> are often criteria used to assess abusive email sources.

That will be dealt with before the DATA by other methods.

> Regardless of the number of messages, and those sent to
> recipients that never expressed a desire for their receipt,
> such behavior can not be attributed to the signing domain.

Of course it can.  Originating or forwarding spam, anything
goes, add signature, and be damned as spammer.  That's the
whole purpose of this exercise.

> The assurance provided by the DKIM signature is strictly
> limited to the initial domain and the nature of the
> message's content.

The assurance is "I sent this mail to you, don't bother to
study timestamp lines, here's my signature, block me if I'm
a spammer".

> Messages of a criminal nature, encompassing a deceptive
> header field, or offering misleading links provides the
> limited basis for assessing a violation of trust.

That isn't the case, a signing entity cannot determine the
"criminal nature" of a message, it's a script, not a lawyer.
It also can't identify deceptive header fields, let alone
study URLs in the body.

> a DKIM signature should reduce the errors involved with such
> an evaluation of individual messages.

Sure, black hat signed it ?  Score -100.  Working as designed.

> Following a message evaluation, any resulting assurances
> conveyed to the recipient should preclude those messages
> from unknown signing domains which might be controlled by a
> bad actor.

ACK, anything STRONG without valid original DKIM signature was
already rejected at this point.

> a vetted list of trusted signing domains should qualify
> assurances conveyed to the recipient.

s/trusted//  Nothing's wrong with a vetted list of white, grey,
and black hats.  

> A reputation system will be unable to respond fast enough
> to deter abuse of a "trusted" message status.

Not necessarily.

> A safe indication conveyed to a recipient would be an
> assurance that a message source is from a "trusted"
> signing domain.

Or from a known grey / black hat.  DKIM is about valid or
invalid signatures, not about promoting dubious bulk mailers.

> Even one signed message can be replicated a billion-fold
> and sent rapidly anywhere by an army of zombie computers.

No problem to say something like that, but not more than once.

> There should be a method, perhaps with a flag within the
> DKIM key, to indicate whether the signing domain itself
> considers the source of the message to be trustworthy.

The D in DKIM doesn't stand for "Do what I mean", they'll get
an average reputation for mails signed by them.  If they don't
like this let them create signing subdomains.

> employee's laptop at too great of risk to allow the key to
> be evaluated as trustworthy.

The MSA signs, not the laptop.

> In the case of the traveling employee while away from the
> office, their messages would not be marked as trustworthy.

That's mostly unrelated to DKIM, implementation details of
the MSA.  If it's paranoid let it use different subdomains
in its signatures.
                           Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Feb 2006 21:34:12 -0800

> sending IP with other means.

Of course other identifiers can be assessed.  This statement however
indicates assessments associated with the signing domain can not include
elements of the message envelope.

> > "opt-in" criteria when assessing the trustworthiness of

A verified signature is independent of the message envelope parameters.
Unless the signing-domain is assessed separately, a bad actor could
easily ruin the reputation of a signing domain.  This can not be
permitted!

> That will be dealt with before the DATA by other methods.

Yes, but these other methods should not affect the reputation of the
signing domain.

> whole purpose of this exercise.

The exercise should ensure a signing domain can retain their trustworthy
status despite the mischief of bad actors.  A signing domain can not be
damned based upon a message envelope taking it where it does not belong.
That would allow a bad actor a simple means to destroy reputations for
signing domains.  Tilt- Game Over.

> study timestamp lines, here's my signature, block me if I'm

A signature indicates the message originated from within the signing
domain.  A signed message may _not_ indicate for whom the message was
intended.  Especially in those cases where the RCPT TO is not discovered
in the message, the signing domain MUST NOT be held accountable for a
problematic instance of a message. 

> It also can't identify deceptive header fields, let alone

Exactly.  The signing domain marking a message as trustworthy is
assuring the recipient the message is not deceptive in _some_ fashion.
This assurance would not be based upon some script or email-address, but
upon who is allowed to receive their endorsement.  Violate the trust,
lose the endorsement.  Let it happen too often, the signing domain will
also lose their trustworthy status.

> Sure, black hat signed it ?  Score -100.  Working as designed.

It is unlikely there will be methods that safely ensure bad actors can
be block-listed.  In the cases where they can be, it is likely they're
already one step ahead.  DKIM will likely need to start by using a list
of known good actors.  Perhaps listing domain with a server certificate
from trusted CAs could be a starting point.  Violate the trust, and then
be removed from the list.  With such an initial requirement, there will
be individuals that can be held accountable. 

> already rejected at this point.

This conveyance of assurances should exclude even for those email-
addresses within the signing domain (where policies would not be
checked) but the trustworthiness of the domain is unknown.

> s/trusted//  Nothing's wrong with a vetted list of white, grey,

Why convey an indication of trustworthiness for messages from bad
actors?  Unless the domain is known, it should not be assumed to be
trustworthy.

> > to deter abuse of a "trusted" message status.

As you have already indicated, there is no simple system for assessing a
violation of trust based upon DKIM signed messages.  Many phishing
attacks start and finish within hours, and there are thousands of domain
names that can be used for this activity.

Marking bigbank.com as trusted will allow recipients an easy means to
spot bad actors using biqbank.com or accounts-bigbank.com that should
never obtain the trusted marking.  Once the message can be marked
trusted, then perhaps also indicate whether the email-address is within
the signing domain.

> invalid signatures, not about promoting dubious bulk mailers.

Bad actors will not have any difficulty creating perfectly signed
messages.  Using trusted domain lists is definitely less expensive than
expecting each domain to acquire all possible look-alikes.
Unfortunately, the industry has already been rather misleading about the
use of modified domain names.  :-(

> No problem to say something like that, but not more than once.

This was to illustrate how critical it is to ensure only trusted sources
have access to keys carrying a trusted status.

> like this let them create signing subdomains.

If reputations were based upon numbers as determined by messages
directly obtained from the MTA, then talking about averages may make
sense.  When one considers the army-in-the-middle situation, a 1%
problem replayed can become 1000%. 

> The MSA signs, not the laptop.

The MSA or perhaps the MUA, from my understanding, can sign messages.

> the MSA.  If it's paranoid let it use different subdomains

Use of sub-domains would tend to create less trust and not more.
Changing the appearance of the domain name will not be understood by
many people, and may cause them to be more easily mislead by hyphenated
names rather than period separated.  It is also likely that few domains
can fully trust all users with access to their outbound servers.  Again,
just one signed message is all that is needed for a fair amount of
havoc.  Otherwise, without constraining this exposure, reputations
services will have trouble keeping up. By marking keys trusted, this
will allow the signing domain a means to limit the extent of their
exposure, and to reserve a trusted status for where it is most needed.

DKIM and vetted domains can prevent phishing exploits.  That should be
enough.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Feb 2006 09:52:39 +0000

Doug,

Thanks for taking the time to make a concrete proposal.
However:

a) I would be very surprised if that text gained
consensus due to its serious lack of clarity (sorry to
be critical, but there it is),

b) there doesn't seem to be anything new there,
but its hard to know given (a).

Regards,
Stephen.

---

From: <[email-masked]>
Date: Fri, 3 Feb 2006 09:17:52 -0500

Doug Stated
**************
DKIM does not sign the message as "trustworthy" DKIM just indicates "I sent this" 
thanks,
Bill Oxley

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 03 Feb 2006 15:48:10 +0100

Douglas Otis wrote:

> Of course other identifiers can be assessed.  This statement
> however indicates assessments associated with the signing
> domain can not include elements of the message envelope.

Okay, but it's IMO unnecessary to talk about it in Jim's draft.
He has it already in 1.2:

| The transmission of messages via SMTP, defined in RFC 2821,
| and such elements as the envelope-from and envelope-to
| addresses and the HELO domain are not relevant to DKIM
| verification.  This is an intentional decision made to allow
[...]

End of story as far as I'm concerned, no need to reiterate it.

> A verified signature is independent of the message envelope
> parameters. Unless the signing-domain is assessed separately,
> a bad actor could easily ruin the reputation of a signing
> domain.  This can not be permitted!

Of course it's "permitted", receivers and future reputation
services are free to do whatever they like including stupid
things.  We can't enumerate all potentially bad ideas, it's
hard enough to catch some necessarily bad ideas.

> The exercise should ensure a signing domain can retain their
> trustworthy status despite the mischief of bad actors.

If it's your intention to get another "I'm no spammer" scheme
without chance that it could be used for the opposite effect
it won't fly.  Something signed by a big ISP will never have
the same reputation as something signed by a bank.

And Jim's draft can't be a "how to" for reputation services,
officially that's off topic, declared to be out of scope in
the WG charter.  Better stop it before it gets out of hand,
or we're trapped in (un)foreseen ratholes.

> That would allow a bad actor a simple means to destroy
> reputations for signing domains.  Tilt- Game Over.

There's a chapter about "replay attacks", all we can do is
warn receivers / reputation services to get ready for this.

And another chapter about zombies "within" an organization:
If those zombies destroy the reputation of a signing domain
that's precisely what we want:  Either they get rid of the
zombies, or they get the deserved reputation.

> the signing domain MUST NOT be held accountable for a

Signing domains are accountable for allowing the transmission
of a message, and the only interesting case are "problematic"
messages, otherwise nobody cares.  There is no 2119 MUST NOT,
receivers will say "stop this enlargement spam or else".  Or
phishing / mailbombing / etc.

> The signing domain marking a message as trustworthy is

Where "some" is either undefined or essentially the same as
"I was stupid enough to transmit this mail, sorry if it's
 not exactly what you want".

> Violate the trust, lose the endorsement.  Let it happen too
> often, the signing domain will also lose their trustworthy
> status.

Yes.  I'd hope that a "reputation service" offers more than
black and white, but also several kinds of grey in between.

> Why convey an indication of trustworthiness for messages
> from bad actors?  Unless the domain is known, it should not
> be assumed to be trustworthy.

Domains like spamcast are known.  For ISPs with 1,000,000 or
more customers it's only natural that one (?) of them tries
to start a new career as baby-spammer, daily.  Not counting
the zombies, discussed in another chapter of Jim's draft.

 
> As you have already indicated, there is no simple system for
> assessing a violation of trust based upon DKIM signed
> messages.  Many phishing attacks start and finish within
> hours, and there are thousands of domain names that can be
> used for this activity.

When I wrote "not necessarily" what I had in mind was Ironport
with their combination of Senderbase and SpamCop.

> The MSA or perhaps the MUA, from my understanding, can sign

Okay, the latter is new for me, but let's say it's possible.
Then I fail to see why a mobile MUA should be necessarily
more dangerous than other MUAs.  Anything with a Win-logo on
it is threatened, whereever it is.  All they need is a say
Sony CD and "oops, did it again".

> few domains can fully trust all users with access to their
> outbound servers.

Then let them partition their users in signing subdomains,
or let them use different subdomains for groups of similar
AUTH methods.  It's their problem.  If you want the aspect
of different classes of users / AUTH methods as new chapter
it's okay, but I'm not yet convinced by your "flag" idea.

                           Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 3 Feb 2006 10:54:00 -0800

On Feb 3, 2006, at 1:52 AM, Stephen Farrell wrote:
>
> a) I would be very surprised if that text gained consensus due to  
> its serious lack of clarity (sorry to be critical, but there it is),

This was an attempt to consider how DKIM can be reasonably employed,  
which should have started from an outline perhaps.

This was a strategy based upon these premises:

A) Recipients can not dependably recognize email-addresses

B) 'o=!' policy offers limited protection

C) Trusted domain lists are
   a) safer
   b) less expensive

D) Mail-filters, MDAs, or MUAs may mark messages for greater safety

E) Trust assessments of signing-domains
   a) must be based upon encompassed content
   b) must ignore envelopes
   c) is independent of signature count
   d) is very resource intensive and expensive

F) DKIM may not offer an assured email-address

G) Reputation assessments of email-addresses are not practical

H) Not all internal sources are trustworthy

I) Signing-domains should indicate internal trustworthy sources

J) Internally trusted sources from trusted signing-domains
   a) limit the scope of white-listed acceptance
   b) limit the conveyance of recipient "trusted" markings

K) Email-address sub-domain segregation is
    a) disruptive
    b) confusing

L) DKIM prevents the spoofing of sources

M) DKIM as a means to abate spam is perilous

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Feb 2006 19:36:45 +0000

Doug,

Douglas Otis wrote:
>> a) I would be very surprised if that text gained consensus due to its 
>> serious lack of clarity (sorry to be critical, but there it is),
> 

We're working on the threat analysis document. If you have a proposal
for text to include that's a good thing to do (as you did) and then
that proposal might be supported or not. But I've no idea what that
list you just sent is supposed to represent.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 3 Feb 2006 12:56:37 -0800

On Feb 3, 2006, at 6:48 AM, Frank Ellermann wrote:

>> however indicates assessments associated with the signing domain  
>> can not include elements of the message envelope.
>

While this clarifies the verification process, this does not stress  
the importance of assessing the signed portion of the message  
separately.

>> parameters. Unless the signing-domain is assessed separately, a  
>> bad actor could easily ruin the reputation of a signing domain.   
>> This can not be permitted!
>
> things.  We can't enumerate all potentially bad ideas, it's hard  
> enough to catch some necessarily bad ideas.

The draft should be able to say what is considered permissible.  Many  
that will attempt to use DKIM to abate spam, which is like using  
tweezers to remove a bolt.  It won't work and will break the tool.   
Misapplying assessments enables mischief by bad actors damaging the  
trustworthiness of otherwise innocent signing-domains.

> without chance that it could be used for the opposite effect it  
> won't fly.  Something signed by a big ISP will never have the same  
> reputation as something signed by a bank.

This is not about self declarations of "I'm no spammer".  This would  
be looking for the union of a list of "trusted signing-domains" held  
by the recipient, with a list of "trusted sources" held by the  
signing-domain.  This union can safely enable acceptance criteria or  
message markings.  Without this mechanism, DKIM would not be as safe.

Unless there is a method for the ISP to constrain what is considered  
trustworthy, it would be impossible for the domain to establish any  
trust whatsoever.  Even a bank would be prudent to consider their  
exposures with respect to who has access to their outbound servers.   
The trusted key concept limits their exposure without increasing the  
number of email-address domains being used.

> officially that's off topic, declared to be out of scope in the WG  
> charter.  Better stop it before it gets out of hand, or we're  
> trapped in (un)foreseen ratholes.

This is not about how a trust violation is determined or reported,  
which I agree represents concerns for a different WG.   This is  
specific to a DKIM signed message regarding the scope of the message  
that can be safely assessed.  This also considers a need to further  
limit the scope of trust for sources within the signing-domain, as  
many domains contain users that can not be adequately vetted.  The  
introduction of the Threat document also clarifies that these  
assessments to be made.  It seems appropriate to consider the scope  
of the assessment as it pertains to DKIM, how this assessment  
provides threat avoidance, and the threats related to the assessments  
where the scope is misapplied.

>> That would allow a bad actor a simple means to destroy reputations  
>> for signing domains.
>
> There's a chapter about "replay attacks", all we can do is warn  
> receivers / reputation services to get ready for this.

DKIM could also provide an essential/simple tool for limiting the  
exposure to this looming problem.

> If those zombies destroy the reputation of a signing domain that's  
> precisely what we want:  Either they get rid of the zombies, or  
> they get the deserved reputation.

While I agree with the motivation, there needs to be a strategy for  
tackling the problem as it currently exists.  Zombies can destroy the  
trust of even innocent signing-domains when "opt-in" criteria is used  
as an assessment basis.  Prohibiting this assessment basis however  
means using DKIM to control acceptance will be painful.  A convention  
for permitting the tracking of sources offered by DKIM, combined and  
reporting and revocation may slowly beat down the problem.  For  
effective reporting, the signing-domain, and not the email-address  
policy, needs to offer the reporting vector.  This is going to be a  
long slog.

>> the signing domain MUST NOT be held accountable for a problematic  
>> instance of a message.
>
> Signing domains are accountable for allowing the transmission of a  
> message, and the only interesting case are "problematic" messages,  
> otherwise nobody cares.  There is no 2119 MUST NOT, receivers will  
> say "stop this enlargement spam or else".  Or phishing /  
> mailbombing / etc.

As it is now, many receivers want to identify problematic domain's IP  
addresses to _white-list_ them.  This is because a percentage of many  
large ISP's traffic is reported on various block-lists.  Using DKIM  
in this manner would be foolish.  Many may be disappointed who expect  
DKIM to offer a solution for this problem. :-(

>> The signing domain marking a message as trustworthy is assuring  
>> the recipient the message is not deceptive in _some_ fashion.
>
> Where "some" is either undefined or essentially the same as "I was  
> stupid enough to transmit this mail, sorry if it's not exactly what  
> you want".

As far as an assessment is concerned, the "you" can not be assumed to  
apply to the signing-domain.  If the domain signed the message and  
marked it as coming from a trusted source, but a link within the  
message was bait for a man-in-the-middle attack, then the signing- 
domain has violated a trust.  A message sent to the wrong recipient  
_must not_ be considered a problem for the signing-domain.

>> Violate the trust, lose the endorsement.  Let it happen too often,  
>> the signing domain will also lose their trustworthy status.
>
> Yes.  I'd hope that a "reputation service" offers more than black  
> and white, but also several kinds of grey in between.

Perhaps, but ratings would be beyond the scope of what is relevant  
for DKIM.  An assessment could be reasonably applied only after  
suffering a fair amount of expense.  This is not something to be used  
to assess each and every message from an ISP. :-(

>> actors?  Unless the domain is known, it should not be assumed to  
>> be trustworthy.
>
> Domains like spamcast are known.  For ISPs with 1,000,000 or more  
> customers it's only natural that one (?) of them tries to start a  
> new career as baby-spammer, daily.  Not counting the zombies,  
> discussed in another chapter of Jim's draft.

Exactly.  But the administrator within that domain should be  
trustworthy and should be able to have their messages acknowledged as  
trustworthy.  This will be important when customers start seeing  
messages from their provider indicating they have problems and need  
to take action X.

> When I wrote "not necessarily" what I had in mind was Ironport with  
> their combination of Senderbase and SpamCop.

This was about starting with a vetted list of trusted domains, valid  
for this example.

> Okay, the latter is new for me, but let's say it's possible. Then I  
> fail to see why a mobile MUA should be necessarily more dangerous  
> than other MUAs.  Anything with a Win-logo on it is threatened,  
> whereever it is.  All they need is a say Sony CD and "oops, did it  
> again".

When the mobile MUA carries a copy of the private key to allow signed  
messages when there is no access to the home office, this would  
represent a key that would be less trustworthy due to its exposure.   
Perhaps they travel to foreign countries or hotels with crazy firewalls.

> Then let them partition their users in signing subdomains, or let  
> them use different subdomains for groups of similar AUTH methods.   
> It's their problem.  If you want the aspect of different classes of  
> users / AUTH methods as new chapter it's okay, but I'm not yet  
> convinced by your "flag" idea.

The use of the trusted/non-trusted keys provides a transparent method  
of introducing security via DKIM.  Your solution will not be  
transparent, will disrupt the normal email-addresses in current use,  
and will create greater confusion further endangering the recipient,  
who DKIM is attempting to protect.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Feb 2006 22:43:48 -0800

Based upon the feedback offered by Frank, this section has been  
revised to offer more concise statements related to threats.  As  
Frank and Jim have pointed out, other concurrent strategies may be  
needed to defend DKIM when used as a basis for acceptance.  This  
review focused upon the scope of the message used to assess bad acts,  
and explored risks related to those aspects of the message not  
protected by the DKIM signature.  This reviews defensive strategies  
using message envelope and DKIM based information.
----

5. Signing Domains Retaining Trust

The required retention of trust by an identified email source  
protects email's utility as an efficient form of communication. The  
signing domain offers a verified identifier that can be used to  
accrue a history of behavior, as mentioned in the introduction. A  
DKIM signature excludes the message envelope, and thus precludes an  
equitable assessment of the signing domain based upon the number of  
messages, return-path, or recipients. Bad acts verifiably associated  
with the signing domain are therefore limited to the message content,  
such as encompassed deceptive header fields, malware, or dangerously  
misleading information or links.

5.1 Verifiable Assessments are Resource Intensive

Assessing message content is extremely resource intensive, when  
compared to the typical “opt-in” criteria often used to establish  
most block-lists. Assessing verifiable actions of the signing domain  
might be slow and involve human interaction across hundreds of  
languages. Such absorbent efforts in assessing the actions of signing- 
domains may cause some recipients to instead hold the signing domain  
liable for bad acts determined by the unsigned message envelope. This  
highly probable expediency increases the signing-domain's exposure to  
reputation attacks, as even stringent control of message content will  
not offer protection.

5.2 Increased Threats Due to Expedient Assessments

Bad acts related to the message envelope represents a potential  
threat when the signing-domain is held liable for these acts. Path  
registration may play a role in defending against this threat. When  
based upon the return-path, there is no overlapping information to  
offer protection for a DKIM message. An alternative to the return- 
path is the Purported Responsible Address (PRA), a licensed algorithm  
with terms some find unsatisfactory. For the signing domain to retain  
source control using PRA path registration, the mediator provisions  
of PRA modified [RFC2822] Resent-* header fields, as well as Sender  
header fields, must be blocked by DKIM listing non-existent headers  
as part of the signature.

PRA path registration with the mediator provisions blocked might  
prevent a bad actor from staging a replay attack, but then email that  
would normally pass through a PRA compliant mediator would be blocked  
as well. Not blocking the PRA mediator provisions however allows a  
bad actor to replay signed messages from a domain they control, and  
still leaves the signing domain exposed to possible message envelope  
liabilities.

An alternative to PRA path registration with header blocking,  
validating the same portion of the DKIM message path, would be a  
forward referenced DNS PTR list of HELO domains. The maximal 112 DNS  
lookups that might be needed to compile a PRA path also introduces  
significant susceptibility to various attacks. Fortunately, HELO  
verification needs only one lookup. When the HELO is within the  
signing domain, even the lookup of a HELO list in the signing domain  
is skipped.

5.2.1 Delayed Lookup and Transient Negative Completion

A possible strategy that can be used when a path is not validated,  
would be to delay the lookup of a block-list based upon message  
envelope identifiers, or a revocation record published by the signing  
domain. This delay would be done in conjunction with "Requested  
action aborted: error in processing" SMTP response, See [RFC2821],  
and Section 4.1.4 Paragraph 5. Although message envelope assessments  
can be made rapidly, distributing these assessments still requires  
time. A delay in acceptance would allow time for an abusive replay to  
be discovered and the message envelope identifiers block-listed or a  
revocation record published.

A receiving domain may eliminate the delayed acceptance once the  
source is proven trustworthy. This strategy would provide protection  
from threats related to abusive message replay, and yet still allow  
messages to transverse mediators. Using revocation records rather  
than block-listing message envelope identifiers assures the signing  
domain greater control of this protection. Distributing revocation  
information also offers greater overall reliability and robustness  
from attack.

5.3 Threats Related to Assessment Delays

Owing to the extensive resources and time needed to properly evaluate  
DKIM related bad acts, any resulting assurances conveyed to the  
recipient should preclude those messages from unknown signing domains  
which might be controlled by a bad actor. Rather than presuming a  
domain is trustworthy until proven otherwise as with block-listing, a  
vetted list of trusted signing domains should qualify assurances  
conveyed to the recipient. A reputation system may be unable to  
respond fast enough to deter the abuse of message related assurances.

A safe indication conveyed to a recipient would be an assurance that  
a message source is from a "trusted" signing domain. An indication  
that an email-address happens to be within a signing domain can be  
accomplished by any bad actor controlling a signing-domain. Any email- 
address related assurances would dangerously presume the recipient is  
capable of a rather perilous examination of the email-address, and  
also that the recipient has knowledge of the domain name hierarchy.

5.4 Trustworthy Assertions
5.4.1 Risks of Confusion Using Sub-domains

Not all users or sources sending messages within an email-address  
domain may be trustworthy enough to meet stringent requirements  
needed for retaining trust. There is also often a desire to retain  
current email-address assignments and also claim all messages from a  
domain are signed. Without a means to group the trustworthiness of  
various email sources within a domain, the overall trustworthiness of  
the domain is significantly diminished. There should be a method,  
perhaps with a tag within the DKIM key, to indicate whether the  
signing domain itself considers the source of the message  
trustworthy. This trust assertion mechanism could provide a means for  
a domain to retain their trustworthy assessment, while still signing  
all messages. Messages sent from trustworthy domains, but where the  
key is not also marked trustworthy, should not convey assurances to  
the recipient unless overridden by a local database maintained by the  
recipient.

Providers offering low cost or free services will not be able to  
adequately vet their many users, who often number in the millions.  
This same provider may wish to send messages from the same domain and  
have these messages receive a trustworthy evaluation. Perhaps these  
would be messages from a system administrator indicating that the  
user's system appears compromised or that their payment information  
is no longer valid. The use of trusted/non-trusted keys would permit  
the signing domain to both retain their trustworthy status and  
prevent un-vetted users within the same domain from spoofing with  
"trusted" messages.

5.4.2 Preventing Spoofs from Untrusted Sources

In addition to the MDA marking messages as "trusted" based upon the  
history of a domain's behavior and the status of the key, the  
recipient's MUA could also perform a similar function using a locally  
maintained list of trustworthy sources. The locally maintained list  
could include additional information beyond just the domain name  
itself to elevate the level of trust for specific email sources, even  
when not indicated as trustworthy by the signing domain. This  
additional information might relate to the account used to access the  
signing domain and possibly the purported role of the signing domain.  
Out-of-band source confirmation would be needed for a locally  
maintained list. Without a purported role of the signing-domain being  
noted, maintenance of a local list would become a nuisance resolving  
conflicts when the same email-address appears from both MSAs and  
mediators.

5.5 The Risk of Overwhelming the Assessment Process

Due to the cost related to evaluating a DKIM signing domain's  
violation of trust, the use of "trusted" keys should be limited to  
transactional messages, ideally having unique signatures sent to  
specific recipients. With the high cost of evaluation and the  
inability to verify the association of the message envelope  
information with the signing domain, there should be no expectation  
whatsoever that DKIM offers a means to abate common spam, or that  
assessments can be based upon an unlimited number of email-addresses  
and signatures. A white-list of signing domains should not cause the  
bypassing of normal checks for messages using keys not also marked as  
"trusted".

-Doug

_______________________________________________
NOTE WELL: This list operates according to &lt;http://dkim.org/ietf-list-rules.html&gt;

---

From: Jim Fenton <[email-masked]>
Date: Sat, 11 Feb 2006 23:09:01 -0800

Doug,

I have done my best to try to understand what you are getting at here,
with limited success.  One main comment though:

The threat document is an analysis of DKIM, not systems that encompass
DKIM in concert with other mechanisms such as SenderID, SPF, and CSA.

If there is anyone else on the list who feels that this should be looked
at more closely, please speak up.  Otherwise, I will assume that there
is a lack of consensus on this change (although I will leave it to the
WG chairs to formally make that determination).

-Jim

Douglas Otis wrote:
> revised to offer more concise statements related to threats.  As Frank
> and Jim have pointed out, other concurrent strategies may be needed to
> defend DKIM when used as a basis for acceptance.  This review focused
> upon the scope of the message used to assess bad acts, and explored
> risks related to those aspects of the message not protected by the
> DKIM signature.  This reviews defensive strategies using message
> envelope and DKIM based information.

_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Feb 2006 09:59:36 -0800

> DKIM in concert with other mechanisms such as SenderID, SPF, and CSA.

This was a concern raised regarding the impact of message replay abuse,
which is definitely part of the threat draft.  _You_ have suggested in
the past, the message replay abuse problem could be resolved with
SenderID when used in conjunction with DKIM.

Verification of the HELO can happen in many ways.  There was not any
mention of how this would be done. 

> WG chairs to formally make that determination).

The introduction of the threat draft established an expectation of DKIM
used as a basis for acceptance. There should be a section that focuses
upon threats related to that specific use.  At the least, there should
be an attempt to explain how message replay abuse will not affect the
acceptability of the sign-domain, the basis for your Low impact rating.

There are three basic issues raised, where some solutions were suggested
to resolve these issues.  Why should major issues should be left
unresolved, if only in theory?  This is not the protocol draft.

 -Assessing the signing-domain using only signed message content is
  difficult, and will likely include the unsigned message envelope.

 -The message path as described by SenderID (when mediators are
  blocked), or a list of HELOs could offer a means to bypass a defensive
  strategy that delays acceptance to avoid an abusive message replay
  threat.

 -A desire to sign all messages will likely include unvetted sources,
  and a proper signing-domain assessment (not prone to corruption) will
  require time.

For statements that are not understood, a specific question usually
helps.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Feb 2006 01:04:21 +0100

Douglas Otis wrote:

> _You_ have suggested in the past, the message replay abuse
> problem could be resolved with SenderID when used in
> conjunction with DKIM.

Did he ?  Somehow I missed that.  DKIM security based on PRA
would be a quite interesting point, to put it mildly.  It's
possible if we're up to "fixing" (modifying) 2476bis 8.1 and
2822, some "minor" details like re-charter DKIM left out. ;-)

> At the least, there should be an attempt to explain how
> message replay abuse will not affect the acceptability of
> the sign-domain, the basis for your Low impact rating.

Is that the basis of 4.1.4 ?

> Why should major issues should be left unresolved, if only
> in theory?  This is not the protocol draft.

Sorry, a statement like "don't even think about DKIM without
PRA" sounds like a death sentence for me.  For starters the
PRA is not necessarily (one of) the 2822-From address(es).

> The message path as described by SenderID

JFTR, SenderID merely offers a normative reference to SPF for
this purpose.  It contains no separate "description" of these
SPF-details except from "use spf2.0/TBD instead of v=spf1" and
the theoretical concept of "positional modifiers" (in practice
not one positional modifier exists so far).

Four letters of one wannabe-backwards-compatible "spf2.0/TBD"
are the subject of an IAB appeal.  It makes no sense to base
DKIM security on PRA, neither technically nor procedurally.

> (when mediators are blocked)

When they're blocked the replay attack wouldn't work, so that
is no problem with the idea to use PRA as a defense for DKIM.

                            Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Feb 2006 17:42:04 -0800

On Mon, 2006-02-13 at 01:04 +0100, Frank Ellermann wrote:
> Douglas Otis wrote:
>
> DKIM security based on PRA would be a quite interesting point, to put
> it mildly.  It's possible if we're up to "fixing" (modifying) 2476bis
> 8.1 and 2822, some "minor" details like re-charter DKIM left out. ;-)

This was an attempt to understand what strategy was being considered to
arrive at the conclusions indicated in 4.1.4 and 4.1.5.  It should not
require a rechartering to suggest a defense that may utilize other
mechanisms beyond that of DKIM.  This was an attempt to review the
details that lead to the Low impact conclusion.

Block-listing email-addresses or signatures requiring a vastly larger
database seems unlikely, when the signing-domain is the predominate
identifier within all types of message replay abuse.  Assuming that the
signature is being used as a basis of acceptance, the likely block-
listing of the signing-domain would create a High impact.

> PRA is not necessarily (one of) the 2822-From address(es).

Jim had mentioned Sender-ID for this purpose, where the speculation was
to better understand his reasoning.  Even this brief review was not
limited to just Sender-ID as a path solution, but also included a list
of HELOs that could describe the same path in one or two lookups.
Forwarding or List-servers would not function with this type of strategy
however. 

This loss of normal functioning would be a significant trade-off, where
the use of delayed acceptance was offered as a possible means to
mitigate the inability for a path approach to otherwise deal with
mediators.

> DKIM security on PRA, neither technically nor procedurally.

While sharing many of the same concerns, the review was an attempt to
understand what Jim was considering, not to endorse any mechanism.

> is no problem with the idea to use PRA as a defense for DKIM.

Correct. Blocking PRA mediators could prevent replay concerns, but at
the loss of the functionality of mediators.  Delayed acceptance was
suggested as a means to bridge over this problem.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Feb 2006 06:03:41 +0100

Douglas Otis wrote:

> It should not require a rechartering to suggest a defense
> that may utilize other mechanisms beyond that of DKIM.

If that "other mechanism" is SPF we're in the muddy waters of
"downref".  DKIM wants to be PS.  SPF is only "experimental".

If that "other mechanism" is PRA it's even worse, state of the
art is that it can't advance on standards track as is, compare
<http://www.ietf.org/IESG/APPEALS/appeal-response-william-leibzon.txt>

| It would be inappropriate to advance Sender-ID on the 
| standards track without resolving this interoperability 
| problem.

To resolve this problem we'd have to modify 2476bis and 2822.
The former is simple, but removing a MUST from 2822 is tricky.
BTW, I'd support the latter.

> Assuming that the signature is being used as a basis of
> acceptance, the likely block-listing of the signing-domain
> would create a High impact.

At the moment threats-00 has LOW impact with M/H likelihood for
4.1.4, and LOW impact with HIGH likelihood for 4.1.5.  For the
likelihood that's okay:  4.1.4 is more difficult for the bad
actors.  And for 4.1.5 the impact might be lower than 4.1.4,
probably depending on the 4.1.5-message.

Any HIGH / HIGH is a showstopper, we can't have a HIGH / HIGH
without clear recipe to prevent it.  And "just use PRA" is not
convincing.  If PRA would work in practice we don't need DKIM.

> Jim had mentioned Sender-ID for this purpose

But PRA is often different from the 2822-From, it's unrelated
to signing domains.  Maybe it helps with a propoer subset of
STRONG signing policies.  Similar reasoning for SPF.  In both
cases mainly "closed" (either PASS or FAIL) policies.  NEUTRAL
for "the rest of the world" (as in ?all) can't be good enough.

> Even this brief review was not limited to just Sender-ID as a
> path solution, but also included a list of HELOs that could
> describe the same path in one or two lookups.

Okay, covering "signing domains" by sets of related HELOs makes
more sense than PRA or MAIL FROM.  We've nothing for arbitrary
HELO id.s.  At best we have CSV's zone-cut emulation.  But CSV
like all the others is single-hop (MON to MX), attackers won't
use a CSV or SPF protected HELO, they simply pick another HELO.

> Forwarding or List-servers would not function with this type
> of strategy however.

Yes.  And receivers usually don't know what the client is, they
have to assume that it's some kind of mediator.  Especially a
mediator that does _NOT_ support SPF / PRA / DKIM.

> This loss of normal functioning would be a significant
> trade-off, where the use of delayed acceptance was offered as
> a possible means to mitigate the inability for a path
> approach to otherwise deal with mediators.

One argument _for_ DKIM is, that using SPF behind 1123 5.3.6(a)
won't work.  For PRA it's the complete 1123 5.3.6, not only (a)

If we'd now find that DKIM needs SPF (or PRA) that's a bit odd:

>> It makes no sense to base DKIM security on PRA, neither
>> technically nor procedurally.
 
> While sharing many of the same concerns, the review was an
> attempt to understand what Jim was considering, not to
> endorse any mechanism.

Okay - on the SPF list Scott and I just discuss SPF modifiers
to get a grip on this mess, ideas like "dkim=strong" (or weak)
and maybe some "op=from" (2821- and 2822-From always equal).

But I don't see any general solution wrt "DKIM replay attacks"
in these ideas yet.  DKIM is supposed to work on its own.

If we get the complete mix of SMTP and 2822 again, that's back
to square one, MARID. <shudder />
                                   Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Feb 2006 11:58:23 -0800

On Feb 12, 2006, at 9:03 PM, Frank Ellermann wrote:

>
>> Even this brief review was not limited to just Sender-ID as a path  
>> solution, but also included a list of HELOs that could describe  
>> the same path in one or two lookups.
>
> more sense than PRA or MAIL FROM.  We've nothing for arbitrary HELO  
> id.s.  At best we have CSV's zone-cut emulation.  But CSV like all  
> the others is single-hop (MON to MX), attackers won't use a CSV or  
> SPF protected HELO, they simply pick another HELO.

Verifying the HELO would be analogous to checking a wax seal on an  
envelope.  When the verified HELO is found within a list of valid  
HELOs for the signing-domain, the seal is intact.  Just as policy for  
an email-address within the signing-domain is not checked, when the  
HELO is within the signing-domain, checking for a list of valid HELOs  
would not be needed.  The threat review may consider the use of the  
HELO, but neither the DKIM threat review or protocol should be  
required to include details of how HELO is verified, or even how a  
list of HELOs is created.

When the wax seal is broken or missing, delayed acceptance from  
unknown IP addresses could provide a means to curtail all types of  
message replay abuse.  A verified HELO also offers a means to defend  
the DKIM process from an inordinate level of abuse as DoS  
protection.  When the HELO does not verify from an unknown IP  
address, or is outside the signing-domain, delayed acceptance will  
ensure the service impact is minimal.

DKIM keys will likely be added on a per MTA basis.  At the same time  
the Key is added to DNS for the MTA, HELO RR can be added at the same  
time.   This is not asking an organization to know all their IP  
addresses for all the machines ever used.  This is only asking that  
the HELO for this DKIM MTA also have a corresponding DNS entry.

Accountability for DKIM must exclude the message envelope.  However,  
accountability for the HELO includes the message envelope.  When DKIM  
is used in conjunction with HELO verification, then, and only then,  
can DKIM become a powerful means to abate spam and curtail replay abuse.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 14 Feb 2006 17:17:52 -0500

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>

> Verifying the HELO would be analogous to checking a wax seal
> on an envelope.

Amazing! <g>

I would not agree with this analogy.

First, "Wax Seals" are user based and optional.  The HELO Client Domain
Names (CDN) are not.

Second, the HELO CDN would be more analogous to the postal service
postmarks indicating the time of processing, postal office, location,
etc, that handled the processing and delivery of the parcel.

The realistic fact most people don't bother to look at it, or if they
did, probably couldn't make heads or tails with the information, it is
extremely close, if not exactly equivalent to how worthless the SMTP
client domain name has become today.

To put trust behave it (HELO), it would be akin to having the same trust
when using a registered or certified mail.   Without it, having the
postmarks won't tell you how many "hands" outside the portal service
touched the letter.

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Feb 2006 15:10:30 -0800

On Feb 14, 2006, at 2:17 PM, Hector Santos wrote:
>> envelope.
> First, "Wax Seals" are user based and optional.  The HELO Client  
> Domain Names (CDN) are not.

A verifiable HELO is optional.

> postmarks indicating the time of processing, postal office,  
> location, etc, that handled the processing and delivery of the parcel.

Verification of the HELO in conjunction with an association to the  
signing-domain is a means to discern the integrity of the message  
envelope.  Both the HELO and signing-domain are not related to a  
third-party identification akin to that of a post-office postmark.   
The trust established by DKIM is for the prefatory domain,  
independent of the message envelope or any email-address.  An  
verified HELO associated with the signing-domain provides an  
assurance the message envelope has been obtained first-hand, and thus  
has not been altered (analogous to the wax seal).

> The realistic fact most people don't bother to look at it, or if  
> they did, probably couldn't make heads or tails with the  
> information, it is extremely close, if not exactly equivalent to  
> how worthless the SMTP client domain name has become today.

A DKIM signature increases the value of a verified HELO, and  
conversely, a verified HELO increases the value of a DKIM signature.   
Delayed acceptance as a practical strategy might also offer  
motivation for ensuring the HELO can be verified and associated with  
a signing-domain.

> To put trust behave it (HELO), it would be akin to having the same  
> trust when using a registered or certified mail.   Without it,  
> having the postmarks won't tell you how many "hands" outside the  
> portal service touched the letter.

An association of the HELO with that of the signing-domain indicates  
the message envelope is being obtained first hand.  The HELO is not  
analogous to that of a postmark, the received header added by a  
recipient would provide a better comparison to that of a postmark.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 14 Feb 2006 18:29:11 -0500

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> recipient would provide a better comparison to that of a postmark.

Which is associated with EACH hop or client domain machine transporting
the message.  If you have X Received, it tells the story of the
sequenced processing, including the HELO machines.

But I don't need to look into the payload (letter) to find out at the
HELO level (postmark) if its valid or not.

In short, an invalid HELO means everything else invalid. It would be
illogical to suggest that the letter might be still "ok" if the postmark
is invalid.  Does it exist?  Sure, broken software and no incentive to
correct it - hence the relaxation and the exploitation.

Put another way, you must have a valid CDN before CSV/DNA can even have
chance of being reliable and if you agree this is true, then the
opposite is true as well.  Invalid CDN promotes a rejection and nothing
else really matters in a post-legacy world where there is a new level of
expectations.

Look Doug, it is obvious this is yet another clear indication of the
separation of the philosophies - one administration oriented, the other
more system process oriented.  The problem is that administrative ideas
(as you are suggesting it) are not compatible with existing practice.

Your push for CSV/DNA (which I expect will be increasing now in a "Phase
II" now that DKIM sans SSP has been "pre-standardized") is clearly
trust.   I, on the other hand, is simply suggesting that before you can
ride the bike to see if it will win you a race, your spokes, gears,
tire, brakes, and possibly seat is expected to be working order.  Just
because it a "branded" item doesn't mean it does not have quality
control problems.