Subject: Re: [ietf-dkim] besides mailing lists...

From: Dave CROCKER <[email-masked]>
Date: Sun, 02 May 2010 09:49:11 -0700

On 4/30/2010 9:37 AM, Jeff Macdonald wrote:
> ESPs have a "forward-to-a-friend" feature for their clients. Its a
> feature in which the ESPs creates the content and sends a message from
> a friend, to a friend. It would be discarded. However, I'm willing to
> say this is a bogus practice.

F2F is a well-established and helpful feature.  That some uses of receive-side 
authentication cannot cope with it is a limitation of the authentication-based 
service, not a flaw in F2F.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 02 May 2010 17:33:29 -0400

>service, not a flaw in F2F.
If authentication has to be shoehorned into email without disturbing any existing practices then we may as quit and spend our time on something else.

Scott K

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 3 May 2010 11:06:35 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Sunday, May 02, 2010 12:49 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] besides mailing lists...
> 
> 
> 
> F2F is a well-established and helpful feature.  That some uses of
receive-
> side
> authentication cannot cope with it is a limitation of the
authentication-
> based

And it is easy enough to do "F2F" in a manner that does not break the
authentication-based service. 

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 03 May 2010 08:34:06 -0700

While I personally find F2F usage sort of creepy, from the receiver's standpoint it looks
for all intents and purposes like a mailing list, which for all intents and purposes looks
like an unsigned piece of mail purporting to be from my domain. Intent seems to have very
little to do with this... so maybe these all just fold into the same unsolved case.

Any other cases of out-of-sender's control of "legitimate" mail purporting to be from their domain?

Mike

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 3 May 2010 09:53:43 -0600

> authentication-based service. 

How?

-- Brett

---

From: John Levine <[email-masked]>
Date: 3 May 2010 16:40:42 -0000

>> authentication-based service. 

The system sending the mail signs it.  That's one of the great
advantages of DKIM, the signature doesn't have to match other header
addresses such as To: or From:.

A user whose domain publishes adsp=discard couldn't successfully use
such a service, but that's a limitation of ADSP, not of F2F mail or of
DKIM.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 3 May 2010 13:16:53 -0400

John gave one example but I personally don't think that is the best way
to do it.

This is no different than the issue that we at AG faced in 2007 with the
Storm Botnet heavily abusing our major brands. 

As long as we sent mail that used someone else's domains for the From
and the Mail From, we weren't in a position to participate in
authentication systems and efforts. I phrase it this way because (just
one example) many domains will not accept mail that claims to be from
their domain if it didn't originate from their own servers.  

So, using americangreetings.com, the Mail From and the From on our card
notifications is always [email-masked]. The information
about the sender is provided in the subject line and the body of the
message so that the recipient knows who created the card. No enduser
personalization other than name and email address is provided in the
notification email so as to provide consistency in the emails. This
makes it easier for mailbox providers as well as recipients to evaluate
the card notification for validity.

Without going into detail about our click through rates and the overall
reduction in phishing/brand abuse, I will say that this works from both
a business and a security perspective.

I will say that many brand owners are unwilling to make changes to their
infrastructure to implement this approach (vs sending as the enduser
email or "on behalf of" the sender email) until their brand is abused.
It really is that simple. In many (most?) cases it requires changes to
back end systems and that takes resources. The other factor is that it
is not perceived as a problem until after it becomes a problem.

Mike

> From: McDowell, Brett [mailto:[email-masked]]
> Sent: Monday, May 03, 2010 11:54 AM
> To: MH Michael Hammer (5304)
> Cc: [email-masked]; [email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 03 May 2010 15:53:28 -0700

On 5/3/2010 10:16 AM, MH Michael Hammer (5304) wrote:
> message so that the recipient knows who created the card.

So, by way of fantasizing an example:  when John Levine sends me a greeting -- 
remember I said this was a fantasy -- through you guys and I hit Reply to thank 
him... he doesn't get it.

 From a user's perspective, this does not seem like such a winning scenario.

d/
-- 

   Dave Crocker

---

From: Al Iverson <[email-masked]>
Date: Mon, 3 May 2010 18:08:19 -0500

>  From a user's perspective, this does not seem like such a winning scenario.

We're off in the weeds here, but a reply-to header would work just
fine to direct the reply message to the right person.

There's other reasons MH's scenario as described is a pretty good
practice, from the perspective of an ESP....stable domain identifier,
FBL participation at ISPs that tie it to authentication, etc.

But then the flip side of that is, the friend -- you -- will get an
email that doesn't actually have your friend's address in the from
field. Confusing, and could potentially result in higher spam
complaints than otherwise.

Then there's my concern about the differences in the applicability of
CAN-SPAM between the two scenarios. I could go on, but it seems out of
scope for the list....

Regards,
Al

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 03 May 2010 16:19:44 -0700

On 5/3/2010 4:08 PM, Al Iverson wrote:
> On Mon, May 3, 2010 at 5:53 PM, Dave CROCKER<[email-masked]>  wrote:

The weeds are certainly plentiful around here, but some consideration of 
scenarios that could be acceptable might be helpful.

The reply-to is a good point.  I assume that it would be something like:

    From:  John Levine <[email-masked])
    Reply-to:   John Levine <[email-masked]>

