Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Murray S. Kucherawy]

On Thu, Apr 2, 2015 at 6:25 PM, John R Levine  wrote:

> So receipt of a message signed in the new form will likely produce an
>> incorrect signature validation, ...
>>
>
> I wondered about that, too, so before I proposed a version bump, I took a
> look at the code that people use:
>
> * Murray's opendkim C library: checks that the version is 0.5 or 1, fails
> otherwise.  That's the code in the milters that sendmail and postfix use,
> and I believe it's the library that everyone else with custom C code
> (including me) uses or adapts.  It replaces the older libdkim.
>

It won't accept 0.5 unless configured to do so, and that's off by default.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[John R Levine]

So receipt of a message signed in the new form will likely produce an
incorrect signature validation, ...


I wondered about that, too, so before I proposed a version bump, I took a 
look at the code that people use:


* Murray's opendkim C library: checks that the version is 0.5 or 1, 
fails otherwise.  That's the code in the milters that sendmail and postfix 
use, and I believe it's the library that everyone else with custom C code 
(including me) uses or adapts.  It replaces the older libdkim.


* Jason Long's perl Mail::DKIM: checks that the version is 0.5 or 1, will 
accept no v= at all for backward compatibility with DK but not other v= 
values.  This is what spamassassin uses.


* Scott K's dkimpy: checks that the version is 0.5 or 1.

A version bump appears unlikely to produce an incorrect signature 
validation unless there are other libraries in active use that ignored the 
spec that says to check the version number.


I suppose I could try sending v=2 signatures to my Yahoo and Gmail and 
Hotmail accounts to see what their trace headers say, but I'd be pretty 
surprised if they got it wrong.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Dave Crocker]

On 4/1/2015 8:22 PM, John Levine wrote:
>  DKIM-Signature: v=2; d=example.com; ...
>  DaveKIM-Signature: v=1; d=example.com; ...
> 
> In this particular case, the incompatibility is a new kind of "must
> handle" tag suggested by Ned Freed with the new rule that if a
> verifier doesn't understand it, the verification fails. 


This handling of unrecognized tags is another change from existing DKIM:

 "3.6.1. Textual Representation
  ...
  The
  current valid tags are described below.  Other tags MAY be present
  and MUST be ignored by any implementation that does not understand
  them."

So receipt of a message signed in the new form will likely produce an
incorrect signature validation, since

   (1) the new tag's semantics won't be applied and

   (2) the new rule for unrecognized tags won't be applied.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[ned+dmarc]

> >In the latter case, it's really an entirely new protocol, which should
> >be identified by the next-lower protocol, rather than by using the
> >version field as an in-bred demultiplexing field.

> I suppose, but if the two procols are 99% the same, and the new one is
> upward compatible with the old one, and anything that understands the
> new one also has to understand the old one, and the goal is to have
> everything puts semantics on the old one put the same semantics on the
> new one, I'm having trouble seeing why one of these is vastly
> preferable to the other:

>  DKIM-Signature: v=2; d=example.com; ...
>  DaveKIM-Signature: v=1; d=example.com; ...

Without getting into the desirability/utility of any sort of v2, I'll note that
the latter of these has one small advantage: It avoids any issues with broken
DKIM handlers that fail to correctly interpret the v= field.

Having said that, I think the version bump approach is a pretty significant
aesthetic win, especially if the change is, as noted below, to implement the
"must handle" tag.

And aesthetics in protocols do matter to some extent.

Ned

> In this particular case, the incompatibility is a new kind of "must
> handle" tag suggested by Ned Freed with the new rule that if a
> verifier doesn't understand it, the verification fails.  The first of
> them would be must-re-sign, which means that the message has to be
> re-signed by another domain, e.g.:

>  DKIM-Signature: v=2; d=yahoo.com; @mr=ietf.org; ...

> which would say this signature is only good if there is also a DKIM
> signature with d=ietf.org.  You could chain these things which might
> deal with the educational forwarding issue that Elizabeth Z. described.

> Once you have the syntax for must handle tags (I used @ here) then we
> can add more of them as needed without another version bump.

> R's,
> John

> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Stephen J. Turnbull]

Murray S. Kucherawy writes:
 > On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett  wrote:

 > > Right, but if that tag were explicitly deemed to be excluded
 > > from the signature, it could be handled differently.  Hmm, but
 > > if this resulted in (for example) the tag not being displayed,
 > > then we would have gained nothing in the case of mailing lists.
 > >
 > 
 > Handled by whom?  If we're talking about telling MUAs "Don't render the
 > unsigned part of the content the same way as the signed content", then a
 > bunch of additional complexities begin to appear:

How about substituting s/U/T/?  Unpacking that rather obscure
expression, if you have a well-defined protocol (as opposed to, say,
the quoting convention for replies :-), the M*T*A (or spam-fighting
milter) could remove the parts signed only by 3rd parties, and add a
message/rfc822 subpart of the whole original message as an attachment
which the reader *could* look at, if they want to, in most M*U*As.
Really paranoid sites like A** and Y! could just remove on
receipt.

 > - We're wandering into conversations about how MUAs should interact
 >   with users, which this community typically avoids like a terrible
 >   allergy

Note that although this does rely on the MUA to havec certain
capabilities, most MUAs *do* have them, and I hope that users will
accept the inconvenience because they get the original message without
the third-party decorations.

I suspect this line of thought is beneficial only to MLs,
unfortunately.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Douglas Otis]

> On Apr 2, 2015, at 11:08 AM, John Levine  wrote:
> 
>> Handled by whom?  If we're talking about telling MUAs "Don't render the
>> unsigned part of the content the same way as the signed content", then a
>> bunch of additional complexities begin to appear:
> 
> We went over all of this ages ago when DKIM was young.  It should all be
> in the DKIM WG archives.
> 
>> - We're wandering into conversations about how MUAs should interact with
>> users, which this community typically avoids like a terrible allergy
> 
> No kidding.  I see no reason to expect that mail recipients would do
> anything useful with differently colored parts of the message.
> Punting security decisions to users usually seems to train the users
> to push whatever button makes the warning go away.
> 
> Also, when we went down this rathole before, we noted that MIME
> provides an enormous range of ways to make both malicious and benign
> changes to a message body, and l= doesn't begin to scratch the mites
> on the dust on the surface.

Dear John,

The goal is to prevent recipients from seeing non-aligned Froms signifying a 
domain seeking DMARC protection.  This may significantly affect third-partys 
causing DMARC alignment failures.  In such cases, a remedy likely requires 
modification of From domains.

The TPA-Label scheme envisioned a DMARC extension to assert domains seeking 
protection will separately authorize various third-partys confirmed by various 
methods.   It is now clear, ESPs (ab)using DMARC have no interest in managing 
exceptions, with their lack of interest likely remaining true when expecting 
them to add provisions for the destinations of their user's messages. 

I'll attempt to put together an I-D that includes provisions for supporting 
both mailing-lists and SMTP gateways without changing DKIM or SPF, or expecting 
ESP cooperation.  The work is to be done by those affected by DMARC and not 
rightfully the (ab)using ESP, acquiescing to the view might makes right.

Regards,
Douglas Otis


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Terry Zink]

What sorts of things do you want to see in an MUA?

- Gmail says, of messages in the spam folder, “This message is here because 
others marked it as spam.”
- If you enable it in Gmail, they also put a key beside authenticated messages
- Outlook.com/Hotmail has a Green Shield in the List view next to messages that 
are on the Green Shield list (large brand susceptible to spoofing, manually 
maintained) and pass authentication
- Outlook desktop says “This message was marked as spam by a filter other than 
the Outlook junk client”
- Outlook desktop also disables Links, Reply, Reply All, and Attachments for 
messages in Junk, and any message marked as Phish regardless of whether or not 
it is in the inbox

Within Microsoft, we’re looking at how to include some of the things in 
outlook.com/Hotmail into Outlook and how best to integrate safety into the 
overall user experience in mail clients Microsoft controls. While traditionally 
there hasn’t been a lot of MTA-to-MUA communication (other than Exchange and 
Outlook), that doesn’t need to be the case going forward.

-- Terry

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 2, 2015 12:52 PM
To: 
Cc: dmarc@ietf.org; Anne Bennett
Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld 
mailto:r.e.sonnev...@sonnection.nl>> wrote:
if DMARC is really the succes that dmarc.org claims it is [1] 
and with so many of the big ESPs around here [2] I fail to see why it would be 
so difficult to involve the MUA developers of these same ESPs?

Several of them are here.  If they have better experience understanding what 
actually gets through to users in terms of message safety that doesn't reduce 
to, as John Levine put it, "Where do I click to make this warning go away?", 
they have yet to say so.  :-)
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Dave Crocker]

On 4/2/2015 11:42 AM, Murray S. Kucherawy wrote:
> On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker  > wrote:
> If the input is "the message" and the output is "a set of zero or more
> SDIDs representing domains whose signatures validated", then I don't

