Subject: [ietf-822] WSJ/gmail/ML, was a permission to...

From: Alessandro Vesely <[email-masked]>
Date: Sat, 03 May 2014 20:29:17 +0200

On Fri 18/Apr/2014 14:37:21 +0200 John Levine wrote:
> 
> I also note that this hack, with or without Ale's changes, does
> nothing to solve the send from gmail and WSJ article problems.

Those two problems can be solved in different ways.  Gmail could use a
third party's submission server just like they use its pop/imap one.
WSJ could write "WSJ.com" in the From: and the purported issuer in the
Subject: (and possibly also Reply-To:) instead of their currently
doing the other way around.

We need to refine the spec specifically for mailing lists.  I'd love
to read something like:

   A mailing list MUST NOT tamper with the From: field.  Those who do
   that are not mailing lists, and can work their own way out of
   DMARC.

Is it practical to mandate the same also for To:, Cc:, Date:?  Are
there lists which alter them?

Also:

   In order to get weak signatures, a mailing list needs to let its
   posters' domain admins know which posters post to which addresses.
   It is advisable to ask for posters' permission to do so.

That can be done manually for the time being.  Imagine lots of
ML-admins writing to the relevant postmasters asking to apply
low-profile signatures for specific MAIL FROM/RCPT TO pairs.  A
postmaster can verify that those users really post to those addresses,
and believe that it is a mailing list since its owner says so.  A
couple of scripts would do.  Automation can later be improved.

The same manual requests can be done for whitelisting, let's see the
pros and cons.

Either way, we have to do it at our expenses, since it's us who want
mailing lists.  Or we may hope that users' rebuttal will discourage
receivers from honoring DMARC policies, but that sounds like letting
email problems grow.

Ale

---

From: "John R Levine" <[email-masked]>
Date: 3 May 2014 14:37:51 -0400

>   that are not mailing lists, and can work their own way out of

Sorry, no dice.  There are plenty of lists that standardize the header 
syntax.

R's,
John

---

From: Paul Smith <[email-masked]>
Date: Sat, 03 May 2014 19:59:06 +0100

>     that are not mailing lists, and can work their own way out of

To be pedantic, if I send a message to a list saying:

hello ietf-822 members

and the mailing list sends a message to you saying:

hello ietf-822 members

-------------
This is a message from the ietf-822 mailing list. To unsubscribe click here

Who is the 'author' of the message? The message you received is NOT the 
one I sent. So, I'm not the author, so why am I in the 'From' field? So, 
arguably, the From field should be changed. Possibly it should be 
changed to:

From: [email-masked], [email-masked]

because we both, "collaboratively", wrote the message. However, this 
would probably break some mail clients/filters/etc because using 
multiple From addresses is not "normal".

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 03 May 2014 22:31:17 +0200

> doing the other way around.

In your proposal one spam/phishing fighting technique (DMARC) requires 
(at least) three techniques to solve its problems (which in turn may 
require another 3^2 techniques to solve their problems, which ... 3^n 
techniques ... et cetera).

> couple of scripts would do.  Automation can later be improved.

This really doesn't scale. Maybe you have the few TBTI ESP's in mind, of 
which there are only a few. But each domain that starts using p=reject 
will introduce a new set of relations (ML-admins-postmaster), which in 
turn will grow exponentially.

> receivers from honoring DMARC policies, but that sounds like letting

I agree there is a need to solve the current problems, but let's come up 
with one solution, not many.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Sat, 03 May 2014 17:13:55 -0400

On 5/3/2014 2:59 PM, Paul Smith wrote:

> Who is the 'author' of the message? The message you received is NOT
> the one I sent. So, I'm not the author, so why am I in the 'From'
> field? So, arguably, the From field should be changed. Possibly it
> should be changed to:
>

Paul,

You need to translate this technical philosophy into client/server 
protocol rule which means that the authoring domain has authorized 
resigning with a DMARC policy.   Otherwise, its will be detected as an 
unauthorized signer, spoofed mail.

It is far easier to fix DMARC which is still in draft form than to get 
into complex, borderline ethical, long time taboos of tampering with 
the 5322.From.

To do a visual display "Posted on behalf of" does not require a header 
change.  That could be an online MUA backend server rendering or 
offline MUA mail reader that takes the mail headers:

    From:  Paul Smith <[email-masked]>
    List-Id: <ietf-822.ietf.org>
    List-Post:  <mailto:[email-masked]>

and displays it in some way in the MUA:

    From: Paul Smith (Posted by ietf-822.ietf.org)

But thats not the problem.  The problem is when we dealing with the 
BAD mail.

Lets suppose you began to sign all your mail with pscs.co.uk at your 
server so that all your outbound mail has:

    From:  Paul Smith <[email-masked]>
    Dkim-Signature:  d=pscs.co.uk

This is considered a 1st party signature.

An central issue is how strong do you wish to make this signing 
practice. You need to tell the world what to expect about your signed 
mail:

    Do you always sign your mail or is it optional?
    Do you always sign your mail with psca.co.uk?
    Do you allow others to sign on your behalf?
    If so, who?

To do this, suppose you published a DMARC record:

    v=dmarc1 p=reject ......

which basically means only psca.co.uk always the mail. No one else.

Now, when you send mail to non-list receivers, direct to people, you 
will want the protection that DMARC offers at these receiver sites.

However, when you send mail to the IETF-822 list receivers, hopefully 
you want the list to also protect your domain by honoring your policy 
and only allow a valid 1st party signature submissions from you, 
reject it if not valid.

But now you also want to give the list server permission to resign. 
So basically what you want is to give the ietf.org domain permission 
to resign.  How is that done?

There are currently one way to do this using ADSP ATPS, ASL or TPA 
extensions.

ADSP was used as to piggy back to extend 3rd party policy information. 
Since ADSP is now historic, lets switch this to DMARC instead with the 
extensions.

Using ASL, your DMARC record changes to:

    v=dmarc1 p=reject asl=ietf.org ......

This simple small scale change fixes the problem by allowing all 
parties to see that your domain is allowing ietf.org to resign the 
mail.    It is "small scale" because you would be limited in the 
record size in how many domains you can fit in a TXT DMARC string record.

For larger scale, using Murray's ATPS (RFC6541 ) extension, the DMARC 
record is:

    v=dmarc1 p=reject atps=y ......

The atps=y tag say to check for "_atps." zone record for the signing 
domain, ietf.org, authorization.  You can create and see this record 
at the wizard http://www.winserver.com/public/wcadsp

   ;
   ; ATPS (v01) Zone Records for author-domain: psca.co.uk
   ; Generated by wcMakeADSP v3.11(c) copyright 2010 Santronics 
