Subject: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Nov 2014 15:48:02 -0800

[co-chairs: I appreciate the latitude in letting me post this here, as
there appears to be no other appropriate venue, and presumably we'll be
done with this part of the work very soon anyway.]

I've received some on-list (which you've seen) and off-list feedback since
posting -05.  My understanding is that the ISE is waiting for review
comments from specific people he's asked (Eliot) but also is interested in
any other review comments people might be able to provide before advancing
to publication.

I have only two changes pending for an -06 based on the feedback I've
received and an observation of my own, namely:

1) Several editorial changes that don't alter the meaning of the technical
work at all; and

2) A change to the IANA Considerations that reduces the requirements on the
new registries from IETF Review to Specification Required (see RFC5226).

The justification for (1) is pretty straightforward in that they are of
little consequence overall.

The justification for (2) is largely procedural: I believe an independent
submission, not being a product of the IETF, shouldn't create such a burden
on the IETF; furthermore, there's really no reason for such stringent
review of extensions that don't seem likely to appear anyway.  The original
choice was made way back when we planned to do this document on the
Standards Track, but that's not how things worked out.

So if anyone feels comfortable making comments on whether or not such an
-06 would be ready for publication (i.e., -05, which is public, plus the
above changes), please say so on this list so the ISE can see them.  Any
other feedback is of course welcome.  I will post what I have for -06 as
soon as the embargo lifts on Monday.

I have not as yet included Doug's proposed changes as they don't seem to be
supported (there has only been opposition voiced so far), but that does
mean they were considered.

We would like to put this document to bed as soon as is practical as it
will be the reference basis for the current and future WG milestones, so
hopefully reviews will be quick and plentiful.  :-)

Thanks,
-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 05 Nov 2014 11:05:16 +0900

> 1) Several editorial changes that don't alter the meaning of the technical

I'm happy with the editorial state of the document, including the
state of the changes to -05 I've proposed off-list as accepted or
rejected by the editors.

 > new registries from IETF Review to Specification Required (see

I agree with this change for the reasons you gave.

I believe the document is ready for publication.

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

---

From: Brett McDowell <[email-masked]>
Date: Thu, 6 Nov 2014 18:06:42 -0500

I also support the -06 changes as you have explained them Murray.

Add me to the list of people speaking in opposition to the proposal what
would change "authentication" to "authorization".

Brett McDowell | [email-masked] | @brettmcdowell | +1 (413)
404-5593

---

From: [email-masked]
Date: Thu, 06 Nov 2014 11:06:40 -0800 (PST)

<chair hat off>

I have a few comments on the base specification.

In the step 7 in section 3.1.3, I think it would be helpful to add a sentence
about the determination of the organizational domain from the author domain.
Step 7 is also pretty large; you might want to consider breaking it up into
substeps or something along those lines.

Another problem with step 7 is the statement "small number of further DNS
queries to the Organizational Domain" is incorrect. Per step 1 in section
5.6.3, the author domain is queried first, then the organizational domain if
that fails to produce a viable result. This needs to be fixed, and adding a
reference to section 5.6.3 would be a good idea.

In section 3.1.4, the paragraph

   It is important to note that identifier alignment cannot occur with a
   message that is not valid per [MAIL], particularly one with a
   malformed or absent RFC5322.From field.  Handling of such cases is
   left to the discretion of the Mail Receiver.

doesn't really make sense to me. If the From: field is missing or is so
malformed that a domain cannot be extracted from it, it isn't a question of
alignment to other fields, but rather that there's no way to determine a DMARC
policy that applies to the message to begin with. Shouldn't that be the primary
reason invalid mail is problematic? Am I missing something here?

I'm not sure the use of a cousin domain in the example given in paragraph 5 of
section 3.1.4.1 is a good idea. The point of using a cousin domain in an attack
is that users will confuse/conflate that domain with a legitimate domain. (And
this is important in the context of this document because DMARC doesn't do
anything to prevent this attack in a From: field.) But the reason identifier
alignment is important isn't that the use of a cousin domain in a DKIM
signature, MAIL FROM, or EHLO/HELO field could cause problems, it's that
without alignment a bad actor could freely use any domain whatsoever in these
places. Users generally don't see these fields so why bother using a similar
name? The way the section is written makes it sound like protecting against the
use of cousin domains in particular is important. Unless I'm missing something,
that's not the case.

There's a bit of tension between section 5.5, which says that all you need to
do to "implement the DMARC mechanism" is publish DMARC records in the DNS, and
the diagram and list in section 3.1.3, which make it sound like deploying both
DKIM and SPF are a required part of DMARC setup and operation. I'm not sure
what, if anything, should be done about this, but I thought it worth noting.

There's a big problem in section 5.6.1, where it says that any message with
more than one address or an empty group in an RFC5322.From field SHOULD be
rejected.

I have to say I find this recommendation to be completely inappropriate. Surely
it should be possible for me to a legitimate, syntactically valid message that
happens to employ the multiple-from/sender format defined in RFC 5322 with all
the domains under my personal control and none publish any sort of DMARC
policy, and not have the application of DMARC to the overall message flow mess
it up? Or alternately, one where the From: field contains an empty group,
something we actually recently went to the trouble of writing RFC 6854 to
allow?

Sure, some clients may barf on such things, but that's a problem for whoever
opts to use the mechanisms, not DMARC.

I have no absolutely problem with rejecting messages with From: fields
containing any sort of domain identifier that has any sort of attached DMARC
policy because of how that From: field is constructed. But intruding on
legitate uses of email that choose not to employ DMARC in any capacity goes
much too far. And it isn't helped by the fact that the DMARC reporting
mechanisms are meaningless when there's no domain owner to report these
rejections to.

There's also a direct contradiction between the third bullet item in section
5.6.1, which says that a message without a From: field SHOULD be rejected, and
the fourth paragraph of section 3.1.4, which leaves this same case to the
discretion of the mail receiver. Furthermore, does it really make sense to give
malformed From: fields a pass - someomthing which could easily contain an
identifier that has an attached DMARC policy - and require rejection of
completely legitimate stuff with no DMARC policy in sight?

I could have missed it, but I don't see any place where the semantics of how
DKIM and SPF are combined (as an it's an OR) is specified prior to item 5 in
section 5.6.2. If this is indeed the case, then this is bad: The way the
mechanisms are combined needs to be made clear much sooner. I note in passing
that we've already had a case on this list where someone misunderstood this
detail.

Section 6.2.2.1 states:

   In the case of a "mailto" URI, the Mail Receiver MUST communicate
   reports using the method described in [STARTTLS] whenever it is
   offered by a Report Receiver.

I seriously question the value or appropriateness of this paragraph. So your
DMARC agent, assuming it actually goes through a SUBMIT server and not through
an internal API, uses STARTTLS to secure that connection. Now what? At present 
there's no standardized way to indicate in a message that it has to be
transported securely. So if you really want that, that leaves configuration - a
configuration that spans an essentially arbitrary set of transport agents, to
enforce this. At least part of which would have to be enforced by the target of
the mailto: to have any chance of being effective.

It's poor practice to have MUSTs in specifications that we know are going to be
ignored. It's also poor practice to have MUSTs that don't actually accomplish
much of anything as written. As such, I strongly recommend dumping this, or at
least making it a SHOULD.

BTW, I took a glance at the source for opendmarc-reports. I don't see any place
where it even tries to use STARTTLS, let alone requires it when talking to
something other than the local host, which is supported via command line
parameters.

Section 9.3 recommends using reply codes during the SMTP session rather than
doing anything that would require sending a DSN later, but doesn't come out and
say that the reason for doing this is to avoid blowback spam. I think it would
be clearer to be explicit about why these policies are a good idea.

That's it!

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Nov 2014 18:12:40 -0800

Thanks, this gives me something to do on the plane ride on Saturday.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Nov 2014 23:16:41 -0800

> substeps or something along those lines.

OK.

> reference to section 5.6.3 would be a good idea.

"small number" is "at most two", and "to the Organizational Domain" is
meant to include its subdomains, so I guess what's meant is to the
Organizational Domain's zone, or something like that.  I'll tidy it up.
Good suggestion on a forward reference.

> reason invalid mail is problematic? Am I missing something here?

No, I think you've got it, but I'm not clear on how the paragraph you cited
doesn't say that.  You have it exactly right: If From: is missing or so
mangled that it's not possible to get a domain out, then there's nothing to
which DKIM and SPF can align, and DMARC can't be applied.  There might be
other mangling though, like multiple From: fields that are properly formed
but contain distinct values, in which case we don't know to which one to
apply alignment.

I'm not sure the use of a cousin domain in the example given in paragraph 5
> of

I agree.  That paragraph should go.

> what, if anything, should be done about this, but I thought it worth

I'll see if I can tidy it up.

> something we actually recently went to the trouble of writing RFC 6854 to

As I recall, there were some surveys of some pretty large email streams,
and not a single instance of a From: field containing other than a single
mailbox could be found that wasn't also part of something either spammy or
some kind of attempt to confound spam filters, or just grossly malformed
and unusable.  This led the original DMARC community to what you see there
now.  There was no deliberate rejection of the RFC 6854 format, but just
rather no observed valid use of it.

> mechanisms are meaningless when there's no domain owner to report these

What sort of remedy would you suggest here?  Off the top of my head, here
are some suggestions:

1) Evaluate all the domains you find, and if any of them have published
DMARC policies, apply the strictest one (by that I mean: if there are any
with p=reject that fail, then reject it; if there are any with
p=quarantine, quarantine it); if not, treat the message as if DMARC simply
did not apply.

2) Evaluate only the first domain you find, if any.