Except that that does not describe the DKIM protocol.

A protocol is not (necessarily) and input/output engine.  It is an
interaction engine that delivers things.

DKIM delivers a single validated identifier.

With respect to the specific DKIM function, the message is overhead, not
payload.  It is part of what service to enable the payload, not be part
of it.



> However, and perhaps unfortunately, RFC5672 changed it so that the
> output of DKIM is a single SDID. 

Sorry, no.  It wasn't changed, although the precise spec language did
change.

RFC 478:

 "permitting a signing domain
   to claim responsibility for the introduction of a message into the
   mail stream. "


RFC 6376:

 "DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name [RFC1034] with the message [RFC5322], which
   they are authorized to use."

In both cases, it refers to a single domain name.  Not multiple.

If you want to validate multiple domain names, you do multiple
(independent) signatures.

The substantive change was to clarify an ambiguity in the original spec,
about /which/ of the two possible domain names that are in the
DKIM-Signature field constitutes the promised one.


> That means either (a) RFC5672 got it
> wrong, because this doesn't allow for the whole message to be the input

huh?


> and multiple domain names (for passing signatures) to be the output, or
> (b) the above definition is wrong, because it means a single DKIM
> signature _plus_ the whole message is the input, and the algorithm picks
> apart the message as needed to complete the verification and thus
> produce the single SDID (or an error).

Or (c) the whole message isn't part of DKIM payload.

 The answer is (c).



> OpenDKIM certainly implements the first definition I've used above at
> its API level, though I could argue that it satisfies either of the two
> definitions and just happens to do the latter one in a parallel way.

I suspect what you've just said is that OpenDKIM can process multiple
signatures and deliver a list of validated domain names.

This is one more demonstration of the difference between a protocol and
an API...

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Murray S. Kucherawy]

On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld <
r.e.sonnev...@sonnection.nl> wrote:

> if DMARC is really the succes that dmarc.org claims it is [1] and with so
> many of the big ESPs around here [2] I fail to see why it would be so
> difficult to involve the MUA developers of these same ESPs?
>

Several of them are here.  If they have better experience understanding
what actually gets through to users in terms of message safety that doesn't
reduce to, as John Levine put it, "Where do I click to make this warning go
away?", they have yet to say so.  :-)

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Rolf E. Sonneveld]

On 04/02/2015 07:59 PM, Murray S. Kucherawy wrote:
On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett > wrote:


> As I recall this was considered during the development of DKIM originally,
> exactly for this reason.  We rejected it because we couldn't
come up with a
> safe description of what a tag should look like. If arbitrary
text is
> allowed in there, then one could "tag" a spam URL at the front of a
> legitimate message's Subject field and the signature would still
pass.

Right, but if that tag were explicitly deemed to be excluded
from the signature, it could be handled differently.  Hmm, but
if this resulted in (for example) the tag not being displayed,
then we would have gained nothing in the case of mailing lists.


Handled by whom?  If we're talking about telling MUAs "Don't render 
the unsigned part of the content the same way as the signed content", 
then a bunch of additional complexities begin to appear:


- MUAs now need to know how to do DKIM themselves, so that they know 
what parts were signed and what parts were not; alternatively, we need 
a way to signal between the DKIM verifier and the MUA what parts are 
safe to render, beyond what Authentication-Results already provides


- We're wandering into conversations about how MUAs should interact 
with users, which this community typically avoids like a terrible allergy


- Even if the above aren't problems, we're relying on MUAs to adapt to 
this change in a relatively short period of time


Here be dragons.


if DMARC is really the succes that dmarc.org claims it is [1] and with 
so many of the big ESPs around here [2] I fail to see why it would be so 
difficult to involve the MUA developers of these same ESPs?


/rolf

P.S. I only noticed today the significant organizational change of 
dmarc.org [3] and the fact that this 'new' dmarc.org has only two 
founding sponsors.


[1] 
http://dmarc.org/2015/02/dmarc-is-a-proven-tool-in-the-fight-against-fraudulent-email/

[2] http://dmarc.org/about/history/
[3] http://dmarc.org/about/

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Murray S. Kucherawy]

On Thu, Apr 2, 2015 at 11:42 AM, Murray S. Kucherawy 
wrote:

> If the input is "the message" and the output is "a set of zero or more
> SDIDs representing domains whose signatures validated", then I don't think
> it matters if we go the "v=2" route or the "new header field name" route,
> because the multiplexing happens on the inside of the processing machine
> thus described.
>