One wrinkle is that MUAs are not all that consistent in processing Reply-to's, 
based on my own experiences.  I post to mailing lists with a different from and 
reply-to and get replies to one or the other or both.)

> complaints than otherwise.

Most MUAs do not show the From: field email address.  So the disparity you cite 
is not necessarily something that most recipients will even see.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 03 May 2010 15:49:17 -0700

> service, not a flaw in F2F.

F2F was created in a kinder, gentler time, when address spoofing wasn't 
nearly as much of a problem as it is now.  The fact that F2F hasn't 
evolved to avoid spoofing users' addresses is a problem that is only 
made more tangible by email authentication.

Telnet (on port 23) was also a well-established and helpful protocol.  
But the threat landscape changed, and today few of us send our passwords 
in the clear.  The email threat landscape has similarly changed.

-Jim

---

From: Al Iverson <[email-masked]>
Date: Mon, 3 May 2010 18:47:06 -0500

On Mon, May 3, 2010 at 6:19 PM, Dave CROCKER <[email-masked]> wrote:

All good thoughts/feedback.

> One wrinkle is that MUAs are not all that consistent in processing
> Reply-to's, based on my own experiences.  I post to mailing lists with a
> different from and reply-to and get replies to one or the other or both.)

I wouldn't worry too much about this for a few reasons. We're both on
lots of mailing lists filled with email geeks who pay attention to the
to: and regularly override it. And occasionally forget to. I suspect
this might be an edge case. When I compare it to what I've observed
when doing it from the ESP side of things, the only mis-parsing of a
reply-to (replacing it with the from address)  that I ever saw was a
specific, well-known, occasionally irritating MUA and it only applied
to its sending of automated out-of-office replies.

-- 
Al Iverson | Chicago, IL | (312) 725-0130
Anti-spam: dnsbl.com and spamresource.com
@aliverson on twitter | www.baconrodeo.com

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 May 2010 16:23:31 -0700

> Sent: Monday, May 03, 2010 4:20 PM
> To: Al Iverson
> Cc: [email-masked]
> Reply-to's,

Indeed; pine, for example, asks the user whether or not to pay attention to Reply-To when replying.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 3 May 2010 20:45:37 -0400

You seem to have forgotten the reply-to header.

I have to say you have some strange fantasies.

Mike

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Monday, May 03, 2010 6:53 PM
> remember I said this was a fantasy -- through you guys and I hit Reply
to
> thank

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 3 May 2010 20:51:38 -0400

to
>  From a user's perspective, this does not seem like such a winning

Actually, I should have stopped before shooting off a reply. You have
the option of sending a response to John from the card itself.... 

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 03 May 2010 18:17:22 -0700

> the option of sending a response to John from the card itself.... 

I suspect that this is a problem in search of problem... the entire point
of these things is to get you to visit the site generally, so regardless of
email once you have them on your site you've got an entire web infrastructure
to make the next round of contact :)

Mike

---

From: John Levine <[email-masked]>
Date: 4 May 2010 01:49:50 -0000

>F2F was created in a kinder, gentler time, when address spoofing
>wasn't nearly as much of a problem as it is now.  The fact that F2F
>hasn't evolved to avoid spoofing users' addresses is a problem that
>is only made more tangible by email authentication.

I have to agree with Mike (alert the media!) that this seems to be a
solution looking for a problem.  There are F2F systems all over the
net, and the amount of spam or hostile spoofage we get from them is
trivial.