Software,Inc.
   ;

   _adsp._domainkey  TXT ("dkim=all; atps=y; asl=ietf.org;")
   PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps  TXT ("v=atps01; 
d=ietf.org;")

I think this is is very simple and elegant solution. Doug has TPA with 
similar zone records tags and labels to lookup.  Its all basically the 
same ideas.  Either way, we somewhat resolved the technical problem 
but we are left with the practical problem of getting the list 
operators/servers to even bother to do any POLICY lookup of any kind.

If the IETF had supported ADSP/ATPS back in DKIM-WG, this would of 
been a done deal long ago.  Yahoo's DMARC record would of been:

      v=dmarc1 p=reject atps=y

and there would be 30,000 ATPS records for all the purported list that 
yahoo says their users are members of.

30,000 DNS records for _atps authorizations?  Is that too much?  I'm 
sure it is, but i don't see realistic for most domains to see close to 
that much, not even 100 or even 50.  How many list domains do you 
believe too?   What would be the average number of list domains the 
average user belongs too?

The IETF SHOULD endorse 3rd party Authorization ideas so we can begin 
to finally solve this problem.

I'm done.

-- 
HLS

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 May 2014 20:35:23 -0400

> domain, ietf.org, authorization.  You can create and see this record at
    > the wizard http://www.winserver.com/public/wcadsp

    > PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps TXT ("v=atps01; d=ietf.org;")

    > similar zone records tags and labels to lookup.  Its all basically the

So, how in the world does this scale to having thousands of "trusted" mailing
lists?  Seriously.

I guess I'll have to read the draft to understand what the second record is.
It seems that it ought to be something like:
   ietf.org._adsp._domainkey TXT ...

    > If the IETF had supported ADSP/ATPS back in DKIM-WG, this would of been
    > a done deal long ago.  Yahoo's DMARC record would of been:

    > yahoo says their users are members of.

okay, but how would they have fit into that _adsp record?

    > I'm done.

I sure support the concept, but it seems to me that we need to do this
differently.

I was thinking that a (list) machine, receiving a signed message with
p=reject, would respond with some new 3xx code that would say, "great, I'd
love to help you, but you didn't delegate to me....", and then include
some transactional part that would help the right authorization occur.
Perhaps going back to the *user* to confirm.

After all, just because [email-masked] is a subscriber to ietf.org lists,
doesn't mean that [email-masked] wants his email redistributed by ietf.org.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Smith <[email-masked]>
Date: Sun, 04 May 2014 09:06:16 +0100

> unauthorized signer, spoofed mail.
No, all you need to do is admit that the mailing list server sent the 
message that came from the mailing list server - so set that to be the 
From/return-path.

Then, it's not spoofed, it doesn't upset DKIM/DMARC, and it all works fine.

The only down-side is that the From address has been changed - but I'm 
not really convinced that's enough of a down-side to warrant all the 
shenanigans to get it to work any other way.

This doesn't help anonymous forwarders, but, personally, I think those 
should be treated as the special case, rather than mailing lists.

-

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 04 May 2014 11:28:21 +0200

> Sorry, no dice.  There are plenty of lists that standardize the header

Isn't that one of those changes that Miles talked about in [1]?
[1] http://www.ietf.org/mail-archive/web/ietf/current/msg87865.html

Many SMTP servers used to standardize message format, and stopped in
order to avoid breaking DKIM signatures.  Won't ML do so too?

Ale

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 04 May 2014 12:00:56 +0200

> and the mailing list sends a message to you saying:

Martin explained the difference between From: and Sender: in:
http://www.ietf.org/mail-archive/web/ietf/current/msg87507.html

> the one I sent.

It seems to me the authored content is the same while a boilerplate
footer was added to explain why the message was resent.

> So, I'm not the author, so why am I in the 'From'

Multiple mailboxes in From: should be used when messages are
co-authored by multiple authors.

Ale

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 04 May 2014 12:01:03 +0200

> techniques ... et cetera).

It is not going to be exponential since the number of techniques
needed to solve this particular problem is dominated by the total
number of techniques available at this time :-)

Seriously, I'm not inventing anything new here.

>> low-profile signatures for specific MAIL FROM/RCPT TO pairs.
> 
> This really doesn't scale. Maybe you have the few TBTI ESP's in mind,
> of which there are only a few. But each domain that starts using
> p=reject will introduce a new set of relations (ML-admins-postmaster),
> which in turn will grow exponentially.

You're right, this is something of a hassle.  However, there are some
upper bounds, the number of users in a domain, the number of lists a
user is subscribed to,  the number of subscribers in a list.  By using
appropriate modes and formats, it won't be overwhelming.  When the
ball starts rolling it might become somewhat manageable, certainly
better than if each poster had to ask her/his postmaster the same
thing individually.

Those ML-admin-postmaster relationship are a plus, as they give an
occasion to meet and talk.  We may regard that happening as a
demonstration, which we call in order to drive the change.

Ale

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 04 May 2014 07:51:51 -0400

> message that came from the mailing list server - so set that to be the 
No. If I have a secretary make 20 copies of a letter, and drop it off at 
the post office, I'm still the author of the message.  A secretary, 
forwarder, mailing list, what have you, is acting on my behalf, as my 
agent.  The letter is from me, and the return address should be mine.  
(In effect, when I set reply-to to list, or a mailing list sets reply-to 
list, is that I'm asking/expecting that everyone who got the original 
letter, gets a copy of any reply.)

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: "John R Levine" <[email-masked]>
Date: 4 May 2014 09:03:02 -0400

> order to avoid breaking DKIM signatures.  Won't ML do so too?

I think you're confusing SMTP with SUBMIT here.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John Levine" <[email-masked]>
Date: 4 May 2014 13:13:30 -0000

>message that came from the mailing list server - so set that to be the 

Besides the semantic wrongness of this approach and the confusion
between envelope and header addresses, it has the severe practical
problem that the address of the actual author of the message no long
appears in a header, so there's no way to reply to her.

Before anyone suggests "fixing" this with reply-to, please review the
past 15 years or so of flamage about mailing lists and reply-to.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 May 2014 15:32:25 +0200

I may be stupid here, but why does dmarc even apply to messages with a 
List-Id? Right now I can't think of any case where it makes sense to use 
both List-Id and DMARC.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 4 May 2014 14:08:18 -0000

>List-Id? Right now I can't think of any case where it makes sense to use 

What do you think would happen if a List-ID: tag was a free pass
through spam filters?

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sun, 04 May 2014 08:08:06 -0700 (PDT)

> What do you think would happen if a List-ID: tag was a free pass

When did DMARC become the only anti-spam mechanism in the world? Nowhere did
Arnt say that messages containing a list-id should be exempted from all forms
of AS/AV processing, only that DMARC in particular isn't useful in this case.

FWIW, I agree with Arnt on this one. In fact the case has yet to be made that
DKIM-based whitelisting of list mail is more than a nice-to-have; per-user
whitelisting on the basis of List-id alone along with the usual checks for
blatent viruses and whatnot seems to work pretty well.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sun, 04 May 2014 08:29:49 -0700

> List-Id? Right now I can't think of any case where it makes sense to use

It's an appealing thought, but it seems to be a security holoe:

A spammer wishing to use a domain name covered by dmarc would merely
need to include a List-ID header field, to disable dmarc processing by a
receiver...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Sun, 04 May 2014 08:16:55 -0700 (PDT)

> I think you're confusing SMTP with SUBMIT here.

No, he's not. A lot of changes done by SMTP servers have been disabled to deal
with DKIM. SUBMIT and delivery time fixups are not being disabled AFAICT;
nobody cares about end users being able to apply or check DKIM signatures.

THe IETF has long maintained a sort of end-to-end fantsay view of how email
works, while simultaneously standardizing and fully condoning stuff that
doesn't work this way. MIME upgrading and downgrading are the obvious example
here, but there are others.

As for mailing lists, the notion that they are going to stop makes deep changes
to messages is also a fantasy. Again, there's an obvious example: The insertion
of legal disclaimers is an absolute requirement for some lists.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 4 May 2014 11:40:30 -0400

> blatent viruses and whatnot seems to work pretty well.