3) Same as (1), but limit it to some fixed (configurable?) number of
domains.

> completely legitimate stuff with no DMARC policy in sight?

We've covered the latter point above, but as to the point about
malformation: Can you reliably extract a domain name from a malformed From:
field?  That seems to be a vector for trying to confuse a DMARC filter if
the advice is to try anyway.

> that we've already had a case on this list where someone misunderstood this

Section 5, third paragraph, is the first formal statement of this kind.
Adding one somewhere up earlier in one of the overview sections would
probably be a good idea.

> least making it a SHOULD.

I'd be fine with making it a SHOULD, exactly because of these reasons.

> be clearer to be explicit about why these policies are a good idea.

Sounds good to me.

Thanks!

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Nov 2014 23:22:35 -0800

> 3) Same as (1), but limit it to some fixed (configurable?) number of

4) Acknowledge the conflict with RFC 6854, but point out that DMARC
participants typically choose to reject them anyway (and drop the MUST).

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2014 18:06:51 -0000

>DMARC policies, apply the strictest one ...

Given the anti-phishing goals of DMARC, I don't see how anything else
makes any sense.  Or you could skip a step, say that DMARC doesn't
permit multi-address From headers, assume that validation failed on
all of the domains and proceed directly to the punishment phase.

For From: headers with address-free groups, recall that the motivation
for this was EAI downgrades at delivery time.  The un-downgraded
message had a normal From: header, so normal DMARC applies.  If the
address is smashed in the downgrade I don't see any reason that the
DMARC result needs to change.  

It also happens to enable an alternative to those
[email-masked] addresses in mail from robots, something I
haven't seen yet, but wouldn't be totally silly.  I'd say that
whatever you do with them is out of scope for DMARC.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Nov 2014 10:32:52 -0800

> all of the domains and proceed directly to the punishment phase.

Right, that's also an option, and it at least accommodates the no-address
>From field that RFC6854 permits.

Another option I can think of is one where we just admit the conflict with
RFC6854 and observe that streams likely to be DMARC-protected don't use
this format, so if you see a multi-valued From where any domain has a DMARC
policy, it's invalid and the receiver should act accordingly.

> DMARC result needs to change.

I don't know much at all about EAI, but if the address is smashed, which
DMARC result could you possibly use?

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Nov 2014 10:49:52 -0800

On Nov 7, 2014, at 10:32 AM, Murray S. Kucherawy <[email-masked]> wrote:

> Right, that's also an option, and it at least accommodates the no-address From field that RFC6854 permits.
> 
> Another option I can think of is one where we just admit the conflict with RFC6854 and observe that streams likely to be DMARC-protected don't use this format, so if you see a multi-valued From where any domain has a DMARC policy, it's invalid and the receiver should act accordingly.
> 
> I don't know much at all about EAI, but if the address is smashed, which DMARC result could you possibly use?

Dear Murray,

I too agree with John. It also seems a specific Group syntax might allow an obvious (and safe) alternate address strategy. This same approach might also support a scheme to re-write third-party services' From addresses.

Regards,
Douglas Otis

---

From: "John R Levine" <[email-masked]>
Date: 7 Nov 2014 15:45:27 -0500

> That's fine if any of the domains have an associated DMARC record - of any
> sort. My concern is the case where none of them do, or when there
> are no domains present.

In that case I agree with you, it's none of DMARC's business what happens.

> Neither do I.

Clarification for Murray: An EAI message might arrive with an address like 
this:

  From: stuff <[email-masked]>

where AAAA, BBBB, and CCCC are UTF-8 strings, and for extra excitement, 
AAAA includes characters not allowed in u-labels.  You can easily do a 
DMARC check on this address by turning BBBB.CCCC, which have to be 
U-labels, into A-labels and do a normal DMARC check.