It might be worth noting that a well-run F2F system can put its own
signature on the mail, regardless of which of the many possible
approaches it uses to set up the To:, From:, Reply-To:, and other
visible headers.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 3 May 2010 21:51:16 -0400

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, May 03, 2010 9:17 PM
> of these things is to get you to visit the site generally, so
regardless
> of

But we do have the reply-to set to go to the person sending the card....
just in case.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 03 May 2010 22:59:47 -0700

> net, and the amount of spam or hostile spoofage we get from them is

But that's not really the issue.  The issue is whether and how using F2F might 
break end-to-end trust models that are being postulated when DKIM is used.

It's not whether there is likely abuse but whether the likely trust will become 
unenforceable, when it should be enforceable.

> approaches it uses to set up the To:, From:, Reply-To:, and other

And indeed, this might be the (or, at least, an) answer to the concern (except 
of course for ADSP assertions made too broadly because it can't cover this scenario.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 4 May 2010 15:48:01 -0000

>But that's not really the issue.  The issue is whether and how using
>F2F might break end-to-end trust models that are being postulated
>when DKIM is used.

>It's not whether there is likely abuse but whether the likely trust
>will become unenforceable, when it should be enforceable.

The only plausible trust model I've seen is to do good things with
mail that has signatures you have reason to think are virtuous.
Signed F2F works just fine with that.

>And indeed, this might be the (or, at least, an) answer to the
>concern (except of course for ADSP assertions made too broadly
>because it can't cover this scenario.

I have to say that ADSP is having just the pernicious effect that I
feared it would.  Its actual utility is very, very narrow, people want
it to do other things, so they start insisting that the rest of the
world redesign itself to match their concept of ADSP.  We seem to have
learned nothing from the experience with SPF.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Tue, 04 May 2010 09:28:29 -0700

> net, and the amount of spam or hostile spoofage we get from them is

To clarify my content, I'm not referring to spam or hostile spoofing 
from the F2F systems.  I'm referring to the spoofing done by F2F in an 
environment where there is a lot of spam/hostile spoofing elsewhere in 
the environment, and that F2F could be doing more to differentiate 
themselves from the bad stuff (use their own From address, for example).

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 05 May 2010 01:27:57 +0100

On 5/4/10 4:48 PM, John Levine wrote:
>  feared it would.  Its actual utility is very, very narrow, people
>  want it to do other things, so they start insisting that the rest of
>  the world redesign itself to match their concept of ADSP.  We seem to
>  have learned nothing from the experience with SPF.

ADSP offers limited utility as a transitional mechanism for stricter 
acceptance, and as an alternative to individual relationships with email 
providers throughout the world.  Predictable cases of unintended message 
loss that ADSP might cause can be mitigated with a third-party 
authorization mechanism.   The mechanism would allow domains a means to 
grant specific exceptions for the third-party services being used.

Lessons have been learned.  Unlike a comprehensive IP address list of 
authorized servers, as with SPF:

A) a hash label mechanism scales to any number of third-party services 
within a single transaction.

B) modified messages will not be confused with those directly from the 
sender domain.

C) authorization is limited to specific domains, and not for any message 
handled by a server.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 5 May 2010 08:23:28 -0400

> within a single transaction.

I don't see how this would work with mailing lists. A domain owner
would have to know all the lists his users may want to be on. His
users would need to know to notify him when they joined a new list.

--
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 May 2010 06:45:19 -0700

> users would need to know to notify him when they joined a new list.

+1.  Doesn't seem scalable to me.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 05 May 2010 16:33:39 +0100

On 5/5/10 1:23 PM, Jeff Macdonald wrote:
> On Tue, May 4, 2010 at 8:27 PM, Douglas Otis<[email-masked]>  wrote:
>    
Jeff,

Use of ADSP "all" or "discardable" for transactional, institutional, or 
corporate messages would differentiate these domains from those for the 
general public.  These domains would be asserting restrictive ADSP 
policies to limit recipient exposure to confidence schemes by reducing 
acceptance of messages lacking an Author Domain Signature.  
Unfortunately, limiting acceptance of messages lacking these signatures 
disrupts mailing-list participation and makes the desired protections 
generally impractical.

Before ADSP can be broadly utilized, a solution to mitigate message loss 
with acceptable third-party services is needed.  This could mean 
automating the publication of hash labels from user requests.  In most 
cases, sharing keys would not be practical.  Unilateral hash label 
authorizations can be specifically for a domain with messages having 
headers indicative of a mailing-list, for example.  The third-party 
authorization draft also allows authorizations to be managed by other 
domains through use of DNAME at the "_adsp." node.  An important aspect 
of this mitigation is that it requires the same overhead used to collect 
the ADSP policy.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 05 May 2010 16:59:09 +0100

> +1.  Doesn't seem scalable to me.
It is clear that sharing DKIM keys will not scale, determining spoofed 
mailing-list by ISPs will not scale, publishing SPF address lists will 
not scale.  However, since the publishing of hash labels can be 
automated or delegated, why would this be something that does not scale?

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 May 2010 09:22:09 -0700

> [email-masked]] On Behalf Of Douglas Otis
> Sent: Wednesday, May 05, 2010 8:59 AM
> Subject: Re: [ietf-dkim] forward to friend, was besides mailing
> lists...
> 

There are two points here that don't scale to me:

1) I don't think putting a burden on the users to register every list to which they might want to subscribe, or become subscribed, is scalable.  They will forget, or do it wrong, or lists will relocate to different domains, or a host of other scenarios, and then mail will start bouncing and complaints will fly.

2) I don't think that a large organization with security-focused operations people will think kindly of the idea of user-generated data making its way into the DNS, whether that's an automated process or not.  That doesn't even touch on the issue that user-generated data is being used to publish some kind of authorization of the use of that domain by others.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 05 May 2010 23:13:28 +0100

On 5/5/10 5:22 PM, Murray S. Kucherawy wrote:
>>   On Behalf Of Douglas Otis Sent: Wednesday, May 05, 2010 8:59 AM
>>
> 1) I don't think putting a burden on the users to register every list to which they might want to subscribe, or become subscribed, is scalable.
Most lists today require a subscription process.  An exchange upon 
acceptance of a subscription could trigger the publication of TPA 
records for service domains.
> They will forget, or do it wrong, or lists will relocate to different domains, or a host of other scenarios, and then mail will start bouncing and complaints will fly.
>    
A list changing its domain will cause similar problems.  Has anyone 
described lists changing their domain as causing a scaling issue?  A 
mailing-list changing its domain in conjunction with use of ADSP "all" 
would cause users to receiving similar feedback and to raise similar 
complaints.   Since third-party authorization eliminates a need for 
policy exceptions, use of  ADSP "discardable" could be deprecated as a 
bad practice that causes lost messages.
> 2) I don't think that a large organization with security-focused operations people will think kindly of the idea of user-generated data making its way into the DNS, whether that's an automated proc…
Unlike SPF authorizations that would include any message handled by a 
server, a DKIM third-party authorization is limited to the specific 
service domain.  And unlike SPF authorizations, the service domain can 
be differentiated from servers of the Author Domain and annotated as 
such.  The authorization of the third-party service only requests 
specific exceptions when applying restrictive ADSP policies.

By not leaving ADSP exceptions open to the discretion of any number of 
receiving domains,  a security focused operation retains its ability to 
take effective actions when a problem is detected.  In addition, unlike 
SPF authorizations, an automated audit of the third-party message 
handling should provide reasonable assurances against spoofing.  No such 
assurance is possible with SPF authorizations.

There was never a suggestion that user generated data be published in 
DNS, nor that automation exclude reputation checks or auditing 
procedures.  It should be clear that being able to request specific ADSP 
exceptions for third-party services only _enhances_ security when 
governed by those having the greatest interest in protecting recipient 
trust.

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 07 May 2010 15:29:39 +0100

> learned nothing from the experience with SPF.

Actually, I'm finding SPF quite useful. Rejecting spf fails, spam scoring 
on softfails, and limiting the exposure caused by whitelisting.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 08 May 2010 09:36:06 +0200

> on softfails, and limiting the exposure caused by whitelisting.

+1, whitelisting based on SPF or DKIM seems to work well for most 
lists that transmit invalid "From" values (besides ADSP, it is quite 
frequent to get, e.g., [email-masked].)

One question is whether SPF is a good method for selecting the 
/second party signature/, for reputation checking, in case there is 
no valid author domain's signature, but multiple valid signatures 
are present. In facts, servers that run various virtual domains on 
the same IPs cannot use rDNS to tell on behalf of which domain the 
current transmission is meant to be.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html