As I read RFC6376 sections 3.8 and 3.9, this is a valid perspective.  (I
may be biased.)

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Murray S. Kucherawy]

On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker  wrote:

> > The main difference I see is that if we call v2 something else, we now
> > have a tedious administrative exercise of finding every place something
> > refers to DKIM and change it to "DKIM or DKIM-plus."  This does not
> > strike me as a good use of anyone's time.
>
> That task you characterize as tedious is, in fact, the discipline of
> making sure the documentation is careful to distinguish between the two
> different (ie, non-interoperable) protocols.
>
> Efforts to do that with a single specification wind up confusing things
> and confusing readers and implementers.


I'm using API terminology here but I think the comment generalizes to the
protocol:

If the input is "the message" and the output is "a set of zero or more
SDIDs representing domains whose signatures validated", then I don't think
it matters if we go the "v=2" route or the "new header field name" route,
because the multiplexing happens on the inside of the processing machine
thus described.

However, and perhaps unfortunately, RFC5672 changed it so that the output
of DKIM is a single SDID.  That means either (a) RFC5672 got it wrong,
because this doesn't allow for the whole message to be the input and
multiple domain names (for passing signatures) to be the output, or (b) the
above definition is wrong, because it means a single DKIM signature _plus_
the whole message is the input, and the algorithm picks apart the message
as needed to complete the verification and thus produce the single SDID (or
an error).

OpenDKIM certainly implements the first definition I've used above at its
API level, though I could argue that it satisfies either of the two
definitions and just happens to do the latter one in a parallel way.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[John Levine]

>Handled by whom?  If we're talking about telling MUAs "Don't render the
>unsigned part of the content the same way as the signed content", then a
>bunch of additional complexities begin to appear:

We went over all of this ages ago when DKIM was young.  It should all be
in the DKIM WG archives.

>- We're wandering into conversations about how MUAs should interact with
>users, which this community typically avoids like a terrible allergy

No kidding.  I see no reason to expect that mail recipients would do
anything useful with differently colored parts of the message.
Punting security decisions to users usually seems to train the users
to push whatever button makes the warning go away.

Also, when we went down this rathole before, we noted that MIME
provides an enormous range of ways to make both malicious and benign
changes to a message body, and l= doesn't begin to scratch the mites
on the dust on the surface.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Murray S. Kucherawy]

On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett  wrote:

> > As I recall this was considered during the development of DKIM
> originally,
> > exactly for this reason.  We rejected it because we couldn't come up
> with a
> > safe description of what a tag should look like.  If arbitrary text is
> > allowed in there, then one could "tag" a spam URL at the front of a
> > legitimate message's Subject field and the signature would still pass.
>
> Right, but if that tag were explicitly deemed to be excluded
> from the signature, it could be handled differently.  Hmm, but
> if this resulted in (for example) the tag not being displayed,
> then we would have gained nothing in the case of mailing lists.
>

Handled by whom?  If we're talking about telling MUAs "Don't render the
unsigned part of the content the same way as the signed content", then a
bunch of additional complexities begin to appear:

- MUAs now need to know how to do DKIM themselves, so that they know what
parts were signed and what parts were not; alternatively, we need a way to
signal between the DKIM verifier and the MUA what parts are safe to render,
beyond what Authentication-Results already provides

- We're wandering into conversations about how MUAs should interact with
users, which this community typically avoids like a terrible allergy

- Even if the above aren't problems, we're relying on MUAs to adapt to this
change in a relatively short period of time

Here be dragons.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Dave Crocker]

On 4/2/2015 9:02 AM, John R Levine wrote:
>> That is, the 'payload' of DKIM is the delivery of a validated domain
>> name.  In the original specification, we failed to properly specify
>> which of the two delivered identifiers (d= and s=) was that promised
>> payload.
> 
> These hairs are split too finely for me to understand.  

You mean like the difference between a driver and a passenger?

Really, there's nothing subtle or fine about it.  In fact is a clean and
essential distinction, if the protocol is to be cleanly defined.

In classic networking architecture hierarchies, an exchange is
characterized by defining provider and a consumer.  The former wants to
supply some information to the latter.  That information is the payload.
 They use a protocol to do that.  The protocol is a set of rules and
formats for effecting that transfer of the payload.  Any part of the
protocol that is not payload is overhead.


> The DKIM
> validator takes the message and the not-API returns a possibly empty
> list of identifiers.  In v2 or whatever we call it, the validator does
> exactly the same thing.