Currently, I agree with you.  But if List-ID always meant to skip the 
DMARC rejection checks, how long would it take for every paypal.com phish 
to include a List-ID?  Presumably competent filters would subsequently 
catch it, but it would make DMARC, which is intended to be a cheap 
anti-phish technique, totally pointless.

Per-user whitelisting on List-ID strikes me has having horrible scaling 
issues.  How can we know who's subscribed to what?  Or if we plan to know 
what List-ID's to believe, we're back at a shared mailing list whitelist.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 4 May 2014 11:42:48 -0400

> No, he's not. A lot of changes done by SMTP servers have been disabled 
> to deal with DKIM. SUBMIT and delivery time fixups are not being 
> disabled AFAICT; nobody cares about end users being able to apply or 
> check DKIM signatures.

I've always had a separation between relay and submission, so the fixup 
issues never came up here.  (It's one of qmail's virtues.)  Dunno what the 
timeline has been for other MTAs.

In this particular case, I was more thinking that some combination of the 
mailing list software and the submission server the list uses would tidy 
up the headers.

Regards,

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 May 2014 18:03:08 +0200

> need to include a List-ID header field, to disable dmarc processing by a

Yes.

If you do dmarc processing for ma message with list-id, you get ~100% false 
positives. If you skip it, ~100% false negatives. Pick your poison. I have 
my opinion as to which poison is better in this case.

Arnt

---

From: Bart Schaefer <[email-masked]>
Date: Sun, 4 May 2014 11:39:26 -0700

> anti-phish technique, totally pointless.

For paypal and other institutional senders, wouldn't it suffice to have a
special DMARC policy that forbids mailing lists from forwarding messages?
 Then anyone who receives a message from such a sender that also has a
List-ID can still reject the message, and compliant mailing lists can
reject before forwarding.

Then the problem boils down to impersonating both an individual sender and
a list to which he is supposedly subscribed.   If a List-ID is present and
the list exploder has re-DKIM-signed the message, a DMARC check that the
message really did come through the list exploder should be enough?

Filters could combine this with a day-old-bread strategy to treat brand-new
List-ID sources as suspicious until a reputation is established.

---

From: Hector Santos <[email-masked]>
Date: Sun, 04 May 2014 14:33:25 -0400

> So, how in the world does this scale to having thousands of "trusted" mailing

We won't know if we don't try it.  Of course, there is a management 
issue, but its doable. Simple but new DNS tools are needed. Surely, 
DNS is robust enough it.

> okay, but how would they have fit into that _adsp record?

It would not fit within a "asl=" tag list of course, but ATPS records 
would be used for a larger scale.   For example, for isdg.net I have 
the following records:

_adsp._domainkey        TXT	( "dkim=all; atps=y; 
asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecoffee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;" 

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT   ( "v=atps01; 
d=megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT   ( "v=atps01; 
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT   ( "v=atps01; d=gmail.com;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT   ( "v=atps01; 
d=mipassoc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT   ( "v=atps01; d=ietf.org;" )
q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT   ( "v=atps01; d=isdg.net;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT   ( "v=atps01; 
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT   ( "v=atps01; 
d=santronics.com;" )

Can DNS handle 30,000 for a zone file?  No problem.

> I sure support the concept, but it seems to me that we need to do this

I agree we should review all the work, the explorations for optimizing 
and scaling DNS lookup methods, maybe there is better new DNS 
expectations for "wild cards."  I don't think we are ready to switch 
to a non-DNS lookup solution, but it should be considered if only as a 
blackbox I/O function.

Also, there is also the DKIM signature i= tag value or AUID "Agent or 
User Identity" which may play a role in DKIM-LIST environments. See 
comments below about AUID.

> Perhaps going back to the *user* to confirm.

Yes, it would be one deployment option.

The IETF should be documenting the practical possible deployment 
options for a SMTP REJECT protocol semantic without the lost of 
security. The alternative options provide the same security protection 
to the end-user -- no harm, which I think includes:

   [X] Honor DMARC p=reject by:
       (o) 550 Reject
       (_) 250 Accept and Discard
       (_) 250 Accept and Keep
       (_) 250 Accept and Quarantine (user junk bin)
       (_) 250 Accept and Bounce/DSN
       (_) 250 Accept and Non-Bounce Notification

Of course, a restrictive domain could quarantine DMARC failed mail and 
present it to the user (in a safe way) to get his acknowledgment 
and/or authorization, thus "learning" a whitelist of resigners.  Yahoo 
decided not to implement or deploy the DMARC p=quarantine mode of 
operations.

> doesn't mean that [email-masked] wants his email redistributed by ietf.org.

The real question is whether there is a security hole with yahoo.com 
opening up its
DMARC policy with trusted 3rd party resigners.  Can a bad guy use the 
trusted ietf.org site to send bad mail purportedly from an 
uncompromised [email-masked]?

User-based policies or user-level granularity designs was always left 
on the back burner for its obvious design overhead and complexity. It 
was all very vague how we can use some of those options, and if any, 
at some local level only.

The AUID "Agent or User Identity" DKIM-Signature i= tag value is an 
example.  In DKIM RFC6376 theory, we have two parameters for lookups:

    DKIM-Signature: ... d=SDID i=AUID

where SDID is the signing domain and AUID is the optional sub-domain 
of the signer domain.

This strict SDID/AUID alignment has always been a problem.  It could 
be used for user granularity authorization at some level but it lacked 
flexibility for a 3rd party policy semantic unless the implementation 
added the author address as part of the AUID.  I have an example of 
that with our DKIM implementation signer configuration option shown below.

The problem was the lost of an "Author Domain Identity" (ADID) in the 
DKIM equation:

    From: user.id@ADID
    DKIM-Signature: ... d=SDID i=AUID

And we also now have a possible mail List-ID to consider:

    List-ID: MLID

What are all the relationships between these ADID, SDID, AUID and MLID 
identities?

Maybe that is the abstract question DKIM alludes to by separating SDID 
and ADID, but we now know the DMARC industry is not wanting to 
separate the two.  Here is what DKIM says about SDID and AUID:

     3.11.  Relationship between SDID and AUID
     http://tools.ietf.org/html/rfc6376#section-3.11

How do we scale an authorization system for a 3rd party SDID signer 
who MAY be related to the ADID, AUID and/or MLID?

How do we separate the SDID and AUID to add the ADID?  What we did 
with our DKIM implementation was to offer the following DKIM signer 
configuration option for setting the i= tag:

# USER DEFINED TAGS:
#
# The UserTags are experimental. They are additional signed "tag=value;"
# information added to the signed signature.  The tag MUST NOT conflict
# with an DKIM standard tag.
#
# IDENTITY (i=)
#
# The optional i= tag allows you to add any valid formatted "email 
address"
# (but it doesn't have to exist).  It must be the same domain as the 
signer
# or a sub-domain of the signer.  Some macros are available:
#
#   {AUTHOR}           replace the Author (From:) address
#   {AUTHOR.DOMAIN}    replace the Author (From:) address domain
#   {SIGNER}           replace the signer domain
#
#   example: i= {AUTHOR}.{SIGNER}

So as you can see, this was one way to get the ADID into the DKIM 
equation:

    DKIM-Signature: ... d=SDID i=ADID.AUID

There are a lot of ideas considered, included some CallBack methods 
where a Message ID (MSGID) can be checked at the source. IBM even has 
a MSGID call back patent.

Whatever the DKIM-LIST resigner solution is, the receiver's DKIM Check 
Signing Practice (CSP) module process model could be:

       RESULT = DKIM_CSP(SDID, ADID, AUID, MLID, MSGID)

and ultimately, it is the ADID Author Domain that should have the 
final mail policy say in what is expected and honored for any of this 
to have a chance to work.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 4 May 2014 19:26:22 -0000

>special DMARC policy that forbids mailing lists from forwarding messages?

I think this leads to an infinite regress.  AOL and Yahoo have a real
problem: crooks broke in and stole people's address books, and are now
sending spam from AOL and Yahoo addresses to recipients in the users'
own address books.  Spammers are not totally stupid, and if is a
flavor of DMARC they could bypass with a List-ID, they'll add a
List-ID.  Even worse, since the volume of spam is vastly greater than
the volume of legitimate mail, most mail with List-ID would be spam,
and it would perversely become a fairly good spam indicator.  If
you've seen the X-Anti-Abuse header added by web hosting control
panels, it's suffered the same fate since spammers have figured out
how easy it is to break into dusty blog and CMS sites and spam from
them.

The basic problem here is that anything a list can do to say "I am a
list", a spammer can do, too.  You can only make credible assertions
to decrease the reputation of your mail, e.g. SPF's if it's not one of
these IPs, it probably isn't me, or to say "this is really from me", so
people can apply whatever opinion they already have of you.

The permission to forward hack is a little different since it's not
the list making the assertion, it's the list in combination with the
original sender, applicable to one specific address via one forwarder
for a limited time.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 May 2014 15:27:08 -0400

John R Levine <[email-masked]> wrote:
    >> FWIW, I agree with Arnt on this one. In fact the case has yet to be
    >> made that DKIM-based whitelisting of list mail is more than a
    >> nice-to-have; per-user whitelisting on the basis of List-id alone
    >> along with the usual checks for blatent viruses and whatnot seems to
    >> work pretty well.

    > DMARC rejection checks, how long would it take for every paypal.com
    > phish to include a List-ID?  Presumably competent filters would
    > subsequently catch it, but it would make DMARC, which is intended to be
    > a cheap anti-phish technique, totally pointless.

So, I think that we need more p= options.

If we had:
   p=reject-even-if-list-id

that would satisfy the paypal case. (But, wait, btw, paypal employees are
@paypal.com.  They need corp.paypal.com or some such).

And the classic:
   p=reject-unless-list-id-in-which-case-do-more-work

would work for yahoo.

To me, it seems that really we need an in-SMTP protocol by which senders are
told that they are sending to a re-distributor, and their current policy
won't do, but that they can do X.  That has to go back to the user.

Along the way, we probably should be standardizing the prove-that-you-own-this-mailbox,
back and forth so that the user's MUA/MTA can recognize that it is a list
already.   Maybe if one does that, then providers-of-mailboxes will start
putting a different From: on mailing list traffic, different from 1:1
traffic.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 May 2014 15:32:57 -0400

>> So, how in the world does this scale to having thousands of "trusted"
    >> mailing lists?  Seriously.

    > issue, but its doable. Simple but new DNS tools are needed. Surely, DNS
    > is robust enough it.

Uhm, there is a limit on how big a TXT record can be.
As far as I can see, I have to list all the mailing lists into asl=

    > would be used for a larger scale.  For example, for isdg.net I have the
    > following records:

    > d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT (
    > "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps
    > TXT ( "v=atps01; d=gmail.com;" ) n3lsehml2wgbfxov7hsak2qzsubsefhb._atps
    > TXT ( "v=atps01; d=mipassoc.org;" )
    > d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT (
    > "v=atps01; d=santronics.com;" )

    > Can DNS handle 30,000 for a zone file?  No problem.

Yes, but that's not the place there is a scaling problem.

    >> p=reject, would respond with some new 3xx code that would say, "great,
    >> I'd love to help you, but you didn't delegate to me....", and then
    >> include some transactional part that would help the right
    >> authorization occur.  Perhaps going back to the *user* to confirm.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "John Levine" <[email-masked]>
Date: 4 May 2014 19:37:42 -0000

>   p=reject-even-if-list-id

Won't work.  See previous message.

>@paypal.com.  They need corp.paypal.com or some such).

They're on top of this problem, and use paypal-inc.com.

>won't do, but that they can do X.  That has to go back to the user.

Remember that there are other things that DMARC broke, that do not
involve forwarding.  That's what "WSJ/gmail" in the subject line are
about.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sun, 04 May 2014 13:10:00 -0700 (PDT)

> anti-phish technique, totally pointless.

One way or another, the Internet routes around what it perceives to be damage.
There is absolutely no question that DMARC usage by domains that aren't purely
transactional in nature is being seen as damage. So the only question isn't
whether this damage will be contained, it's how.

Now, it's entirely possible that it will be done in a way that leaves DMARC
intact. But it is also possible that it will be done in ways that leave DMARC
in tatters.

And I for one am having a lot of trouble mustering up any sympathy if we end up
with the latter.

> issues.

Really? Given that we've seen per-user per-sender blacklists implemented  on
massive scale with no scaling issues, I for one fail to see the issue. (This is
not to say that these blacklists worked. They sucked completely and failed
badly, but not because of scaling issues.)

>  How can we know who's subscribed to what?  Or if we plan to know

I don't think so. The obvious model would be to check to see if the list-id
address is in the recipient's address book, and to instruct users to add list
addresses to their address book in order to insure list delivery.

This builds on the very common whitelisting model of checking the from address
against the recipient's address book. Which, BTW, also seems to scale just
fine. And which, incidentally, is one of the things that makes the
AOL and Yahoo address book thefts even more problematic.

And if you don't have address book integration, then a whitelisting rule
that checks the list-id would seem to do the trick.

Of course this has the side effect of weakening, but not breaking DMARC, as
well as making future address book thefts more problematic for mailing lists.
Funny how these things work.

				Ned

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 04 May 2014 16:40:50 -0400

> appears in a header, so there's no way to reply to her.

one obvious partial fix is a "originally-from:" header - I seem to have 
seen comments that Google Groups is adding an "x-originally-from" header 
to list traffic.

a longer-term fix would seem to be to get serious about an effort to 
develop SMTP2, or some such refactoring that incorporates 
authentication, integrity, and mailing list functions into the message 
format and SMTP state machine definition in a standard way (any ideas 
who might fund some focused work in that regard, the way ARPA and NSF 
used to fund protocol work?)

Miles Fidelman

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 May 2014 15:28:39 -0400

Bart Schaefer <[email-masked]> wrote:
    > Then the problem boils down to impersonating both an individual sender
    > and a list to which he is supposedly subscribed.   If a List-ID is
    > present and the list exploder has re-DKIM-signed the message, a DMARC
    > check that the message really did come through the list exploder should
    > be enough?

Spammers started using mailing archives to find out *EXACTLY* this, in order
to forge From: lines that would get into mailing list filters.  I first saw
this a few years ago.  I'm not sure why it hasn't become a bigger problem.

DMARC processing on input to mailing lists certainly would help there.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 May 2014 20:19:40 -0400

John Levine <[email-masked]> wrote:
    >> If we had: p=reject-even-if-list-id

    > Won't work.  See previous message.

I think you are reading it wrong.
It's basically the same as p=reject is now.
The other one, would mean: there are some things that could change
by an intermediary.

    >> that would satisfy the paypal case. (But, wait, btw, paypal employees
    >> are @paypal.com.  They need corp.paypal.com or some such).

    > They're on top of this problem, and use paypal-inc.com.

right!

    >> To me, it seems that really we need an in-SMTP protocol by which
    >> senders are told that they are sending to a re-distributor, and their
    >> current policy won't do, but that they can do X.  That has to go back
    >> to the user.

    > involve forwarding.  That's what "WSJ/gmail" in the subject line are

Yes, I understand.  I'm not sure that web sites sending on my behalf
is ultimately distinguishable from spam without some cryptographic route
through the browser/webserver into my MUA.

I can imagine such a channel, but I don't think we want to talk about that.
I think that we should list the various problems that we have discovered and
it may be that some we can fix, and some we can not.

Ultimately, in the space of end-to-end SMTP, lists are a form of
intermediary.  DMARC is a form of BCP38...

---

From: Russ Allbery <[email-masked]>
Date: Sun, 04 May 2014 20:07:47 -0700

Ned Freed <[email-masked]> writes:

> Now, it's entirely possible that it will be done in a way that leaves
> DMARC intact. But it is also possible that it will be done in ways that
> leave DMARC in tatters.

> And I for one am having a lot of trouble mustering up any sympathy if we
> end up with the latter.

+1

Right now, I consider breaking DMARC signatures to be a feature, not a
bug, and am acting accordingly in the maintenance of my mailing lists.
Users who want reliable mailing list service can use a non-broken email
provider.

If we come up with something better, I'm happy to consider it.  But I'm
not going to jump through hoops, or rewrite messages in broken and
deceptive ways, just because Yahoo and AOL had a security problem that
they want to externalize to the rest of the Internet.

-- 
Russ Allbery ([email-masked])              <http://www.eyrie.org/~eagle/>

---

From: Brandon Long <[email-masked]>
Date: Sun, 4 May 2014 22:58:59 -0700

> they want to externalize to the rest of the Internet.

I guess I just don't understand this sentiment.

The people who operate Yahoo/AOL have made this decision, and
"externalized" it to mailing list administrators.

Your choices are to route around the issue... or externalize the problem
yet again to the members of your lists.

You write as if changing email addresses or service providers is something
that people do at the drop of a hat, but it is not that way.

Or, we can hope that enough mailing list providers get together and stay
the course, break enough mail that Yahoo/AOL feels the pain and loses
customers or just plain feels the blow-back... but I see now indication of
that.  Heck, AOL saw the pain that Yahoo users were having and jumped right
in with their eyes open.

We talk on this list of possible solutions, but really, there are only two
that will work for mailing lists today: pass the messages through intact so
DKIM doesn't break, or modify the From header of the message.  Even if we
come up with a different solution, the time to implementation, and to
implementation by everyone who has adopted DMARC as is would be non-zero.

What is more important to your mailing lists, some historical formatting,
or the participation of your members?

Brandon

---

From: Brandon Long <[email-masked]>
Date: Sun, 4 May 2014 23:01:34 -0700

> third party's submission server just like they use its pop/imap one.

Gmail does allow you to use a third party submission server, and it looks
like we may have to encourage its use even more in the future.

Brandon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 5 May 2014 09:13:56 +0200

Ned Freed answers John Levine:
> massive scale with no scaling issues, I for one fail to see the issue.

Isn't this kind of whitelisting more or less what gmail does with the new 
"unsubscribe" button?

Arnt

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 05 May 2014 10:10:29 +0200

> I think you're confusing SMTP with SUBMIT here.

No, I didn't mean to.  Since you raised this topic, I think it's part
of submission servers' duties to check format and content (e.g. From:)
of outgoing messages, before signing.  SMTP receivers used to
standardize header and MIME structure too (e.g. encoding
auto-conversion); they stopped after DKIM, IME.

The question is where do MLMs position themselves in that respect?
Perhaps somewhere in between?

Ale

---

From: Hector Santos <[email-masked]>
Date: Mon, 05 May 2014 08:55:16 -0400

> they want to externalize to the rest of the Internet.

But its everyone's security problem, Russ.  The List Service Provider 
(LSP) just felt it more now when the high volume of DKIM+POLICY usage 
switched was finally enabled.  It was always a known possibility by 
design to offer strong filtering for self-signing 
exclusive/restrictive policies. The LSP has refused to adjust to a 
long time mail integration change need.  It wanted to add raw 
DKIM-BASE for resigning, but it didn't want the baggage that it came 
with with author domain policy lookups or for any signer domain lookup 
methodology for that matter. This second layer simply hasn't 
materialize.  No one (other mail software vendors) wants to add the 
logic to Check Signing Practices from either the AUTHOR or the SIGNER.

Go figure.

-- 
HLS

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2014 10:03:08 -0400

> like we may have to encourage its use even more in the future.

I'm not sure how realistic that is in practice for users who aren't 
uber-nerds.

To set up to use Yahoo's submission server from Gmail, I tried to 
configure it in the popup Gmail provided, which failed with an error 
message that told me to go log in at Yahoo.  I did, didn't help.  After 
some poking around I found a message in my Yahoo inbox that suggested I 
needed an app specific password.  (How many people will realize that Yahoo 
considers Gmail to be an app?)  It provided a link to the place in their 
credential server to create such a password, which is otherwise not easy 
to find.  So I finally found it, and made a password for Gmail, and then 
went back to Gmail, and used it, and indeed it worked.

But how many people without CS degrees are going to be able to go through 
all that?

Regards,

---

From: Ned Freed <[email-masked]>
Date: Mon, 05 May 2014 07:30:46 -0700 (PDT)

> But how many people without CS degrees are going to be able to go through

That's just the beginning. Even if you get the interface right (other
providers reportedly do this a bit better than Gmail), you now have the
problem that the submission server can't see the actual client IP address,
which is needed for logging and filtering purposes.

Of course there's a way to solve this problem: The XCLIENT extension or
a standardized variant of it. But for this to work there has to be
a recognizable relationship between all submission servers and all
send-on-behalf-of agents. Which sure looks like O(N*M) to me.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Mon, 05 May 2014 08:00:19 -0700

Hi Miles,
At 04:51 04-05-2014, Miles Fidelman wrote:
>No. If I have a secretary make 20 copies of a letter, and drop it 
>off at the post office, I'm still the author of the message.  A 
>secretary, forwarder, mailing list, what have you, is acting on my 
>behalf, as my agent.  The letter is from me, and the return address 
>should be mine.

Which MUA would you recommend for the secretary to send a message on 
behalf of an author?

Regards,
S. Moonesamy

---

From: Russ Allbery <[email-masked]>
Date: Mon, 05 May 2014 08:18:33 -0700

Brandon Long <[email-masked]> writes:

> customers or just plain feels the blow-back... but I see now indication
> of that.  Heck, AOL saw the pain that Yahoo users were having and jumped
> right in with their eyes open.

The mailing lists that I run are primarily technical.  If Yahoo and AOL
are deciding to become closed gardens and refusing to allow their users to
participate in broader Internet mailing lists, oh well, that's a business
decision on their part, and their users will have to react accordingly.
It wouldn't be the first time that certain service providers have opted
out of interoperability with the broader Internet and users have had to
decide whether they care or not.  I'm sure it won't be the last.

> What is more important to your mailing lists, some historical
> formatting, or the participation of your members?

Breaking mail addressing is considerably more than "some historical
formatting" and is more important to me than the participation of certain
members who have (through no fault of their own, to be sure) chosen to use
incompetent mail providers.

That said, I'm also happy to take an approach that will let users receive
the mail that they want to read, whether or not that destroys the
usefulness of DMARC.  But I'm not going to rewrite From headers to lie
about the author of the message.  That's a bridge too far for me.

---

From: Hector Santos <[email-masked]>
Date: Mon, 05 May 2014 12:10:28 -0400

> As far as I can see, I have to list all the mailing lists into asl=

If it fits your "Small scale" needs, ok. But the complete solution is 
with both ASL and/or the ATPS proposal.

ASL is a "smaller scale" solution using a "asl=" tag list of domains 
fitting as much as you can into a 512 byte TXT record without forcing 
a UDP->TCP fallback query switch.

For larger scale need, the ATPS method is to have one TXT record per 
authorized 3rd party signer domain. Is that OK?  Can that be improved?

This would be the suggested DMARC compliant receiver's Check Signing 
Practice (CSP) procedure for DMARC with the extended ASL, ATPS support:

1) Obtain the 5322.From header AUTHOR-DOMAIN and perform a
    DNS TXT query for "_dmarc.AUTHOR-DOMAIN" to obtain a
    policy record.

    If no DMARC record is found (NXDOMAIN),
       return result DMARC=NONE

2) Obtain the 5322.DKIM-Signature header SIGNER-DOMAIN and
    compare with the AUTHOR-DOMAIN.

    If the two domains are the same,
       return DMARC=PASS (authorized 1st party signer).

    otherwise continue with third party authorization checking.

3) If the DMARC record "asl=" tag is present, check the
    SIGNER-DOMAIN within the "asl=" list of domains.

    If SIGNER-DOMAIN is found in the "asl=" list,
       return DMARC=PASS (authorized 3rd party signer).

4) If an atps=y tag is present, perform the steps as outlined
    in ATPS (RFC6541) which is to lookup the TXT record existence
    for:

       base32(sha1(SIGNER-DOMAIN))._atps.AUTHOR-DOMAIN

    If the TXT record exist,
       return DMARC=PASS (authorized 3rd party signer)

6) return DMARC=FAIL (unauthorized signer).