Non-EAI mail can't handle the AAAA, so one of the ways a message might be 
smashed for delivery might be this:

From: "international address [email-masked]" :;

(You can use MIME encoding for the comment.)

So the address is gone, but the message remains, and the DMARC result 
might as well remain too.  I agree this is pretty deep into nit-land, so 
my only real concern is that there not be langauge that forbids doing the 
obvious thing in this situation.

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

---

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 7 Nov 2014 17:40:31 -0700

> I have a few comments on the base specification.

<snip>

> reason invalid mail is problematic? Am I missing something here?

The foundational statement is that for DMARC to be implemented, there
must be an address in the addr-spec portion of the RFC5322.From field. 
By my read, the current paragraph includes the necessary statements, but
perhaps it could be modified as follows to be more clear:

-----
It is important to note that identifier alignment cannot occur, and
DMARC determination applied, with a message that is not valid per RFC
5322 [MAIL].  This is particularly true when a message has a malformed
or absent RFC5322.From field.
-----

This proposed edit also addresses another issue in the thread: it
removes the tension between it and section 5.6.1.

<snip>
> mechanisms are meaningless when there's no domain owner to report these

There's a lot of interesting meat to chew on here... but maybe setting
some context would help feed the conversation.

Starting off, we can ignore a <null> address in the RFC5322.From field
as DMARC will have no bearing in that case.  Similarly, when there is
exactly one address in the RFC5322.From field, application of DMARC is
reasonably straight forward.

The question is what to do about more than one address in the
RFC5322.From field.  The options would be to not apply DMARC at all
(regardless of any addresses with associated DMARC policies), reject the
entire message, or run through the set of addresses and try to apply
DMARC in some way (if any of the addresses have associated DMARC records).

Not applying DMARC would enable malicious actors to slip through, so
that's not a great choice.  Rejecting the message outright (even if none
of the addresses have an associated DMARC policy) seems like it unfairly
punishes domains who aren't opting into DMARC.

That leaves taking some action based on the DMARC policies associated
with the set of domains represented in the RFC5322.From field.  It seems
that the most reasonable approach is to gather the DMARC policies for
all addresses, and then apply the most strict.

Given all that, here's my suggested revision to Section 5.6.1.:

-----
5.6.1.  Extract Author Domain

In order to be processed by DMARC, the domain(s) must be extracted from
the domain of the email address(es) within the addr-spec portion of the
RFC5322.From field. If the domain is encoded with UTF-8, the domain name
must be converted to an A-label for further processing. If no domain is
found, the message SHOULD be rejected (as it is forbidden under RFC 5322
[MAIL]).  If more than one domain identifier is found, the full set of
domains MAY be collected as a set of identifiers for DMARC processing.

It is useful to note that it may not be possible to extract a meaningful
author domain identifier from some messages.  For example, some messages
could:

   o  have multiple RFC5322.From fields (which is also forbidden under
      RFC 5322 [MAIL])

   o  have no RFC5322.From field (which is also forbidden under RFC 5322
      [MAIL])

   o  have an RFC5322.From field that contains no meaningful values, such
      as RFC 5322 [MAIL]'s "group" syntax.

Messages that are forbidden under RFC 5322 [MAIL] SHOULD be rejected
without requiring further DMARC processing.
-----

This change would also necessitate a slight change to Section 5.6.2. 
Below is my suggested revision that would bridge the gap:

-----
5.6.2.  Determine Handling Policy

To arrive at a policy disposition for an individual message, Mail
Receivers MUST perform the following actions or their semantic
equivalents.  Steps 2-4 MAY be done in parallel, whereas steps 5 and 6
require input from previous steps.  In the case where multiple
identifiers were extracted from the RFC5322.From field, steps 1-4 are
performed for each identifier, collecting the results, prior to
performing steps 5 and 6.

The steps are as follows:

   1.  Extract the identifier(s) from the addr-spec portion of the
       RFC5322.From field of from the message (as above).

   2.  For each identifier, query the DNS for a DMARC policy record
       published by the Domain Owner(s). Continue if at least one
       policy record is found, or abort DMARC evaluation otherwise.
       If there is more than one identifier, the DMARC policy found
       for each identifier SHOULD be collected as a set to be used in
       step 5. See Section 5.6.3 for the details of policy discovery.

   3.  Perform DKIM signature verification checks.  A single email may
       contain multiple DKIM signatures.  The results of this step are
       passed to the remainder of the algorithm and MUST include the
       value of the "d=" tag from all checked DKIM signatures.

   4.  Perform SPF validation checks.  The results of this step are
       passed to the remainder of the algorithm and MUST include the
       domain name used to complete the SPF check.

   5.  Conduct identifier alignment checks.  With authentication checks
       and policy discovery performed, the Mail Receiver checks if
       Authenticated Identifiers fall into alignment as described in
       Section 3.  If one or more of the Authenticated Identifiers align
       with an identifier extracted from the addr-spec of the
       RFC5322.From domain, the message is considered to pass the
       DMARC mechanism check.  All other conditions (authentication
       failures, identifier mismatches) are considered to be DMARC
       mechanism check failures.

   6.  Apply policy.  Within the set of DMARC policies found in Step
       2, select the most strict (with p="none" being the least strict,
       next being "quarantine", and "reject" being the most strict) to
       use in applying policy.  See Section 5.3 for details of the
       discovered DMARC policies.

-----

... of course, now that I've gone through that exercise, I realize that
this would necessitate a change to reporting (Section 6).  Basically,
that we need to report on the results to everyone with a DMARC record
that includes a request to receive reports... then there's the question
of what we should tell them (especially to a "none" policy domain about
a rejection due to a "reject" policy from another domain found in the
RFC5322.From field).

Off to the side, there may be some concern about a message that is
received with a large number (e.g. 100) of addresses in the RFC5322.From
field.  While ostensibly permitted, that would definitely raise some
eyebrows.  I have a feeling that mailbox providers know how to handle
that case, irrespective of DMARC.

> completely legitimate stuff with no DMARC policy in sight?

I tried to remove the tension in the proposed edit above.

<snip>
> the mailto: to have any chance of being effective.

+1 to removing the STARTTLS requirement in this specification.

HTH,
Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: [email-masked]
Date: Sat, 8 Nov 2014 13:57:18 +0900 (JST)

> or absent RFC5322.From field.

I occasionally see non-ASCII octets introduced by spam/virus checkers in
X-Spam-* fields in the header or in the (non-8-bit) message body, due to
copying message content into those contexts.  The From field is perfectly
valid, however.  Does that really mean that identifier alignment cannot
occur?

(I think that is a plausible policy choice, since in an invalid message
"anything can happen".  But I don't see that it's a no-brainer.)

> reasonably straight forward.

By "DMARC", you really mean "DMARC policy", right?  DMARC the protocol
does need to say something about what happens if alignment fails or no
policy can be discovered.

> all addresses, and then apply the most strict.

I wouldn't call that "reasonable".  It's the only plausible option, but
here's the problematic use case:

Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. 
For organizational political reasons it is necessary that (a) both names
appear on the memo and (b) Stephen has to do the dirty work.  Stephen
sends the mail "From: [email-masked], [email-masked]", with proper
SPF and DKIM setups.  Unfortunately, example.com publishes p=reject,
example.com alignment fails because Stephen sent the message, the MTAs
reject the message, and nobody except Trent and Stephen shows up to the
meeting.  I see two ways this message could pass DMARC: Stephen has the
keys for example.com, or the Japanese "ringi" system, where I write and
sign the message, send it to Trent, who then signs the message but
otherwise forwards it verbatim.  Both seem fragile to me.

OTOH, only checking policies of aligned SPF source domains and DKIM
signers means that Stephen (or any scammer) can add "[email-masked]"
to the From field and pass DMARC.  It's obvious what the Felons of April
would do with that.

I guess the most plausible approach to this issue is to say that if you
want to use DMARC and have multiple authors, you must contrive to give all
the authors mailboxes in the same domain.  In the example, I could create
the-committee.example.org for committee members, or give trent a
forwarding mailbox at example.org itself.

> found, the message SHOULD be rejected (as it is forbidden under RFC 5322

I still don't think a null From filed is any business of DMARC the
protocol.  That's really an issue for (a) the security considerations
section or (b) the planned BCP.

But this seems to be the insecure approach I describe above:

>        DMARC mechanism check.

AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to
send spam that passes DMARC on your behalf, as long as my mailbox appears
in From, too.  Am I misunderstanding your proposed algorithm?

>        All other conditions (authentication

Bottom line, I think both messages where no Authenticated Identifiers can
be extracted and those where multiple Authenticated Identifiers can be
extracted should be defined to be mechanism check failures.  In the former
case, policy discovery is impossible, in the latter, the strictest policy
should be applied.

Regards,
Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Nov 2014 23:26:03 -0800

> "anything can happen".  But I don't see that it's a no-brainer.)

Do you have another suggestion?

Note that there's nothing normative in Trent's suggestion.  If a receiver
thinks it can continue with the X-Spam-* fields malformed as described,
then it can continue on that basis.

> policy can be discovered.

That's how I understood what he said.

> forwarding mailbox at example.org itself.

Ned, do you concur with this analysis?  Is Trent's proposal coupled with
this caveat a valid remedy for your point?

> section or (b) the planned BCP.

I think we're all in agreement on that point so far.

> in From, too.  Am I misunderstanding your proposed algorithm?

No, because in (6) the strictest rule applies.  Your throwaway domain might
pass, but the other advertised author's would not.

> case, policy discovery is impossible, in the latter, the strictest policy

Right, I think that's what Trent is also saying.

And everyone seems to agree on just dropping STARTTLS as well.

-MSK

---

From: Brett McDowell <[email-masked]>
Date: Sat, 8 Nov 2014 15:20:59 -0500

I support making no change in dmarc-base-05 that might change how current
mailbox providers implement dmarc-base.  But to the extent this collection
of contributors would like to see the recommendations/requirements in
section 5.6.1 updated to better harmonize with related RFC's, I support
Trent's proposal as it seems to introduce the least amount of increased
risk to fraud.

That said, we do have people here familiar with large-scale mailbox
provider deployments (Google, Yahoo!, Hotmail, etc.).  I'd like to ask them
if they expect Trent's changes to have any impact on how they implement
dmarc-base today.  If it will, I think we should consider these changes for
a future version of dmarc-base and let this version go through with these
requirements unchanged.  As you all know, there are now years of experience
deploying dmarc-base with these requirements as written.  Those deployments
have had tremendous success protecting users from domain-spoofing the
RFC5322.From field.

The importance of the current dmarc-base specification's efficacy at
blocking domain-spoofed phishing attacks should not be underestimated.  I
advise extreme caution when considering any normative changes at the 11th
hour.

Dear high volume MBP's, will any of these changes in Trent's proposal alter
how you implement dmarc-base today?

-Brett

On Sat, Nov 8, 2014 at 2:26 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> No, because in (6) the strictest rule applies.  Your throwaway domain
> might pass, but the other advertised author's would not.
>
>

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sun, 09 Nov 2014 00:00:30 +0100

On 11/08/2014 09:20 PM, Brett McDowell wrote:
> I support making no change in dmarc-base-05 that might change how 
> current mailbox providers implement dmarc-base.  But to the extent 
> this collection of contributors would like to see the 
> recommendations/requirements in section 5.6.1 updated to better 
> harmonize with related RFC's, I support Trent's proposal as it seems 
> to introduce the least amount of increased risk to fraud.
>
> provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask 
> them if they expect Trent's changes to have any impact on how they 
> implement dmarc-base today.  If it will, I think we should consider 
> these changes for a future version of dmarc-base and let this version 
> go through with these requirements unchanged.  As you all know, there 
> are now years of experience deploying dmarc-base with these 
> requirements as written.  Those deployments have had tremendous 
> success protecting users from domain-spoofing the RFC5322.From field.
>
> blocking domain-spoofed phishing attacks should not be 
> underestimated.  I advise extreme caution when considering any 
> normative changes at the 11th hour.
>
> Dear high volume MBP's, will any of these changes in Trent's proposal 
> alter how you implement dmarc-base today?

The current effort to publish DMARC as informational RFC is mainly, to 
document the current specification 'as is', to be able to refer from 
other documents to a published spec. The concerns raised by Ned and the 
proposal of Trent try to address situations, where the spec does not yet 
describe what to do (RFC5322.From with multiple addresses), or leaves 
room for different interpretations/implementations. As such I welcome 
the text proposed by Trent. If the big MBP's deviate from what that text 
describes, then in my opinion:

  * either this is part of the 'secret sauce' which is being applied by
    Mail Receivers anyway (no matter what a spec will prescribe)
  * or (better) the big MBP's will need to come up with text describing
    what their implementations will do in these specific cases.

Not changing the text, because the MBP's might have implemented these 
cases in a different way than what is being proposed here, but not 
documenting that way, is not a good idea, IMHO.

/rolf

---

From: "John Levine" <[email-masked]>
Date: 8 Nov 2014 23:10:21 -0000

>Do you have another suggestion?

I don't see how we can offer useful advice beyond noting that strange
things can happen if the message isn't 5322 compliant.  On my mail
system in the US, random headers with stray high bits are an extremely
reliable indicator of botful spamminess, while in Japan, apparently it
happens innocently all the time.

>> meeting.

If I may be direct, "our policies don't match what our users do but
it's your problem" is not exactly a new issue with DMARC.  Let's make
a deal: if you fix the mailing list problem, I'll fix this problem,
and I can probably do it for free since the plausible fixes for
mailing lists (e.g., double signing, trusted forwarders) would
probably work here, too.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Sat, 8 Nov 2014 19:29:35 -0600 (CST)

See inline....

Printed on recycled paper!

> On Nov 6, 2014, at 23:16, Murray S. Kucherawy <[email-masked]> wrote:
> 
> "small number" is "at most two", and "to the Organizational Domain" is meant to include its subdomains, so I guess what's meant is to the Organizational Domain's zone, or something like that.  I'll tidy it up.  Good suggestion on a forward reference.
> 
> No, I think you've got it, but I'm not clear on how the paragraph you cited doesn't say that.  You have it exactly right: If From: is missing or so mangled that it's not possible to get a domain out, then there's nothing to which DKIM and SPF can align, and DMARC can't be applied.  There might be other mangling though, like multiple From: fields that are properly formed but contain distinct values, in which case we don't know to which one to apply alignment.

Note that an email with no RFC 5322 field is not valid, as well as one with more than 1. This header is mandatory as well as the Date header. These are the only 2 headers mandatory in an email.

So rejecting an email with no RFC 5322 or more than one is just following the RFC.

I'm not talking on how many mailboxes/domain there are in this header.

> As I recall, there were some surveys of some pretty large email streams, and not a single instance of a From: field containing other than a single mailbox could be found that wasn't also part of something either spammy or some kind of attempt to confound spam filters, or just grossly malformed and unusable.  This led the original DMARC community to what you see there now.  There was no deliberate rejection of the RFC 6854 format, but just rather no observed valid use of it.

Note that RFC 6854 format is a "transitional" RFC. The applicability statement clearly indicates this syntax is to be used for non SMTPUTF8 aware MTA when receiving mail from an upstream MTA SMTPUTF8 aware as a convenience and under security considerations left to the receiver. So in my view if your receiving MTA does SMTPUTF8 then there is little reason to accept this syntax.

I always had a problem with RFC 6854 and opposed it in last call as it surprised me the IETF would prefer convenience for security. The result was to strongly limit the applicability of this RFC.

> What sort of remedy would you suggest here?  Off the top of my head, here are some suggestions:
> 
> 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one (by that I mean: if there are any with p=reject that fail, then reject it; if there are any with p=quarantine, quarantine it); if not, treat the message as if DMARC simply did not apply.
> 
> 3) Same as (1), but limit it to some fixed (configurable?) number of domains.

My solution is that if all the domains are part of the same organisational domain, then the task is easy, you apply the policy of the organizational domain, otherwise you reject the email.

I found .NET early version uses an invalid syntax, that creates the appearance of 2 mailboxes. If all domains are in the same organizational domain this prevent to reject a bunch of .NET generated emails.
> We've covered the latter point above, but as to the point about malformation: Can you reliably extract a domain name from a malformed From: field?  That seems to be a vector for trying to confuse a DMARC filter if the advice is to try anyway.
>  
> Section 5, third paragraph, is the first formal statement of this kind.  Adding one somewhere up earlier in one of the overview sections would probably be a good idea.
>  
>> Section 6.2.2.1 states:
>>

---

From: Franck Martin <[email-masked]>
Date: Sat, 8 Nov 2014 19:38:10 -0600 (CST)

> On Nov 8, 2014, at 15:00, Rolf E. Sonneveld <[email-masked]> wrote:
> 
>> I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base.  But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud.
>> 
>> That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.).  I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today.  If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged.  As you all know, there are now years of experience deploying dmarc-base with these requirements as written.  Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field.  
>> 
>> The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated.  I advise extreme caution when considering any normative changes at the 11th hour.
>> 
>> Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today?
> 
> The current effort to publish DMARC as informational RFC is mainly, to document the current specification 'as is', to be able to refer from other documents to a published spec. The concerns raised by Ned and the proposal of Trent try to address situations, where the spec does not yet describe what to do (RFC5322.From with multiple addresses), or leaves room for different interpretations/implementations. As such I welcome the text proposed by Trent. If the big MBP's deviate from what that text describes, then in my opinion:
> 
> either this is part of the 'secret sauce' which is being applied by Mail Receivers anyway (no matter what a spec will prescribe)
> or (better) the big MBP's will need to come up with text describing what their implementations will do in these specific cases.

There are no secret sauces. I thought it was clear this type of language on this list is frown upon as non constructive?

Several MBPs use openDMARC, less use msys-dmarc but both are opensource.

---

From: [email-masked]
Date: Fri, 07 Nov 2014 10:47:20 -0800 (PST)

Neither do I.

> whatever you do with them is out of scope for DMARC.

That's exactly my position. If you want to reject them on the basis that
the mess up user agents, you have a pathological hatred of group
syntax, or whatever, fine. Local policy choices always win.

But DMARC should not be saying that valid things should be rejected when
there's no DMARC records in sight.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 08 Nov 2014 20:26:46 -0800

>>> > >DMARC policies, apply the strictest one ...
...
> sort. My concern is the case where none of them do, or when there

Right.  I believe the phrasing of 1), above, constrains the scope of
applicability carefully and in the way that avoids the possible problems
you are (correctly, IMO) concerned about.

That is, I believe the "if any of them" text matches your "if any of
the" text...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Douglas Otis <[email-masked]>
Date: Sat, 8 Nov 2014 23:58:00 -0800

>> No, I think you've got it, but I'm not clear on how the paragraph you cited doesn't say that.  You have it exactly right: If From: is missing or so mangled that it's not possible to get a domain o…

Dear Franck,

> So rejecting an email with no RFC 5322 or more than one is just following the RFC.

Which normative RFC is that?

> 
> I'm not talking on how many mailboxes/domain there are in this header

It would be wrong to assume SMTP will reject messages based on possible RFC5322 violations.  Also efforts to change the From header field into alignment with DKIM or SPF violates RFC 5322 as well.  In addition, use of DKIM and DMARC alignment to reject phishing attacks can not safely rely on DKIM signatures being considered invalid when multiple From header fields exist.  This makes the strategy suggested in RFC6376 Section 8.15 dependent on all domains being checked for DMARC policy.  Because of this flaw in DKIM signature validation, it becomes necessary to apply DMARC policy checks against each and every originating domain.  It would be incorrect to expect Authentication-Results headers will indicate a failure in the case of invalid originating header fields.  The domain being checked for DMARC MUST NOT depend on Authentication-Results headers, OR assume SMTP or DKIM validation rejects such messages since there is no RFC language to impose message rejection or a DMARC policy failure.  DMARC now suggests making this difficult check with an ought. It seems rather dubious to trust DKIM signatures and that DMARC offers a safe and reliable policy enforcement. 

Also consider that it took several years for Yahoo to notice exploits allowed by multiple From header Fields.

Per RFC 5322:
    Also in Section 3.6.2: In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.

Per RFC 5321:
   When the RFC 822 format ([28], [4]) is being used, the mail data
   include the header fields such as those named Date, Subject, To, Cc,
   and From.  Server SMTP systems SHOULD NOT reject messages based on
   perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
   header section or message body.  In particular, they MUST NOT reject
   messages in which the numbers of Resent-header fields do not match or
   Resent-to appears without Resent-from and/or Resent-date.

Even the dmarc-base draft Section 4 and Section 10 removed rejection of invalid
From header fields:
   The absence of a single, properly-formed RFC5322.From field renders 
   the message invalid. This document prescribes no specific action in
   that case, other than to suggest that the message ought to be disposed
   of by the Mail Receiver's infrastructure in a safe manner that
   recognizes and possibly even highlights the malformation.

So it is perfectly valid to indicate a DKIM pass with multiple From header fields, and now ignore this situation with DMARC as well.

Do you see the problem with the assumption you made?  Heck, the DKIM deploy RFC even suggests subsequent checks can be bypassed when a valid DKIM signature is found from a trusted domain.

Regards,
Douglas Otis

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Nov 2014 03:19:02 -0600 (CST)

----- Original Message -----
> From: "Douglas Otis" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: "Ned Freed" <[email-masked]>, [email-masked], "Murray S. Kucherawy" <[email-masked]>, "Douglas Otis"
> <[email-masked]>
> Sent: Saturday, November 8, 2014 11:58:00 PM
> Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
> 
> 
> >> No, I think you've got it, but I'm not clear on how the paragraph you
> >> cited doesn't say that.  You have it exactly right: If From: is missing
> >> or so mangled that it's not possible to get a domain out, then there's
> >> nothing to which DKIM and SPF can align, and DMARC can't be applied.
> >> There might be other mangling though, like multiple From: fields that
> >> are properly formed but contain distinct values, in which case we don't
> >> know to which one to apply alignment.
> 
> Dear Franck,
> 
> > Note that an email with no RFC 5322 field is not valid, as well as one with
> > more than 1. This header is mandatory as well as the Date header. These
> > are the only 2 headers mandatory in an email.
> > 

see table under http://tools.ietf.org/html/rfc5322#section-3.6

> It would be wrong to assume SMTP will reject messages based on possible
> RFC5322 violations.  

While SMTP implementations have been lenient, they have been lenient in a way which is contrary to this RFC. The Postel statement indicates to be lenient when there is protocol ambiguity, not to allow anything but the kitchen sink when the protocol is clear about what headers must be present.

Therefore it is not wrong to assume SMTP will reject messages on protocol violations.

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Nov 2014 03:26:27 -0600 (CST)

----- Original Message -----
> From: [email-masked]
> To: "John Levine" <[email-masked]>
> Cc: [email-masked], [email-masked]
> Sent: Friday, November 7, 2014 10:47:20 AM

With IPv6 and openPGP or S/Mime it will become more and more prevalent to block emails based on the domain(s) present in the RFC5322.From.

Are the domains, domains that exist? Are they emailable? are they present in blocking lists?
When there are none, my eight ball tells me the preferred behavior will be to reject such emails...

These are also a set of easy techniques to avoid that DMARC be by-passed.

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Nov 2014 03:31:31 -0600 (CST)

----- Original Message -----
> > DMARC result needs to change.

Conclusion, a DMARC enabled MTA MUST be SMTPUTF8 enabled (so there is no to little reasons to downgrade).

---

From: Douglas Otis <[email-masked]>
Date: Sun, 9 Nov 2014 03:01:10 -0800

Dear Franck,

This table defines a message format accompanied with an SMTP caution not to reject messages based on perceived structural errors.  Prior to DKIM creating a security hole in its mandated From header field signing, repeated From header fields often simply resulted from poorly automated responses.  Since such errors directly affect DKIM's protection of header fields, DKIM should considered such messages as having invalid signatures.  This would allow subsequent processes an ability to use results headers without re-examining message structure, nor does such overlooked checks appear in the Authentication results header field. 

> While SMTP implementations have been lenient, they have been lenient in a way which is contrary to this RFC.

It is not contrary.  SMTP is a store and forward protocol exchanging messages over MTAs having changed little over decades.  There is no practical way to negotiate format changes, such as those created by RFC 6854 for example.  For SMTP to evolve, some change must be allowed.  Where the change is known to place the integrity of DKIM signatures at risk, the signatures should not have been considered valid.  Although a simple configuration switch offers a low overhead solution, ignoring this change was a deliberate choice made by DKIM.

> The Postel statement indicates to be lenient when there is protocol ambiguity, not to allow anything but the kitchen sink when the protocol is clear about what headers must be present.

Why not fix the problem in the algorithm walking the header field stack from the bottom up during signature validation?  It makes little since to now say all such errors should be rejected.

> Therefore it is not wrong to assume SMTP will reject messages on protocol violations.

It is a protocol violation to reject messages because of some perceived error.  It would not be a protocol violation to assert a DKIM signature is invalid.  With that change, Authentication results headers could be trusted without subsequent processing.  Why expect recipients to process messages a second time?  Get it right the first time, especially where doing so is only a software switch in most cases.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Sun, 09 Nov 2014 08:02:01 -0500

> I'm not talking on how many mailboxes/domain there are in this header.

+1

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 09 Nov 2014 08:02:39 -0500

+1

-- 
HLS

---

From: Tim Draegen <[email-masked]>
Date: Sun, 9 Nov 2014 10:03:04 -0500

> On Nov 8, 2014, at 8:38 PM, Franck Martin <[email-masked]> wrote:
> 

Just a point of clarification here.  The original author was referring to decisions that receivers make when processing email.  "Secret sauce" is often shorthand for the local conditions that exist at a receiver (eg input from local user behavior, site specific content scanning, etc).

No foul here.  Play on!

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 09 Nov 2014 09:21:21 +0900

Trimming the CC list, as we're getting into spam-trap numbers of
mailboxes.

Rolf E. Sonneveld writes:

 > room for different interpretations/implementations.

I don't think that is the case here; the current spec says what to do
(reject them).  My problem is with the current rationale.  I think it
is somewhat bogus, and goes beyond DMARC's remit (it says to reject
any message with multiple addresses in From, rather than rejecting on
the basis of policy corresponding to Authenticated Identifiers).

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 09 Nov 2014 12:43:08 -0500

>no to little reasons to downgrade).

In that case, DMARC ought to be deferred for several years. I don't think you really mean that. 

Scott K

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Nov 2014 18:14:37 +0000

> On Nov 9, 2014, at 09:43, Scott Kitterman <[email-masked]> wrote:
> 
I'll settle for a SHOULD ;)

Seriously, it is important to strengthen your MTA (and be less permissive), if you don't want some forms of unwanted emails to work easily around DMARC.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sun, 09 Nov 2014 19:27:37 +0100

> Just a point of clarification here.  The original author was referring to decisions that receivers make when processing email.  "Secret sauce" is often shorthand for the local conditions that exist…

thanks, Tim.

Frank, this was exactly the meaning of 'secret sauce' I had in mind, 
like it has been used in the past, see for example [1] and [2]. From [2]:

    Obviously, in computing reputations via traffic analysis, some
    private algorithms may come into play.  For some RSPs, such "secret
    sauce" comprises their competitive advantage over others in the same
    space.

Although this is said in the context of reputation, a similar meaning 
can apply to the internal decision making process within MBP's/ESP's 
when dealing with the results of e.g. SPF verification or DMARC 
verification.

Having said that, it's still interesting to learn (if you want to share 
that) what LinkedIn does in situations where there are e.g. multiple 
addresses in a From field.

/rolf

[1] http://lists.opendkim.org/archive/opendkim/users/2011/06/1143.html
[2] https://tools.ietf.org/html/draft-ietf-repute-considerations-03

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Nov 2014 18:36:07 +0000

> On Nov 9, 2014, at 10:27, Rolf E. Sonneveld <[email-masked]> wrote:
> 
> Frank, this was exactly the meaning of 'secret sauce' I had in mind, like it has been used in the past, see for example [1] and [2]. From [2]:
> 
> Although this is said in the context of reputation, a similar meaning can apply to the internal decision making process within MBP's/ESP's when dealing with the results of e.g. SPF verification or DMARC verification.
> 
> Having said that, it's still interesting to learn (if you want to share that) what LinkedIn does in situations where there are e.g. multiple addresses in a From field

No secret sauce here cf https://github.com/linkedin/dmarc-msys/blob/master/dmarc.lua#L815

;)

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sun, 09 Nov 2014 19:44:11 +0100

On 11/08/2014 01:40 AM, J. Trent Adams wrote:

[...]

>         discovered DMARC policies.

We would like to apply the most strict policy, but doesn't that conflict 
with the p=none policy, where Domain Owners can start gathering reports 
without having to bother about impact on the disposition of their mail? 
Furthermore, doesn't a 'most strict' conflict with the meaning of the 
pct tag:

> The purpose of
> the "pct" tag is to allow Domain Owners to enact a slow rollout
> enforcement of the DMARC mechanism. The prospect of "all or
> nothing" is recognized as preventing many organizations from
> experimenting with strong authentication-based mechanisms.

Treating the mail with the most strict policy for a From field with two 
addresses, where one of them has p=reject and the other p=none, may have 
the result that p=reject is applied for mail from the domain which has 
policy=none. Or am I missing something?

/rolf

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Nov 2014 12:51:45 -0600 (CST)

> Having said that, it's still interesting to learn (if you want to share that) what LinkedIn does in situations where there are e.g. multiple addresses in a From field.

:P

(Resent from a more suitable email address)

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 09 Nov 2014 14:58:19 -0500

>policy=none. Or am I missing something?

Sure. OTOH, picking anything other than the strongest policy makes for a trivially implemented bypass of DMARC checks.

Given this is a rare corner case, I think it's better to lean towards strictness than leniency. 

Scott K

---

From: Brett McDowell <[email-masked]>
Date: Sun, 9 Nov 2014 15:30:31 -0500

On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman <[email-masked]>
wrote:

> Sure. OTOH, picking anything other than the strongest policy makes for a
> trivially implemented bypass of DMARC checks.
>
+1

---

From: Franck Martin <[email-masked]>
Date: Sun, 9 Nov 2014 15:15:01 -0600 (CST)

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

> From: "Brett McDowell" <[email-masked]>
> To: "Scott Kitterman" <[email-masked]>
> Cc: [email-masked]
> Sent: Sunday, November 9, 2014 12:30:31 PM

> On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman < [email-masked] >
> wrote:

> > >We would like to apply the most strict policy, but doesn't that
> 
> > >conflict
> 
> > >addresses, where one of them has p=reject and the other p=none, may
> 
> > >have
> 

>From the code I gave, I ran for several weeks my system in logging mode to record the RFC5322.From when it had zero or more than one mailbox. This is what I found: 

A bug at a major mailbox provider that was not rendering a variable correctly (no domain in From) 
A bug with a common dot NET version that would do a From like this (If I recall correctly): From: [email-masked] <[email-masked]> (the first email address is meant to be double quoted) 
All the rest were bounces (NDM) with stuff like From: postmaster@local or From: [email-masked], postmaster@localhost,... In short non configured machines, some doing backscatter, some not... NDM are getting rarer nowadays by the way. 
Did not find (probability close to 0 but non null) a single email with 2 email addresses in the From that is meant to an end user. 

I wish the mailbox-list syntax in the From would be deprecated for the mailbox syntax, but it is unlikely to happen, may be when RFC5322 gets revised (under Security, end to end, IPv6 experience), but from an operational point of view (if you want ops to come back to IETF, listen to them :P ) you don't loose any useful email if you reject emails with multiple mailboxes in the From.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 10 Nov 2014 18:22:24 +0900

Franck Martin writes:

 > I wish the mailbox-list syntax in the From would be deprecated for
 > the mailbox syntax, but it is unlikely to happen, may be when
 > RFC5322 gets revised (under Security, end to end, IPv6 experience),

I don't understand why any of those experiences would cause RFC 5322
to be revised in this way.  The problem is not in the protocol used to
implement the network, but rather in the structure of the network of
people involved.  Most email networks-of-people don't involve a use
case for multiple mailboxes in From, but some do (see below).  OTOH,
if you really need to pin responsibility for message origination on a
particular person, the Sender field is the appropriate field.

Even in the case of DMARC, as far as I can tell, for the intended use
case of transactional mail there is little problem with throwing From-
with-multiple-mailboxes into the "unauthenticable" pool, and rejecting
on that basis if you want to.  I see no reason to disallow this useful
feature in RFC 5322 when it is better done in DMARC, or perhaps in the
lower level protocols.

 > but from an operational point of view (if you want ops to come back
 > to IETF, listen to them :P ) you don't loose any useful email if
 > you reject emails with multiple mailboxes in the From.

Please take more care with your pronouns.  I am not a member of your
"you".

I know for a fact that if every MTA rejects because of multiple
mailboxes in From, mail I consider important will not be delivered.
I know and consider it important because I write it on behalf of an
anti-harassment committee, and it's important that the members be
individually identified[1] and individually reply-able[2].  There
are other ways to accomplish these goals simultaneously, but using
multiple mailboxes in From is all of most economical, most intuitive,
and most beautiful.  (I occasionally do it in other cases, but this
case is special because it is of true utility to the recipients.)

Given that you say this practice is rare and mostly harmless in your
own experience, I don't see that the costs of treating such messages
as an unauthenticated are high.

Also, your experience is probably far less generic than you think, if
it's based on LinkedIn.  LinkedIn is a social network based not on
groups but on individual links (although it provides groups, IME they
are not entities in themselves in the way that bureaucratic committees
are, but rather aliases for a "me-to-many" set of bilateral links
based on common interest rather than individual identity).  It is no
surprise to me that the vast majority of messaging at LinkedIn is
related to *one*-to-one or *one*-to-many communications.  The reverse
relationship ("many-to-you") is more likely in a bureaucratic context
(and certainly is useful for me personally).

If you *aren't* speaking of LinkedIn, or that's not a correct
analysis of how LinkedIn works, feel free to enlighten us.

Footnotes: 
[1]  We have ex oficio personal responsibilities to maintain student
privacy that are actually a special exception to the normal faculty-
administration relationship.

[2]  Not a group address -- it's not unheard of for bad actors to end
up on such committees, although not in my tenure, thank heaven.

---

From: Franck Martin <[email-masked]>
Date: Mon, 10 Nov 2014 04:00:14 -0600 (CST)

> On Nov 9, 2014, at 23:22, Stephen J. Turnbull <[email-masked]> wrote:
> 
> Franck Martin writes:
> 

The part missing was end to end encryption where I heard that it could be conceivable that the entire DATA part be encrypted (headers+body). The only info the MTA would have is the envelope. This would require a somehow update/rewrite of RFC5322, but we are not there.

Ps: Please don't summarize my experience to Linkedin, I had many other lives before that.

---

From: [email-masked]
Date: Sat, 8 Nov 2014 16:50:48 +0900 (JST)

[Excuse my broken mail system; until the tech staff return on Monday, it
looks like I'm stuck with a webmail interface where I can't change my From
to the subscribed address or break lines properly etc.]

> Do you have another suggestion?

Remove the words "with a message that is not valid per RFC 5322 [MAIL]. 
This is particularly true", and add a comment to the effect of "other
kinds of invalid message should be viewed with extreme suspicion in the
DMARC context, because MTAs and MUAs will not necessarily be prepared for
them and 'anything can happen'" to the Security Considerations.  Or just
leave that comment for the BCP.

> Note that there's nothing normative in Trent's suggestion.

Understood, I just think it's factually inaccurate.

> pass, but the other advertised author's would not.

I think my interpretation of Trent's words "If one or more of the
Authenticated Identifiers aligns with an identifier extracted" is
plausible, though: in that case we don't get to the policy application
(6).  My understanding is that policy is only applied when the DMARC
alignment *fails* for a domain publishing a policy.

> Right, I think that's what Trent is also saying.

Probably, but I don't think my reading is implausible.

Regards,

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 11 Nov 2014 04:05:23 +0900

> Ps: Please don't summarize my experience to Linkedin, I had many

I have no choice but to make assumptions about the context in which
you collected your data, since you didn't describe it, and the data
collection context is required to assess the bias in your results.

---

From: Franck Martin <[email-masked]>
Date: Mon, 10 Nov 2014 13:23:23 -0600 (CST)

----- Original Message -----
> From: "Stephen J. Turnbull" <[email-masked]>
> Cc: "Brett McDowell" <[email-masked]>, [email-masked], "Scott Kitterman" <[email-masked]>
> Sent: Monday, November 10, 2014 11:05:23 AM

Fair enough, in the 20 years I do email (starting with uucp), I don't recall any such email where multiple email addresses where in the From: on purpose.

So I'm curious to see some real world examples. If you could add them in the wiki may be?

---

From: Brandon Long <[email-masked]>
Date: Mon, 10 Nov 2014 15:50:04 -0800

I don't think his changes in 5.6.1 would change anything we do.  We
currently require a single From header with a single address with a valid
domain on all messages (not restricted to DMARC).  RFC 6854 as used for EAI
downgrades shouldn't apply since we support SMTPUTF8... though, if it
became popular enough that we saw a large amount of mail forwarding in that
format, we would adjust.

I would think that how shipped software handles such things would be more
likely to have issues, as its less likely to be upgraded.

That said, from my understanding, this is a loosening of restrictions, from
"only one" to "may allow more than one", so that doesn't seem particularly
problematic.

Would we support multiple addresses?  Probably not.  We've had the current
restrictions for 2+ years, and before that had less strict but similar
restrictions.  I haven't seen any complaints to date about this
restriction, but it does apply to a non-trivial amount of mail.

Brandon

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 11 Nov 2014 16:33:23 +0900

> So I'm curious to see some real world examples. If you could add

(a) Of the ones I have ready access to, there are privacy concerns
    with the email itself in many cases, and employer issues with all
    of them (Japanese institutions don't like to admit they even
    *might* have any problems in public).
(b) They're in Japanese.

So, no, not from my archives there won't be.  I'll post the
description of the use case and an example, though.

I can tell you that in my "truly useful" case all addresses are "work
addresses", and therefore all have the same domain and *could* satisfy
the DMARC mechanism in the sense that the authenticated domain would
be aligned with all addresses in From, like this:

    DKIM-Signature: ..., d=xemacs.org, ...
    From: "Stephen J. Turnbull" <[email-masked]>,
          "Another Steve" <[email-masked]>

I wouldn't be surprised if that handles the majority of such cases.

I have sent mail "frivolously" with multiple domains in From, like
this:

    DKIM-Signature: ..., d=xemacs.org, ...
    From: "Stephen J. Turnbull" <[email-masked]>,
          "My Co-Presenter" <[email-masked]>
    Subject: Come see our presentation at Tokyo Linux Users Group

but I don't seem to have a copy of that immediately available.

Steve

---

From: Brett McDowell <[email-masked]>
Date: Wed, 12 Nov 2014 14:38:09 -0500

On Mon, Nov 10, 2014 at 6:50 PM, Brandon Long <[email-masked]> wrote:

> That said, from my understanding, this is a loosening of restrictions,
> from "only one" to "may allow more than one", so that doesn't seem
> particularly problematic.
>

Thank you Brandon for replying with your perspective on Trent's proposed
changes to 5.6.1.