Ahh, I see.  American English and British English and Malaysian English
are all identical, since they satisfy the same, generic functional
description.  For that matter, English and Russian are the same because
the do too.

Again:  The required semantics differ and...  The Protocols Do Not
Interoperate.

To make this fundamental point irrelevant, one of us first needs to be
able to mate with an orang utan.


> The main difference I see is that if we call v2 something else, we now
> have a tedious administrative exercise of finding every place something
> refers to DKIM and change it to "DKIM or DKIM-plus."  This does not
> strike me as a good use of anyone's time.

That task you characterize as tedious is, in fact, the discipline of
making sure the documentation is careful to distinguish between the two
different (ie, non-interoperable) protocols.

Efforts to do that with a single specification wind up confusing things
and confusing readers and implementers.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[John R Levine]

That is, the 'payload' of DKIM is the delivery of a validated domain
name.  In the original specification, we failed to properly specify
which of the two delivered identifiers (d= and s=) was that promised
payload.


These hairs are split too finely for me to understand.  The DKIM validator 
takes the message and the not-API returns a possibly empty list of 
identifiers.  In v2 or whatever we call it, the validator does exactly the 
same thing.


The main difference I see is that if we call v2 something else, we now 
have a tedious administrative exercise of finding every place something 
refers to DKIM and change it to "DKIM or DKIM-plus."  This does not strike 
me as a good use of anyone's time.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Dave Crocker]

On 4/2/2015 8:14 AM, John R Levine wrote:
>>> On the signing side, the signer has the new option of adding a
>>> conditional
>>> signature, but all of the old options still work.
>>
>> Protocols are defined by bits over the wire, not APIs.
> 
> They're defined by both. 

Sorry, no.

Or rather, while it is common to link them together, that's not required.

Just as the same API can be satisfied by many different protocols, the
same protocol can be accessed through many different APIs.

Historically the IETF has tried to focus only on protocols (bits over
the wire), in order to stay away from API wars and the differences
needed by different platforms.  In recent years, this has been relaxed
somewhat, mostly serving to add to the confusion about the difference
between APIs and protocols (IMO).

I haven't done a careful audit, but the IETF typically does not put API
specs on standards track, though I note that the Kerberos GSS-API comes
close.  Except that it is specified as... a protocol.


> The main reason we published RFC 5672 was to
> clarify that the API returns the value of the d= tag, not the i= tag,
> even though the bits on the wire didn't change.

That's not why I initially raised the issue that led to the creation of
the update.  I cast it in terms of overhead vs. payload, the same as I'm
distinguishing here and alas, the same as I was taught, 40 years ago.


"DomainKeys Identified Mail (DKIM) ... permit[s] a signing domain
 to claim responsibility for the introduction of a message into the
 mail stream. "

That is, the 'payload' of DKIM is the delivery of a validated domain
name.  In the original specification, we failed to properly specify
which of the two delivered identifiers (d= and s=) was that promised
payload.


In the Update, here too we see the confusion caused by having the
document even reference the construct of an API.  Frankly I conceded the
reference in that document as a means of trying to get past people's
confusion about the difference between the parts of a protocol that are
overhead, versus that part that is payload, delivered outside of the
protocol.  Given this exchange now, I regret that concession.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[John R Levine]

On the signing side, the signer has the new option of adding a conditional
signature, but all of the old options still work.


Protocols are defined by bits over the wire, not APIs.


They're defined by both.  The main reason we published RFC 5672 was to 
clarify that the API returns the value of the d= tag, not the i= tag, 
even though the bits on the wire didn't change.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Dave Crocker]

On 4/2/2015 7:48 AM, John Levine wrote:
> It occurs to me why this is still DKIM -- the external interface is
> the same.  You call a DKIM verifier by, roughly, giving it a mail
> message, and it tells you what the d= was on the valid signatures.
> That doesn't change.  Anything that uses DKIM v1, whether it's DMARC
> or a Spamassassin plugin, uses v2 the same way.
> 
> On the signing side, the signer has the new option of adding a conditional
> signature, but all of the old options still work.


Protocols are defined by bits over the wire, not APIs.

The most striking example of this point that I had to deal with was
NetBIOS.

IBM published the API but not the protocol.  A few different LAN
companies each created their own proprietary protocols that conformed to
the API, but which were wildly different from IBM's and each other's.

The fact that the new ones all ran over TCP didn't matter:

 They Did Not Interoperate.

Eventually there was market pressure to interoperate and we were forced
to collaborate on the development of RFC 1001/1002.(*)