-- 
HLS

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 05 May 2014 14:42:27 -0400

S Moonesamy wrote:
>> No. If I have a secretary make 20 copies of a letter, and drop it off 
>> at the post office, I'm still the author of the message.  A 

Well, I was using physical mail handling as an analogy, but... Outlook 
supports delegated access rights for sending on behalf of, as well as 
scheduling meetings on behalf of another mail user. Would a recommend 
Outlook - that's a separate question :-)

---

From: Ned Freed <[email-masked]>
Date: Mon, 05 May 2014 13:45:40 -0700 (PDT)

> Outlook - that's a separate question :-)

I haven't set it up myself, but I believe our web client product supports it as
well.

And judging from how often we've been asked to implement various schemes to
authenticate various send on behalf of as part of SUBMIT, there are other
clients out there that support it.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Mon, 05 May 2014 13:47:32 -0700

Hi Miles,
At 11:42 05-05-2014, Miles Fidelman wrote:
>Well, I was using physical mail handling as an analogy, but... 
>Outlook supports delegated access rights for sending on behalf of, 
>as well as scheduling meetings on behalf of another mail user. Would 
>a recommend Outlook - that's a separate question :-)

Asking you to recommend Outlook is not something I would do. :-)

I have not tested Outlook.  Please do correct me if what I wrote is 
incorrect.  That MUA uses "Delegate Name on behalf of Manager Name" 
in the "From: header.  That's not what is in RFC 5322.

Here are some headers from a message:

   Return-Path: <[removed]@bounce.linkedin.com>
   Received: from maile-ed.linkedin.com (maile-ed.linkedin.com 
[199.101.162.60])
         by [removed] (8.14.5/8.14.5) with ESMTP id s457gjVQ013948
         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
         for <[removed]>; Mon, 5 May 2014 00:42:51 -0700 (PDT)
   Authentication-Results: [removed]; dkim=pass
         reason="1024-bit key; unprotected key"
         header.d=linkedin.com header.i=@linkedin.com header.b=UyTsPaJu
   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com;
         s=proddkim1024; t=1399275758;
         bh=m3RA41aYlIhAwutaZd8/5p6sXXx1rnDoi4kKdNf6PvU=;
         h=Date:From:To:Subject:MIME-Version:Content-Type:
         X-LinkedIn-Template:X-LinkedIn-Class:X-LinkedIn-fbl;
         b=UyTsPaJuxbvrbLbrhwPq0TwJFtNZIs1J1SEUUqKTK/uU0KIO14h/kyqTeDv1UTWeV
         7b3rh0lOA2HxK68t2PHlOzEo4N7qGPZMiNv0oDMu6hqI84wgZSuyDSSFeXa4c5+MV8
         QXitJEceBdbA94UaFZ/brLnGVq1VV8W6qi84XgwU=
   Date: Mon, 5 May 2014 07:42:38 +0000 (UTC)
   From: [removed] <[removed]>
   To:  <[removed]>
   Message-ID: <[email-masked]>
   Subject: Invitation to connect on LinkedIn
   MIME-Version: 1.0
   Content-Type: multipart/alternative;
         boundary="----=_Part_6815668_1839834165.1399275758986"

The email address in the "From:" header did not contain 
"linkedin.com" as the domain.  According to 
https://help.linkedin.com/app/safety/answers/detail/a_id/37021

   "Phishing is a common tactic that cyber criminals use to try and steal your
    information and your money."

How do I determine whether that message was not from someone trying 
to steal information?   How would linkedin.com send an invitation if 
the domain required permission to appear in the "From:" 
header?  There isn't a "Sender:" header in the above headers.

Regards,
S. Moonesamy

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 05 May 2014 21:19:11 -0400

I haven't actually dug into the details of how Outlook does things, 
but... does not RFC5322's series of resent- headers start to provide a 
direction for standardizing mailing list use of header fields?

Miles

S Moonesamy wrote:
>> Outlook supports delegated access rights for sending on behalf of, as 
>> well as scheduling meetings on behalf of another mail user. Would a 
>> recommend Outlook - that's a separate question :-)
>
> incorrect.  That MUA uses "Delegate Name on behalf of Manager Name" in 
> the "From: header.  That's not what is in RFC 5322.
>
>   Message-ID: 
> <[email-masked]>
> The email address in the "From:" header did not contain "linkedin.com" 
> as the domain.  According to 
> How do I determine whether that message was not from someone trying to 
> steal information?   How would linkedin.com send an invitation if the 
> domain required permission to appear in the "From:" header?  There 
> isn't a "Sender:" header in the above headers.
>
> Regards,
> S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 May 2014 21:27:04 -0400

> direction for standardizing mailing list use of header fields?

Before you go too far down this rat hole, consider how Sender ID worked out.  
It's premise was oriented around the idea that there was value in validating 
if those headers were authorized or not.  Also, it's almost impossible to pick 
the right header field out of From, Sender, Resent-From, and Resent-Sender 
without having to consider Microsoft patents (good, bad, or indifferent it's 
there - consult the MARID working group ML archives for details).

Scott K

---

From: Russ Allbery <[email-masked]>
Date: Mon, 05 May 2014 18:30:30 -0700

> direction for standardizing mailing list use of header fields?

I think these are used in the opposite direction of what you'd need to
satisfy the current constraints.  The entity doing the resending goes into
the Resent-* headers, and From is left unaltered, whereas to satisfy this
signature scheme you would need to do the opposite.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 06 May 2014 01:44:09 -0700

Hi Miles,
At 18:19 05-05-2014, Miles Fidelman wrote:
>but... does not RFC5322's series of resent- headers start to provide 
>a direction for standardizing mailing list use of header fields?

I read the relevant text as meaning that the "resent-" headers are 
added when a message is reintroduced.  I prefer to leave it to other 
people to interpret what that means.  There are a few List- headers 
which have been standardized for mailing lists.

I trimmed the headers of the message which I received from this mailing list:

   From: Miles Fidelman <[email-masked]>
   MIME-Version: 1.0
   To: [email-masked]
   Subject: Re: [ietf-822] WSJ/gmail/ML, was a permission to... (off-topic)
   Precedence: list
   List-Id: "Discussion of issues related to Internet Message Format \[RFC 822,
     RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
   List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>,
     <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
   List-Post: <mailto:[email-masked]>
   List-Help: <mailto:[email-masked]?subject=help>
   List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>,
     <mailto:[email-masked]?subject=subscribe>
   Content-Transfer-Encoding: 7bit
   Content-Type: text/plain; charset="us-ascii"; Format="flowed"
   Errors-To: [email-masked]
   Sender: "ietf-822" <[email-masked]>

There aren't any Resent- headers in the above.  I looked at a message 
that passed through another mailing list implementation; there 
weren't any Resent- headers.

Regards,
S. Moonesamy

---

From: Paul Smith <[email-masked]>
Date: Tue, 06 May 2014 11:12:17 +0100

On 05/05/2014 07:01, Brandon Long wrote:
>
>
> Gmail does allow you to use a third party submission server, and it 
> looks like we may have to encourage its use even more in the future.

We're thinking that as well, or just stopping forwarding services at all.

The problem with forwarders using third party services' submission 
servers is that the user would need to give out their login details - 
which is a big issue. Maybe users should be able to create extra sets of 
authentication details for their submission servers, but ONLY for mail 
going to their own email addresses, for forwarding servers to use. These 
could still let the messages be blocked by a spam filter, but would let 
the receiving server know that the messages are coming from a forwarding 
server, so (a) the forwarding server's reputation should not be affected 
by spam from there, and (b) some checks like DKIM might have to be 
ignored/loosened.

I suppose that a scheme like this could potentially be extended to 
mailing lists - when you subscribe, you give authentication details as 
well as an email address.

-

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 06 May 2014 13:02:47 +0200

> signature scheme you would need to do the opposite.

I beg to differ.  To adjust the signature scheme so that it works in
the face of resending is plan A.  The From: field is set by the
author's MUA and checked by the MSA.[1]  Leaving it unaltered is a
privilege that resenders need to earn by enforcing MSA-equivalent
checks.  WSJ article sending is an example where From: ought to be
changed, while gmail and MLs can keep it unaltered.

It is a technical challenge to define authentication correctly, but we
should not modify the semantics in order to meet the constraints.
This problem is not specific of DKIM signatures.  S/MIME and OpenPGP
present it too; for example, Thunderbird fails to verify S/MIME-
signed mailing list messages[2].

Whitelisting by (sub)domain name can be done according to how well
they carry out the checks they're responsible for.  Maintaining
whitelists without relying on authentication --plan B-- will likely
require more human knowledge and personal judgment than with a working
signature scheme in place.

Ale

[1] http://tools.ietf.org/html/rfc6409#section-3.2
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=885286#c4

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 06 May 2014 07:12:30 -0400

> which have been standardized for mailing lists.

Yes, I understand that.

My contention is that:
1. mailing list software performs a relatively stable, well defined, set 
of functions (re-distribution, subject tagging, adding headers and 
footers, etc.), but,
2. those functions are not performed in a standardized way, and,
3. if those functions we're standardized, a lot of things would become 
easier - including, perhaps, improved interoperation of lists with 
things like DMARC, better list-aware mail clients

It strikes me that the RFC-5322 resent-headers, which don't seem to be 
used much, might be a good starting point for such standardization - for 
a start, by getting past the overloading of the From: header that causes 
so many problems.

Miles

---

From: "John Levine" <[email-masked]>
Date: 6 May 2014 17:09:34 -0000

>going to their own email addresses, for forwarding servers to use.

That's approximately what Yahoo did.  See earlier message.

I still think it's unlikely that many people will find it usable, though.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 6 May 2014 17:12:38 -0000

>a start, by getting past the overloading of the From: header that causes 

Keep in mind that anything a mailing list can do, a spammer who wants
to piggyback on the generally good reputations of mailing lists can
also do.  Anything that says "I'm a mailing list" is only useful with
some sort of external validation that it really is a list.  If you
have to do that anyway, you might as well use the list's DKIM
signature as the key which doesn't involve inventing any new
mechanism.

I think it's also pretty clear that any scheme that depends on the
DKIM signatures of incoming messages transiting mailing list software
won't work, either.

---

From: Brandon Long <[email-masked]>
Date: Tue, 6 May 2014 10:26:55 -0700

On Tue, May 6, 2014 at 3:12 AM, Paul Smith <[email-masked]> wrote:

> The problem with forwarders using third party services' submission servers
> is that the user would need to give out their login details - which is a
> big issue. Maybe users should be able to create extra sets of
> could still let the messages be blocked by a spam filter, but would let the
> receiving server know that the messages are coming from a forwarding
> server, so (a) the forwarding server's reputation should not be affected by
> spam from there, and (b) some checks like DKIM might have to be
> ignored/loosened.
>
> I suppose that a scheme like this could potentially be extended to mailing
> lists - when you subscribe, you give authentication details as well as an
> email address.

I wasn't talking about forwarding or mailing list through MSA, I was
talking about sending from one service through another (ie, if you use
Gmail as your "client" to access your Yahoo account, you can set it up to
use pop/smtp-msa just like any non-web client).

Trying to use submission servers for forwarding/mailing lists... I don't
think that would be fun.  You'd be better off fetching messages with pop
instead of forwarding.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Tue, 6 May 2014 10:34:52 -0700

On Mon, May 5, 2014 at 7:03 AM, John R Levine <[email-masked]> wrote:

> credential server to create such a password, which is otherwise not easy to
> find.  So I finally found it, and made a password for Gmail, and then went
> back to Gmail, and used it, and indeed it worked.
>

Yes, it runs up against that other problem, that username/passwords are no
longer near useful enough.  In Gmail's case, you would only need an
application specific password if you have one-time passwords enabled on
your account.  The error message when trying to use your password would
give you to this url:
https://support.google.com/accounts/answer/185833which should be
enough for some non-CS types to figure it out.  Its less
than ideal, however.

But, even then, we have
http://googleonlinesecurity.blogspot.com/2014/04/new-security-measures-will-affect-older.htmlwhich
means that trying to use a password on an account isn't going to work
all that well in the future.  OAUTH2 SASL is almost an RFC, but using it
still has scaling issues for clients, in that there is no
discovery/registration protocol yet.  Theoretically, once all that is
accomplished and implemented, trying to authorize smtp-msa from one account
to another via the web would be as simple as an ACL pop-up that you can
agree to.

Clearly, that level of interop is a bit further away than we'd want any
solution to the DMARC issue.

Brandon

---

From: Russ Allbery <[email-masked]>
Date: Tue, 06 May 2014 15:10:48 -0700

Alessandro Vesely <[email-masked]> writes:

> I beg to differ.  To adjust the signature scheme so that it works in the
> face of resending is plan A.  The From: field is set by the author's MUA
> and checked by the MSA.[1] Leaving it unaltered is a privilege that
> resenders need to earn by enforcing MSA-equivalent checks.  WSJ article
> sending is an example where From: ought to be changed, while gmail and
> MLs can keep it unaltered.

Ah, yes, that scheme also works, as long as you can change the verifiers
to support this new scheme.  And would definitely be an improvement over
rewriting the From header.

> should not modify the semantics in order to meet the constraints.

Wholeheartedly agreed.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 May 2014 12:06:42 +0200

On Tue 06/May/2014 19:12:38 +0200 John Levine wrote:
> 
> Anything that says "I'm a mailing list" is only useful with some
> sort of external validation that it really is a list.

Please note that "really is a list" actually means "/good/ list".  An
unmoderated, unfiltered list, with no posting restrictions and
dubious subscription practices would technically still be a list, but
nobody would whitelist it --nor subscribe to it.

> If you have to do that anyway, you might as well use the list's
> DKIM signature as the key which doesn't involve inventing any new 
> mechanism.

A useful mechanism tells domain admins which users post to which
lists.  Domain admins can consider those posts as endorsements from
their users.

> DKIM signatures of incoming messages transiting mailing list software

As that is being told by the author of "A DKIM Profile to Enable
Message Forwarding", I guess I should believe it.  However, it is not
clear why.  Paul asked for Message-ID: to be signed too.[1]  I
suggested that each ML defines an h= header field list that authors'
domains can reliably sign.[2]

You mentioned even From: cannot be reliably signed because MLMs need
to "standardize" its syntax.[3]  It seems to me that eliminating some
of such gratuitous changes is the solution to DMARC-for-MLs which
minimizes the alterations in MLM software.  Are you sure it won't
work?

Ale

[1] http://www.ietf.org/mail-archive/web/ietf-822/current/msg06856.html
[2] http://www.ietf.org/mail-archive/web/ietf-822/current/msg06715.html
[3] http://www.ietf.org/mail-archive/web/ietf-822/current/msg06821.html

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 May 2014 12:10:40 +0200

On Tue 06/May/2014 19:34:52 +0200 Brandon Long wrote:
> 
> OAUTH2 SASL is almost an RFC, but using it still has scaling issues
> for clients, in that there is no discovery/registration protocol
> yet.  Theoretically, once all that is accomplished and implemented,
> trying to authorize smtp-msa from one account to another via the
> web would be as simple as an ACL pop-up that you can agree to.
>
> Clearly, that level of interop is a bit further away than we'd want
> any solution to the DMARC issue.

Except that OAUTH can also be used to authorize ML subscriptions with
the participation of the subscriber's mail server.  Knowing the [user,
list] pair, the server can apply weak signatures or whatever other
solution we'll find for the DMARC issue.  Other advantages over COI
include:

* Define a folder to store list mail at subscription time, and

* a real list of subscriptions, instead of a time-distributed
  database of reminders.

Ale

-- 
http://fixforwarding.org/

---

From: S Moonesamy <[email-masked]>
Date: Thu, 08 May 2014 10:59:19 -0700

Hi Alessandro,
>minimizes the alterations in MLM software.  Are you sure it won't

This mailing list breaks the DKIM Signature.  Gratuitous changes to a 
mailing list message is a matter of opinion.  I suggest reading the 
past discussions first if you are interested in trying to make it work.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 09 May 2014 12:23:24 +0200

Hi SM,

On Thu 08/May/2014 19:59:19 +0200 S Moonesamy wrote:
> This mailing list breaks the DKIM Signature.

No, it doesn't.  It broke elandsys' signature, but check tana's
signature on this message.  (I send this to ietf-822 only, to avoid
any confusion.)

So it seems I could publish a strict DMARC policy right now, and cause
minimal disruptions.  However, some verifiers (NetEase) consider
tana's h= inadequate, see "objection" below.

> Gratuitous changes to a mailing list message is a matter of
> opinion.

Well, not exactly.

For corrections, section 6.4 of RFC 5321 is rather clear that
submission servers MAY, while intermediate relays MUST NOT, apply
certain changes.  So the range where opinions may vary is whether an
MLM is to be considered akin to submission servers or relays.

By /gratuitous/ changes, such as adding/removing double quote marks, I
mean unnecessary embellishments that were already disputable before
DKIM took root.

> I suggest reading the past discussions first if you are interested
> in trying to make it work.

Yes, much of this discussion was recited at the time of ADSP, for
example http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html

The most relevant objection to weak signatures is why would domains so
concerned about security as to publish a strong policy weaken their
DKIM signatures?  A solution is to do so for ML messages only.

To recap, assume a domain has a DB of (user, mailing list) pairs which
defines ML traffic.  Messages to ML are then sent in separate SMTP
transactions and weakly signed.  MLMs sign those messages in turn,
using strong signatures.  Verifiers derive the validity of MLM domains
by comparing d= against To: or Cc: mailboxes.

Besides minor refinements, the major bar is to build that DB.  I
proposed to do it manually for starting, and then find out how to
automate its maintenance.

Ale

---

From: S Moonesamy <[email-masked]>
Date: Fri, 09 May 2014 08:44:13 -0700

Hi Alessandro,
>signature on this message.  (I send this to ietf-822 only, to avoid

The verifier at my end validated the ietf.org signature instead of 
the tana.it signature.

>mean unnecessary embellishments that were already disputable before

I thought that you mean subject tagging, etc.  If the objective is to 
ensure that an MLM does not make any change it is easier to say "MLM 
must not make any change as that will break X" instead of looking for 
a clause to justify whether any change is appropriate.

>DKIM signatures?  A solution is to do so for ML messages only.

Yes, it would weaken the DKIM signature.

>automate its maintenance.

I'd say try it. :-)  You may have to convince the people writing the 
software to make changes.  That's usually the difficult part.

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 May 2014 13:05:27 -0400

Alessandro,   I believe what SM meant, is that every list developer 
has its own level of change needs and for the most part, in my view, 
you really don't want to make big changes to your mail framework when 
adding DKIM.  Its complex. But for an integrated system when you  have 
more controls of all the part, its doable. Take a look at our wcDKIM 
integration with our wcListServer component.

    http://www.winserver.com/public/files/wcdkim-ssi.png

But in general, the main reason there is a general issue/problem with 
the general LS is because DKIM was added at the edge so it can 
"blindly" sign all the outbound mail.  The key word here is "Blindly."

Overall,  the MLS change requirements to make the MLS more "fitting" 
with the blind DKIM signer component is:

1) Subscription controls for restrictive domains,
2) Submission controls for restrictive domains, and
3) "Meta" information to tell the signer not to sign a particular list.

Where and how those things are done will vary.  Unless the MLS 
developer does it himself, it will be asking much of list operators to 
handle this complexity themselves.  So makes you understand why is far 
easier for the LSP (List Service Provider) and/or resigner market to 
just ignore all Author Domain Signing Practice protocol and just allow 
for a complete open ended DKIM signing network when perhaps the only 
signature that matters most, is that last one in the transport chain 
and as long as the receiver trust the last signer, it really doesn't 
matter what the author does or the previous resigners had done.

Unfortunately, its a GOOD versus BAD framework.  With the signer 
trust, you can only look for the GOOD. It doesn't know how to handle 
the BAD and that is what the author domain signing protocols attempts 
to address and the trust folks keep forgetting or don't wish to deal 
with -- the bad legacy spoofing/phishing mail that Trust people can't 
do anything about.

-- 
HLS