FWIW this confusion about the nature of 'upgrades' is a relatively
consistent pattern over the years.  It plagued some of the recent
internationalized email work, which bogged down in trying to define both
a new mode and the shared operation with new and old modes.  And it
plagued IPv4/IPv6, although in the reverse direction: v6 could have been
an almost-compatible upgrade, which would have made gatewaying trivial
and deployment probably 15 years earlier...

d/

* It was also my introduction to the difference between skills in
implementing a protocol specification, versus skills in designing one.
Being quite good in the former was no prediction of competence in the
latter...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[John Levine]

In article <551cc3fe.10...@dcrocker.net> you write:
>On 4/1/2015 8:22 PM, John Levine wrote:
>>> In the latter case, it's really an entirely new protocol, which should
>>> be identified by the next-lower protocol, rather than by using the
>>> version field as an in-bred demultiplexing field.
>> 
>> I suppose, but if the two procols are 99% the same, and the new one is
>> upward compatible with the old one, and anything that understands the
>
>'Upward compatible' was carefully distinguished from 'different protocol'.

It occurs to me why this is still DKIM -- the external interface is
the same.  You call a DKIM verifier by, roughly, giving it a mail
message, and it tells you what the d= was on the valid signatures.
That doesn't change.  Anything that uses DKIM v1, whether it's DMARC
or a Spamassassin plugin, uses v2 the same way.

On the signing side, the signer has the new option of adding a conditional
signature, but all of the old options still work.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Anne Bennett]

Murray S. Kucherawy responds to my (not-so-new) suggestion:

>> Some days ago I tentatively suggested signing only part of
>> some message parts, in particular part of the Subject header
>> (excluding any future additions of "[list-identification]"),

> As I recall this was considered during the development of DKIM originally,
> exactly for this reason.  We rejected it because we couldn't come up with a
> safe description of what a tag should look like.  If arbitrary text is
> allowed in there, then one could "tag" a spam URL at the front of a
> legitimate message's Subject field and the signature would still pass.

Right, but if that tag were explicitly deemed to be excluded
from the signature, it could be handled differently.  Hmm, but
if this resulted in (for example) the tag not being displayed,
then we would have gained nothing in the case of mailing lists.

> Short of introducing legislation about what constitutes a "standard" set of
> list modifications, which would be highly controversial

Unlike, say, having mailing lists munge the "From:" header.  ;-)

> and consensus
> firmly disliked, there wasn't a good path forward there, so the working
> group dropped the idea.

... but okay, in view of the fact that this idea ends up not
really gaining us much in terms of allowing mailing lists to
tag their messages,  I'll drop it.


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third Party Sender DMARC Adaptations

[Hector Santos]

On 4/1/2015 9:00 PM, Michael Jack Assels wrote:


To avoid a new header field or a "v=" increase, to make DMARC failure a really
reliable indication of genuine invalidity, at least where mailing lists
are concerned, why not focus on the fact that RFC5322.From headers clearly
allow multiple addresses, and invite Mediators such as mailing list to take
responsibility for their changes by adding an address in their own domain
to the RFC5322.From header and adding their own DKIM-Signature?


Which address would be first?  The 3rd party or the first party?  Will 
the 3rd party first do a POLICY check to determine is this is allowed? 
 Maybe the first party doesn't want or expect any 3rd party signature?


I think the MLS/MLM needs to first respect the wishes of the 1st party 
before trying to circumvent the security by modifying the 5322.From.



RFC7489 seems to hem and haw a bit about multiple From addresses (in a
single From header).  E.g., in Section 6.6.1:

o  Messages bearing a single RFC5322.From field containing multiple
   addresses (and, thus, multiple domain names to be evaluated) are
   typically rejected because the sorts of mail normally protected by
   DMARC do not use this format;

and a little later in the same section:

The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge.  The process in this case is to
apply the DMARC check using each of those domains found in the
RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.


While it is technically allowed by 5322. I have yet to see this in the 
wild and many software components simply are not ready for such 
multiple From field, especially at gateways and transformations or 
online hosting systems or MUAs where only one from is expected.



(The word "fail" leaves me confused.  Shouldn't that be "pass"?)

At any rate, it seems to me that if DMARC would be satisfied by a Mediator
making substantial modifications to my message, changing the RFC5322.From
to 


Its far easier to just a DNS lookup of the 1st party to determine if 
the 3rd party is a trusted, authorized resigner, "mediator."


 YesNo =  Is_Signer_Authorized(Author, Signer)


Far easier and least expensive solution.

--
HLS


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc