Re: [dmarc-ietf] Reversing modifications from mailing lists

[ned+dmarc]

> It appears that Wei Chuang   said:
> > If the RFC2045 canonical representation at the final destination can be the
> > same as the canonical representation at the original sender, ...

> When we were working on DKIM canonicalization we had lengthy discussions about
> what to do about MIME and we decided not to even try.

A mistake IMO.

> There is no canonical
> representation of a MIME message and nobody to my knowledge has ever tried to
> describe what it would mean for two MIME messages to be equivalent, since they
> could vary in a fantastic number of ways.

First, a caonnical form doesn't have to produce a 100% reliable equivalency
test in order to be useful.

Second, there can be more to a hash computation than a canonical form. This
is especially true given that a MIME message is a tree.

> Part separators can change, the
> pieces of multipart/whatever might change, line breaks in quoted-printable
> and base64 can change, spacing and capitalization of headers can change, and
> that's just what I can think of in two minutes.

If you treat the message as a Merkle tree with:

o Separate header and body hashes
o Decoding message bodies prior to hashing
o Applying the already-defined unfolding/capitalization stuff from DKIM
  to part headers.
o Removing the CTE field and boundary value from CT fields in the header

You end up with a value that's:

o Invariant in regards to part separator changes
o Invariant in regards to CTE changes
o Invariant in regards to many/most common header changes 
o Allows for rapid computation of hashes for large numbers of large messages
  that share common content.

Which I note takes care of your list.

But the question is, as always, whether or not defining such a thing is worth
the trouble. At this point I think the answer is "no".

    Ned

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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[ned+dmarc]

>>> Actually that's a community that I would expect to know exactly what all 
those terms mean and
>>> how they are all related.



yes. But it's worse than that.  The current language is not
automatically clear even for folk with good knowledge about DNS
administration.



As is being noted, I too think a great deal of the problem is
over-reliance on the word register.



It is being used as if it explains a basic difference in administrative
roles.  It doesn't.  Not even close.




>> To work with the example you gave here, I agree that "facebook.com" is registered 
(under "com"), but
>> disagree that "www.facebook.com" is registered at all;



> Right, of course it's not.



I disagree.  Strongly.  The fact that one registration is internal and
another is through a third-party, semi-regulated service does not make a
difference, for the use of that word.



I work with an organization that has an IT department that is just as
formal typical ICANN-authorized registries.  To get a sub-domain is a
Very Big Deal.  Don't think for a moment that it is fundamentally
different than interacting with the TLD registeries.


Wow, I didn't know you had started working for Oracle! Welcome aboard! ;-)

Seriously, this is the rule, not the exception, with large organizations,
especially those that assign significant value to their domain reputations.
There are all kinds of hoops you have to jump through before you'll be able to
get a sub-domain, or for that matter a different name with the company name
embedded in it. And after it's registered, there are ongoing maintenance
requirements.

Registering a domain with, say, GoDaddy is a triviality by comparison.

The SSL certificate situation adds even more complexity, but fortunately
that's not relevant here.


> I didn't say that it is: I said that
> people who don't fully understand this stuff *think* it is, and that's
> the part that the text isn't making clear.



>> To my mind, "register" involves a specific transaction, sometimes involving 
money, with whoever gates
>> access to make those delegations.



How much do you pay to register to vote?



However the rest of the above statement is correct.  A transaction to
record gain access to a resource or to reserve access to it.



Registration is a process of signing up.  That's all.  And it says
nothing about the role or relationship of the entity the registration is
with.


Yep.

Ned

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote:
>
> DMARC validation failures can be caused either due to legitimate mail
> (i.e., mail originated by or on behalf of the publisher of the DMARC
> policy, a.k.a., the domain owner) failing authentication checks due to a
> shortcoming in the authentication practices of the domain owner or some
> other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
> not originated by or on behalf of the domain owner, so mail intended to
> fraudulently impersonate the domain), specifically the kind of mail that
> DMARC is purported to be designed to stop.




That kind of analysis seems to be missing from the draft.  After some years of
experience,  we should be able to provide some, I'd hope.  If not, we'd better
bluntly drop the draft.


I think a list of possible failure causes would be nice to have, because
a lot of people seem to think that DMARC is a completely reliable mechanism.

I'm not entirely convinced this document is the place for it, but OTOH
I'm not convinced it isn't.

It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.

Let's see. We have:

 o Illegitimate mail
 o Message changed in transit, invalidating DKIM signature
 o Incorrect DKIM signing
 o Incorrect SPF setup
 o Unintentional domain misalignment
 o Improper assertion of DMARC policy


We get regularly get problem reports whose root cause turns out to be one of
these things.

I've probably missed a bunch, and this may not be the best way to compose the
list.

    Ned

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote:
>
>> I still think it'd be a good idea to mention RFC 6590...
>
> Why? RFC 6590 documents a generic approach to partial information hiding. It
> does not specify how to apply this technique to DMARC failure reports, and
> doing so effectively requires a careful assessment of what needs to be hidden
> and what does not, and that in turn drags in all of the specifics we need to
> avoid in a base document of this sort.




The failure-reporting draft references RFC6591.  The only appearance of the
term "redaction" occurs in the 2nd paragraph of Section 4.1:


Referencing an approved standards document on failure reporting formats is
perfectly reasonable and even necessary.


These reports may expose sender and recipient identifiers (e.g.,
RFC5322.From addresses), and although the [RFC6591] format used for
failed-message reporting supports redaction, failed-message reporting
is capable of exposing the entire message to the report recipient.



RFC6591 doesn't go into a very detailed description.  It references RFC6590:



For privacy reasons, report generators might need to redact portions
of a reported message, such as an identifier or address associated
with the end user whose complaint action resulted in the report.  A
discussion of relevant issues and a suggested method for doing so can
be found in [RFC6590].



RFC6590, in turn, avoids the specifics of what exactly needs to be redacted.
However, it mentions the local parts of email addresses.


If anything this is an even stronger case for not referencing RFC 6590 here -
it's unnnecessary because the reference is already in the failure reporting
format specification.

I also note that RFC 6591 was published in 2012, long before PII became such a
contentious issue. Timing can be everything.


> P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
> standards-track status to be nothing short of astonishing. How on earth do
> you assess interoperability?



Maybe it's the ability to relate reports from the same source with one another
which makes them manageable.  Producers of actionable reports and consumers who
react properly can be said to interoperate, can't they?


Absent agreement on what gets redacted and how? Not even close.

RFC 6590 doesn't even pass muster as a BCP, since it describes an overall
approach to solving a range of problems and explictly does not recommend
a particular practice.

This is an informational document, nothing more and nothing less.

Ned

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

Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Mon, 28 Dec 2020, Ned Freed wrote:
> I'm not ethusiastic about the split, but if that's what people want then so be
> it. I will say that my experience has been that doing so is usually more work
> and provides less benefit than you'd expect.



I recall agreeing to split out all of the reporting into a separate draft,
which makes some sense so the two parts can proceed separately, but not
further splitting aggregate and failure reports.


I was referring to the latter; I thought the reference to the drafts involved
made that clear. Sorry for the confusion.

The outcome of the split of MIME part one into four parts may offer some
limited insight here. IMO splitting message bodies from media types was a sound
logical split and ended up being a good thing. The split of conformance
criteria from media types, however, was a pretty serious lose - they now tend
to get ignored - so much so it's tempting to try and undo it.

But the split of media type registration from MIME/email was the real win, so
much so that it more than justified the entire activity.

The lesson, if there is one, is to go just far enough, but no further.
Splitting different reporting types smells a lot like "further" to me.

    Ned

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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote:
>> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote:
>>> I Believe I agree with the current version, but can someone post what we
>>> think is the final text?
>
> See below, with the two changes mentioned before and Mr Copy Edit's minor
> tightening up which I hope are not controversial.
>
> Ale said:
>> I posted it here:
>> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting
>
> Hold it. I don't recall that we agreed to break failure reports into a 
separate
> document.




The fact that draft-ietf-dmarc-failure-reporting-00 exists on IETF datatracker
seems to confirm WG consensus.


I'm not ethusiastic about the split, but if that's what people want then so be
it. I will say that my experience has been that doing so is usually more work
and provides less benefit than you'd expect.

That said, the adoption of something as a WG document, especially one with an
intended status of  and in the absence of a corresponding charter update,
doesn't really mean much. 


I also don't see where the discusssion leading to the WG consensus on the
split occurred on the mailing list. Perhaps you could point me at it?



But see also:
https://mailarchive.ietf.org/arch/msg/dmarc/2DsSazvE9QxFjVSeg_mdNlRMETM




> It makes more work and I see no agreement to change anything beyond the
> security paragraph.  In particular, we have nothing to offer on what one
> might or might not redact.




I still think it'd be a good idea to mention RFC 6590...


Why? RFC 6589 documents a generic approach to partial information hiding. It
does not specify how to apply this technique to DMARC failure reports, and
doing so effectively requires a careful assessment of what needs to be hidden
and what does not, and that in turn drags in all of the specifics we need to
avoid in a base document of this sort.

Indeed, as things stand, since the intent of RFC 6589 is to preserve some
information, we can't even say it solves any particular problem with DMARC
failure reports.

Ned

P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on earth do you
assess interoperability? 


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

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

> On Wed, Dec 23, 2020 at 10:10 AM John R Levine  wrote:

> > On Wed, 23 Dec 2020, Ned Freed wrote:
> > >  Failure reports provide detailed information about the failure of a
> > single
> > >  message or a group of similar messages failing for the same reason. They
> > >  are meant to aid in cases where a domain owner is unable to detect why
> > >  failures reported in aggregate form did occur. It is important to note
> > >  these reports can contain either the header or the entire content of a
> > >  failed message, which in turn may contain personally identifiable
> > >  information, which should be considered when decoding whether or not to
> > >  generate such reports.
> >
> > Ship it.
> >

> With one minor correction, I agree. The minor correction is in the last
> sentence: s/decoding/deciding/

Yes, sorry about that.

Ned


> --Kurt

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[ned+dmarc]

> In article  you write:
> >> One of the points of the tree walk is to get rid of the PSL processing.
> >

> > The PSL processing is a local lookup on an in-memory suffix tree.  How is 
> > it a
> > progress to replace it with a tree walk?  A PSL search is lightning faster 
> > than
> > even a single DNS lookup, isn't it?

We added PSL support for other reasons some time back.

FWIW, there were some intricacies I didn't like in the suffix tree approach.
And since memory use really isn't a consideration for something this small, I
opted for multiple lookups in a hash table instead. We have our own hash table
code and loadable format, but there are compile-to-loadable-format tools out
there if you don't want to roll your own.

> You have to download a copy of the PSL,

Hopefully you're doing that in the background...

> read it into your program, and
> parse it into some internal form. The PSL is over 200K of text and
> 13,000 lines, so while it's not a large file, it's not zero either.

Our implementation processes a bunch of text files from various sources, of
which the PSL is less than 5% of the total size, into our loadable format.

I just checked, and it takes a litle over 2 CPU seconds to run the program. On
an 333Mhz Alpha.

I really don't think this is a concern.

> If you're lucky you can amortize your PSL parsing across multiple
> DMARC checks, but your DNS cache amortizes DNS lookups across mutiple
> checke, too.

Parse only happens when one of the input files changes. Why would you
implement it any other way? 

> The DNS approach has the advantage that you don't have to depend on a
> third party's text file updated at unknown intervals, and also makes
> it easier to deal with what I've called the Holy Roman Empire problem.

So you download and check every week or whatever. Still not seeing a problem.

Finally, there's the HRE issue. Which I guess could be a problem. But so can
DNS usage, which is subject to what I'll now call the fiefdom problem, where
you're required to use a DNS service operated by someone else in your org and
they are ... problematic.

Of course DNS use is unavoidable. Even so, the fiefdom problem has led to
requests to minimize DNS usage by any means possible.

The HRE problem remains theoretical for us at least.

    Ned

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[ned+dmarc]

...



Well, ok, here's one that shows lack of efficacy, and it's a big one: 
EV-certs



/Google to bury indicator for Extended Validation certs in Chrome
because users barely took notice/



https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/



"The reason is simple. "Through our own research as well as a survey of
prior academic work, the Chrome Security UX team has determined that the
EV UI does not protect users as intended... users do not appear to make
secure choice..."


To be fair, this is looking at positive security indicators, not negative
ones. But there are plenty of other studies looking at the more general
case. Here's one that seems relevant to DMARC:

  Do Security Toolbars Actually Prevent Phishing Attacks?
  https://dl.acm.org/doi/pdf/10.1145/1124772.1124863

  Abstract:

  Security toolbars in a web browser show security-related
  information about a website to help users detect phishing
  attacks. Because the toolbars are designed for humans to
  use, they should be evaluated for usability - that is, whether
  these toolbars really prevent users from being tricked into
  providing personal information. We conducted two user
  studies of three security toolbars and other browser security
  indicators and found them all ineffective at preventing
  phishing attacks. Even though subjects were asked to pay
  attention to the toolbar, many failed to look at it; others
  disregarded or explained away the toolbars' warnings if the
  content of web pages looked legitimate. We found that
  many subjects do not understand phishing attacks or realize
  how sophisticated such attacks can be. 


    Ned

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

Re: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy

[ned+dmarc]

The MIME document split was, in hindsight, partly successful (separation of
media types registration was a really good thing), partly unsuccessful (part
five should not have been pulled out of part two), and partly a wash (the
cost/benefit of separating parts one and two ended up pretty much equal IMO).

The devil is always in the details. The DMARC alignment validation process
appears free of policy considerations as currently specified, and is thus a
candidate for separation. But are we sure it will remain so, and is the
separation of a relatively small part of the specification worth it?

Ned


I am not a fan of splitting documents only for an abstract sense of
cleanliness.  There needs to be justification of improved documentation
'cleanliness' and/or useful removal of fate-sharing -- if separate fates
are reasonably expected.




DMARC alignment validation is a basic, mechanical process that produces
a yes/no response.  At that level, it's comparable to the nature of a
DKIM validation, except for the From: field domain.



DMARC "policy" is fundamentally different.  It's not that its mechanism
isn't "mechanical" but that its semantics produce more semantic and
operational challenges.




I think that could reasonably make it worth strongly separating them
into two different documents, no matter has small one of the documents
might be.





d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net



___
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] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

[ned+dmarc]

On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote:
> On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely  wrote:
>
>> For multipart messages, transformations may need to replace boundaries.
>> In that case, the "restricted patch" to undo the transformation may
>> require more data than it is convenient to store in a DKIM tag. >>
>
> Replace why?  It might need to add its own, but it's easy to undo that.




Oops, I thought MLM generated boundaries anew.  It seems that's not the case.


Depends on the MLM and what it is doing. For example, boundary marker
regeneration can happen if you're adding a header or a footer to a multipart
message.


Still, the original Content-Type is difficult to reproduce exactly.  You need
to know whether the boundary= parameter is written as a token or a
quoted-string, and, if not c=relaxed, spaces and newlines.  If longer than a
few bits, the info to undo the transformation (a reverse patch?) could be
stored in its own field, or even in an attachment.



Another difficulty, IIRC, is reordering of To:.  This can simply be avoided.



> In order to be useful, this only needs to do what MLMs commonly do
> already.  We don't need to cover the universe of possible futures right
> away.



Agreed.  MLMs code has no lack of conditionals.  Probably this technique can
address a class of mailing lists somewhat wider than the "no-changes" class,
without trying to cover even one half of /present/ MLM possibilities.  Shall
say just enough to cover IETF mailing lists?


The problem is that list software wasn't designed with the idea of keeping
changes to an invertible/removable minimum in mind. So you're going to see
many/most of the transformations this document deals with done in ways other
than what the document describes. So in order to make use of this document
you're basically talking about a fairly major rewrite.

I think that's unlikely to happen.

    Ned

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

Re: [dmarc-ietf] DMARC as an instance of a class

[ned+dmarc]

On 7/3/2020 9:58 AM, Hector Santos wrote:
> On 7/1/2020 7:51 PM, John Levine wrote:
>>
>> ##, ###. Spam filters like spamassassin have looked at the headers
>> along with everything else in the message forever.
>
> SA is a tool that reads the entire RS232 payload.



HA! RS232 on my mind, helping an enterprise customer with his 32 modem
server setup. Of course, I meant RFC5322.


Good to know I'm not the only one who confuses those.

    Ned

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[ned+dmarc]

> In article 
>  you 
> write:
> >I for one am always amazed how much people use web forums, which are almost
> >all universally worse at providing a reading interface or keeping people
> >up-to-date on new messages... which might be why most of the one's I look
> >at are nearly dead, maybe there are better ones that are active.

> Well, there's Reddit, and um, er.  Flyertalk, I guess.

> One thing web forum fans seem to miss is how poorly they scale. I
> subscribe to at least 150 mailing lists, most of which are only active
> occasionally. As mailing lists, that works fine. The busier ones go
> into separate folders, less busy into a general folder, and MUAs tell
> me which folders have new messages so I can scan through all of my
> list mail about as fast as I can hit the tab key to move on to the
> next message. This works equally well for public and private lists.

> In theory RSS or Atom does this for web forums, in practice, it's
> amazing how lousy their RSS support is and how lame RSS readers are
> for public fora, and hopeless for private ones where you have to log in.

And that assumes the site supports RSS/Atom. Many don't.

The other problem with all of these tools is that someone else gets to
decide how to organize your life. If you decide that two different fora
should be grouped together, good luck getting your reader to do that for
you.

But Slack is the true nadir of usability in this regard. I have dozens of
channels I need to monitor, the breakdown of same is not remotely aligned with
how I would prefer to consume them. Add in a complete crap UI, and I honestly
can't think of a mail UI I've used that's worse. Not ever.

    Ned

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

Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication

[ned+dmarc]

On 2020-04-23 02:20, John Levine wrote:
> In article <51be5654-94c4-38c6-8f6b-dca403d66...@dcrocker.net> you
> write:



>> The paper asserts that AR is used as DMARC input.  I suspect that is
>> rarely, if ever, true.  Yes? No?
>
> I'd say never.  To do DMARC rejects you have to do all of the
> validation in the SMTP daemon, which is before anything has a chance
> to create an A-R header.



Of course this is possible with the Milter protocol introduced by
Sendmail and used also by Postfix. The mail traverses during the SMTP
phase through different milters, e.g. a SPF milter, followed by a DKIM
milter, and every milter injects an AR header with its results. The last
milter is a DMARC milter that processes the AR headers and signals the
SMTP daemon do either accept or reject the message. This is how OpenDKIM
& OpenDMARC work together.


This is done all the time, and not just by Sendmail and Postfix.


Other projects do it all in one milter (rspamd?)...


Yes, but when you do it all in one go it's more difficult to customize.

Ned

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

Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax

[ned+dmarc]

> I believe in the situation where standard is absolutely clear like this,
> any implementer must strictly follow the standard. Otherwise, it can
> lead to unpredictable behavior and security issues.

Sorry, I meant to mention this in my previous response. It's one thing
when there's wiggle-room or lack of clarity in the standard. It's quite
another when things are clear, as is the case here.

> Example: there are absolutely legal situations where non-trusted or less
> privileged side can partially control the name and/or content of the DNS
> record. I can provide users or customers with possibility to register a
> hostname and TXT record in my zone but I want to prevent them from
> corrupting or changing SPF/DMARC/etc policy. I can rely on filtering TXT
> record content. Non-standard behavior of DMARC implementation can allow
> to bypass this filtering.

> While this example doesn't seem realistic, I can demonstrate quite
> realistic ones. For example, a minor relaxation for ARC version check
> can lead to DKIM signature spoofing, compromising DMARC as a result. For
> DMARC DNS record itself, realistic scenario may appear in the future.

> We already have a lot of problems in-the-wild because of standards
> relaxations, e.g. it's usually possible to bypass DMARC which relies on
> RFC5322 via malformed From: due to fact invalid From: header is
> generally accepted and parsing From: header for DMARC validation and for
> visual representation is usually made by different pieces of code with
> different behavior.

Exactly. This is a security protocol and there are real security implications
of doing stuff like this. Another reason to Just Say No.

    Ned

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

Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax

[ned+dmarc]

On 1/16/2019 11:18 AM, John Levine wrote:
> Remember, that if your software rewrites an invalid record into a
> correct one, you are trying to read the mind of the person who wrote
> the misformed record.




To emphasize a point you made earlier:  There are many, small
adjustments that a receiver might make, with the intention of operating
more robustly.  The current examples certainly quality as small and
seemingly innocuous.  But the earlier point was that one deviation from
the specification bodes ill for more important questions of conformance...



If they didn't read this part carefully, why believe they read other
parts more carefully?


The seemingly innocuous nature of the accomodation is only one of several
factors that need to be considered when deciding whether or not to implement
these things. Others include, but are not limited to:

(0) What are the worst case security considerations?

(1) Whether or not the misbehavior is widespread.

(2) Is the misbehavior likely to be corrected if you don't accomodate it?

(3) What wiil the effect of telling customers experiencing difficulties that
   it's Someone Else's Problem be?

(4) What is the long term impact on your code going to be?

All that said, in the present case this appears to be a nobrainer: Since the
correct behavior is to ignore malformed records, the security implications may
be significant, it is not widespread behavior, it's very likely to be
corrected, telling people that banks should get their security right seems like
an easy argument to make, and it's a bit of a wart on the code.

I'll also note that transmitters as well as receivers can play the
accomodatation game, with similar effects: What should be common cases
get turned into corner cases, and interoperability suffers as a result.

        Ned

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

Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

[ned+dmarc]

s terminology. However,
> >> regardless of that, this claim about SPF seems problematic in the
> >> sense that you could have an intermediate MTA decorate the message
> >> with the incoming IP address (in some unspecified way)  but then have
> >> the terminal MTA do the SPF validation.
> >>
> >
> > Right, that's a property of SPF: It only evaluates the latest
> > ("connecting" in that paragraph) hop, while DKIM often survives end-to-end
> > irrespective of who's relaying it in to the local ADMD.
> >

> Hmm.. I think I'm making a different argument here. If the evaluating ADMD
> trust claims made by a relaying hop, then it is able to do its own SPF
> evaluation by having the relaying hop supply the IP address of the
> originating MTA, even if the relaying hop didn't itself do SPF validation.
> In this sense, it's not tied to the incoming connection.

Quite right. And these sorts of arrangements where IP address information
is derived not from the connection but from a Received: field, XCLIENT
command, etc. are actually pretty common.

Ned

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

Re: [dmarc-ietf] [ietf-smtp] Moving RFC4406 to historic?

[ned+dmarc]

WFM.

Ned

> On Thu, Mar 22, 2018 at 4:08 PM, Ned Freed  wrote:

> > On 3/22/2018 7:49 AM, Kurt Andersen (b) wrote:
> >> > For the sake of people browsing the IETF RFCs, what would it take to
> >> > make 4406 historic?
> >>
> >
> > +1
> >>
> >
> > Yes, cleaning this up would be good. It doesn't come up often, but it does
> > come up.


> I have now posted
> https://tools.ietf.org/html/draft-andersen-historic-4406-etal-00 for this
> task.

> Please let me know if that fits the bill.

> --Kurt

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

Re: [dmarc-ietf] [ietf-smtp] Moving RFC4406 to historic?

[ned+dmarc]

On 3/22/2018 7:49 AM, Kurt Andersen (b) wrote:
> For the sake of people browsing the IETF RFCs, what would it take to
> make 4406 historic?



+1


Yes, cleaning this up would be good. It doesn't come up often, but it does
come up.

        Ned

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

[ned+dmarc]

This would need to be coordinated with the EAI people/list, but as long
as it isn't controversial I don't see a reason not to put it in.

Ned

> If I may budge in here, any chance we could put in a few tweaks for
> EAI mail?

> I think the main changes would be that if the A-R or AAR header is in
> an EAI message, domain names and local parts can be UTF-8 rather than
> ASCII.  I specifically do not want to change any of the keywords or
> codes, since they're for software, not for people.

> I realize that we should update RFC 6376 at the same time for DKIM
> signatures, but I'll take what I can get.

> 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] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

[ned+dmarc]

Normally I'm not a stickler for avoiding side discussion of related items 
on working lists. But this case I'm going to have to agree with Dave: This

group is not making sufficient progress on its core work, which currently
is to review and progress the ARC specifications. This needs to happen
sooner rather than later, and we cannot afford to spend time on this
specification at this time.

If and when we get that far, we can discuss whether or not this is a fit for
the third track of this WG (documentation of actual and possible operational
practices).



Ned



On 10/3/2016 9:21 AM, Takehito Akagiri wrote:
> We have updated the draft based on comments on ML when we submitted
> draft 00.  I'll show small comments about that.




I'm confused.



First, this is not a task within the working group charter, as I read
it, and I haven't seen a wg discussion to adopt it.



Second, I've seen a range of specific arguments against this work, with
only a tiny amount of support for it, and no follow-up discussion of
those arguments, nevermind accomplishing reasonable resolution of those
concerns.



All of which tells me that this activity is out of scope for this IETF
mailing list.



I encourage the chairs to chime in and either confirm or correct this
assessment.



d/



--
Dave Crocker
Brandenburg InternetWorking
bbiw.net



___
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] indeterminisim of ARC-Seal b= value

[ned+dmarc]

> What's the best way to proceed from here for the working group?

That's easy: The way to proceed is by describing the actual interoperability
problem that came up. In detail.

What you have done so far, AFAICT, is propose a change that at most facilities
a type of testing decades of experience have shown to have limited value.
This is a far cry from describing an actual interoperability problem.

This is, or at least is supposed to be, a technical list. Noone here is
going to be put off by complicated technical details. In  fact the absence
of such discussion was and is a major problem with the advancement of this
specification, and unless that changes fairly soon I'm going to put on my
working group chair hat and say some stuff that people are really not going
to like.

Ned



> On Fri, Mar 31, 2017 at 8:55 AM, Dave Crocker  wrote:

> > On 3/30/2017 10:41 PM, Seth Blank wrote:
> >
> >> If the consensus here is that the matter is not worth pursuing further,
> >> that is fine - I just want to make sure we're all talking about the same
> >> thing.
> >>
> >
> >
> >
> > Except that 'the matter is not worth pursuing' isn't what I heard anyone
> > saying and it definitely wasn't what I meant...
> >
> > I'm not sure whether it's been presented here sufficiently, but I believe
> > your underlying concern is based on observed problems with implementation
> > of the current ARC specification.  That is, from interoperability testing,
> > the actual use of ARC is proving far too fragile.
> >
> > If that's true, then there needs to be an effort to a) understand the
> > fragility better, and b) consider ways to make ARC more robust.
> >
> > So while there has been strong push-back against the /solution/ that you
> > proferred, I am not clear whether there is working group understanding of
> > the motivating concern or with the way to resolve it.
> >
> >
> >
> > d/
> >
> > --
> > Dave Crocker
> > Brandenburg InternetWorking
> > bbiw.net
> >
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
> >



> --

> [image: logo for sig file.png]

> Bringing Trust to Email

> Seth Blank | Head of Product for Open Source and Protocols
> s...@valimail.com
> +1-415-894-2724 <415-894-2724>

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

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

[ned+dmarc]

> >
> > > I think Peter's proposal (and he can correct me if I'm wrong) is only to
> > > constrain signers.  Verifiers are still expected to handle everything
> > weird
> > > that the infrastructure might do.
> > This proposal creates a situation where verifiers are required to support
> > something that no compliant signer will generate. The result will be that a
> > test suite with reasonable coverage cannot be generated using compliant
> > software.
> > And since most people are not going to bother to create an incompliant
> > signer
> > specifically for purposes of testing, if anything this will create, rather
> > than
> > elimnate, interoperability problems.
> >

> Just to be clear, this is not what I was proposing.  Specifically, I don't
> think the Robustness Principle
> <https://en.wikipedia.org/wiki/Robustness_principle> applies in this case.
> Verification should check the RFC defined spacing, ordering, etc. of the
> tag/value pairs and reject non-compliant values

> As this is a new protocol, and these headers are all new and used
> exclusively for ARC, and for the reasons mentioned by Ned, there's no
> reason to be lenient in what is accepted.

On the contrary, there are very good reasons. People aren't going to magic
up implementations of ARC out of nothing; they will undoubtedly use
existing DKIM code as a starting point. Implementing an ordering
requirement on top of such code could get interesting depending on how
it works.

And given the relationship with DKIM people are going to expect ARC
to work in the same general way, maing such a change a least astonishment
principle violation.

> > That sort of organic validation of implementations seemed to work for
> > > DKIM.  The unknown here is whether ARC will be as successful with that
> > > model.

> > Exactly. And given the success of the approach with DKIM, the burden is
> > on those proposing to use a different model for ARC to explain why it will
> > work better.


> A few quick comments on this.

> As per my earlier email, I have a lot less confidence in how well this
> 'seemed to work' than some of the other participants in this thread.  One
> of the benefits of DMARC re:DKIM is it has exposed some issues with DKIM
> implementations that were not obvious prior to DMARC evaluation.  Without
> DMARC reporting some of the problems with certain DKIM implementations were
> simply not very visible.  So I don't actually think the DKIM model worked
> as well as is being asserted.

Which of these problems had anything to do with field ordering? Which of
these problems would have been exposed by requiring a specific
order?

> Second, the existence of such a test suite would have had material benefits
> just within the last ~18 months over which ARC implementations have been
> developed.  We know this because of the immediate benefits the current test
> suite (which does impose a canonical ordering, spacing, etc.) yielded
> almost immediately.

> The suite exposed a few minor but significant issues with the Python
> implementation that was submitted to dkimpy.  Similarly, it exposed that
> the current OpenARC signing functionality is in a much less mature state
> than was generally understood.  In terms of RFC definition, it exposed the
> fact that the current RFC as written required support for insecure 512 bit
> keys - and triggered a discussion on this very list.  In our internal
> development it's forced us to look hard at some of the corner cases and
> raise them on this list or at interops.  Note that most of these issues had
> escaped detection through multiple interops.

> None of the above is meant to insult the associated developers or spec
> authors.  Their contributions have been essential, and the skill and
> dedication they've brought to their tasks is greatly appreciated.  It is
> simply meant to demonstrate the material benefit that this kind of testing
> has already brought.  This is what automated tests do - bring problems to
> light quickly.

> So yes, I think this approach works better.  Much better.

Simply put, I don't. I'm strongly opposed to this, to the point where I'm
likely to significantly deprioritize implementation of this proposal because of
it.

I have better things to do that waste my time watching the sorts of bugs this
is going to cause get shaken out.

Ned

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

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

[ned+dmarc]

> On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman <skl...@kitterman.com>
> wrote:

> > What's more difficult to is identify all the ways that things get
> > reordered,
> > mangled, etc as they transit the various elements of the mail architecture.
> > If you over specify the allowed order, aren't you risking increasing the
> > brittleness of the solution.
> >

> I think Peter's proposal (and he can correct me if I'm wrong) is only to
> constrain signers.  Verifiers are still expected to handle everything weird
> that the infrastructure might do.

This proposal creates a situation where verifiers are required to support
something that no compliant signer will generate. The result will be that a
test suite with reasonable coverage cannot be generated using compliant
software.

And since most people are not going to bother to create an incompliant signer
specifically for purposes of testing, if anything this will create, rather than
elimnate, interoperability problems.

> > If test cases are automatically generated, then they are cheap and we
> > shouldn't worry about unduly constraining things to keep the number
> > small.  As
> > long as, at some point, the test cases are validated against multiple
> > implementations, I think it's fine.  If you've got a handful of
> > implementations, then the risk of them all having the same bug is pretty
> > low.
> >

> That sort of organic validation of implementations seemed to work for
> DKIM.  The unknown here is whether ARC will be as successful with that
> model.

Exactly. And given the success of the approach with DKIM, the burden is
on those proposing to use a different model for ARC to explain why it will
work better.

And note that "this kind of test becomes possible" is not sufficient. All
kinds of tests become possible when you add constraints - the question is
what sort of real world problem will those additional tests find.

Ned

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

Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[ned+dmarc]

> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form
> it can not be implemented in most MTAs (see below)

It wouldn't work at all in our MTA without modifications because our general
filter interface currently receives recipient addresses after some processing
has been performed. We could add an option to change that fairly easily, but as
you note, that doesn't address all the issues.

> 2. This standard mixes transport standards (SMTP) and message standard.
> There are multiple issues as a result of this:

> 2.1 Same message may have multiple recipients on different MTAs while
> each MTA only sees it's own recipients. So, destination MTA can not
> verify signature, because it doesn't know all recipients. This can be
> fixed if message to every destination is  signed independently, but it
> breaks existing mail flows, because in most cases message is signed
> before placing to MTA queue.

We have sufficient flexibility in this regard to sign late (and as noted
above, verify early), and we can split by destination before signing
each variant separately.

What would be much more difficult is detecting this usage and turning off
splitting where feasible to avoid breaking the signature. That would be very
difficult.

The bottom line is that at best this will be very fragile, at worst it will
fail a significant percentage of the time.

> 2.2 Recieving MTA may e.g. limit the number of recipients and single
> message may be sent to different final recipients on the same MTA in
> multiple session as few different messages, each message with partial
> list of recipients.

Actually, this quickly turns into a hairball. The minute the receiving
system starts 4yz'ing some recipients the precomputed signature is going
to be rendered invalid and will have to be recomputed.

And how does the receiving MTA know when do this? It gets no indication
that it's dealing with this particular DKIM variant until after recipients
are processed. So it's only choice would be to do it unconditionally, or
to try and keep track of senders who use this feature.

Yuck.

> Actually same message to same destination may be
> sent to different MTAs (e.g. different MXs with same weight).
> 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> lowercase the domain of recipient.

Our default is to leave the case of addresses alone by default, but sites often
do configure things to "right case" their business name. That said, Early
validation would avoid such issues for us. I think.

> All problems except 2.1 may be fixed by adding additional header, like e.g.
> DKIM-Transport-recipients
> which contains salted hashes (with some random salt) of all recipient
> addresses, and require this header to be added to DKIM signature and
> existence for every recipient's address' hash to be checked in this
> header. It is compatible with any current DKIM implementation.

If you're talking about hashing all recipients together, then I don't see this
solving all the problems except 2.1.

And if you're talking about hashing them separately, then why would you
insist that they all be present?

> 2.1 can also be solved in this case, but it disclosures BCCs of the
> message (even if this header is removed before delivery to mailbox)

Prior to delivery the bcc's are disclosed by being present in the envelope. So
as long as the sender adopts the approach of splitting by destination before
signing, only including the recipients for a given copy in the signature, and
the receiver removes the field prior to final delivery, I think it might
work.

But limiting the number of recipients to 1 when this extension is used would be
a much simpler approach. Of course there's some overhead involved in doing
this, but given the idiotically limited spam report mechanisms in place at some
sites single copy may be a requirement already.

> All problems may be solved by using asymmetric encryption instead of
> hashing, e.g. require domains with support for this standard to publish
> some public key (or to use special DKIM selector) via DNS record and
> encrypt recipient's addresses in the additional header with public key
> and only sign recipients for systems with this key published.

Yes, and that's really cute. Considerable overhead though.

> P.S. I just did a quick look into standard, sorry if I missed or
> misunderstood something.

So did I, and so do I.

Finally, my biggest concern here is that this, like most proposals that
involve complex linkages between the header and envelope, is complex
and loaded with pitfalls. (Just look at these two messages...) And at least
some of this spills over to both implementations and operational policy.

Can we really expect people to get this right?

Ned

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

Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)

[ned+dmarc]

On 11/7/2016 11:41 AM, Franck Martin wrote:
> The EAI WG found it was fine to remove the obligation to have an email
> address part in the mandatory RFC5322.From header, leaving only the
> display part to assert the original author.



We had that relaxed permission for From:, in the original
From/Sender/Reply-to specification of rfc733, with the requirement that
there be a Sender: email address.  It looks like we removed it for rfc822.



And while I recall something of the EAI discussion, I'm not recalling
this permission's being returned.  Nor am I finding it in rfc6854:



  https://tools.ietf.org/html/rfc6854#section-2



So, please point to the formal specification that permits a From: field
to have no email address.


RFC 6854.


Absent that, there's the small question about how the EAI group would
have the authority to make such a major change to such a basic email
feature...


RFC 6854 can speak for itself as to the rationale for allowing no address.

The EAI connection was, as I recall, for use in downgrade formats used to
present EAI messages to non-EAI clients via POP3 and IMAP4.

        Ned

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

Re: [dmarc-ietf] Responses to IESG review comments on draft-ietf-dmarc-interoperability

[ned+dmarc]

> Noting again that my comments are non-blocking (so you
> should feel free to ignore me:-), but ...

> On 22/06/16 06:08, Kurt Andersen wrote:
> >> > - I think the abstract and intro would be better if they
> >> > explicitly ack'd that DMARC affects mailing lists. . .

> > While mailing lists can be adversely impacted, I don't think

> s/can/are/ above, as previously agreed.

> > that they are necessarily more impacted than the other items
> > which are called out in the body of the document.
> >

> It is IMO entirely noteworthy that the primary mechanism used
> to discuss the definition of mail protocols, including this one,
> has been adversely affected by this mail protocol.

> One can quite rightly and fairly claim that that trade-off is
> overall a win for the mail ecosystem, but not being explicit
> about what has been the biggest downside of dmarc, from the
> IETF participant perspective, seems plain wrong.



On reflection and after reviewing the document, I have to agree with Stephen
here. The conditional language makes it sound too much like the problems DMARC
causes can be avoided, when in fact doing so almost always has an adverse
impact on the overall functionality of the mail system.

IMO Stephen's suggestion is a good one and should be implemented.



    Ned

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

Re: [dmarc-ietf] Meeting in Berlin... or no?

[ned+dmarc]

> On Fri, Jun 3, 2016 at 3:44 PM, Barry Leiba <barryle...@computer.org> wrote:

> > My sense is that we don't need to meet face to face in Berlin.  We
> > have lots of things to discuss on the list, but we're not stuck on
> > issues that need in-person time.
> >

> Agreed.

Agreed as well.

Ned

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

Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

[ned+dmarc]

There are a few different points here:



1.  The proposed activity falls perfectly under "track" 1:



> 1. Addressing the issues with indirect mail flows



If anyone disagrees with that, that should probably be discussed as a
distinct point, because I think it's obvious.


I concur.


2.  The constraint to "not develop additional mail authentication
technologies" has a scope limited to the second "track", which is:



> Reviewing and improving the base DMARC specification



Since the proposed activity does not directly touch any aspect of the
base DMARC specification, I again think that the INapplicability of the
text for track 2 is also obvious.


Agreed again.


3. Now we get to the difference between a track and a phase.  And to
state the issue is to state its resolution:  these are different
constructs, with different terminology.  As if they are meant to be
considered separately...


It never occured to me to think of the two as connected or cooresponding
or anything similar.



The first item in Phase II is:



>  Phase II:
>
> Specification of DMARC improvements to support indirect mail flows



And here's where I wish we'd phrased things a bit differently, although
I don't think the current wording is a show-stopper.


It probably would have help to clearly link this item to track 1.


The proposed work falls under this first item in phase II.



The catch is that the draft doesn't /say/ it's improving DMARC.  (In
fact, I've been quite vigorous in pressing to have the proposed spec
carefully not say much about DMARC.)  But really that's a
document-writing point, not a working group functional point.


Agreed.


That is, ARC's development has been specifically motivated to respond to
exactly this item in Phase II.



If we did sloppy specification-writing, we'd have written this as a part
of a DMARC enhancement.  Not the 'base', of course, but an enhancement.
The fact that it's been written as an independent component is so that
its use is not /limited/ to DMARC.  But again, that's merely a writing
artifact.



So, my reading of the charter says that the proposed spec falls under
the first item of Phase two and the second sub-bullet of Track 1.


As does my own reading.

Ned

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

Re: [dmarc-ietf] Document shepard's review of draft-ietf-dmarc-interoperability-14

[ned+dmarc]

> On Wed, May 11, 2016 at 1:45 PM, <ned+dm...@mrochek.com> wrote:

> >
> > For this reason I think it would be a good idea to address these nits
> > sooner
> > rather than later.
> >

> I have just now posted
> https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-15 which
> incorporates the fixes suggested by Ned. The only one that I did not
> incorporate was the suggestion to reformat the example message in A.2 into
> a standard DSN (mainly in the interests of time, but also because it may
> make sense to just drop the appendix altogether).

It's by no means essential to do that.

> Thank you for the fine-tooth comb treatment!

No problem!

    Ned

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

[dmarc-ietf] Document shepard's review of draft-ietf-dmarc-interoperability-14

[ned+dmarc]

In my capacity as document shepard, I've now done fairly careful review of the
document. The results of that review are attached below.

Almost all - but not all - of the issues I found were editorial, not technical,
in nature, which is as it should be for a document that this stage. However, we
are also about to issue an IETF-wide last call, which will hopefully result in
wider review of the document by a more general audience, so now is also the
time to correct as many editorial nits as we can so the document is as clear as
it can be.

For this reason I think it would be a good idea to address these nits sooner
rather than later. But if that's a problem I certainly can live with
going to last call with the current version.

Ned
First, some global changes need to be made to be consistent with RFC 5598:

  "RFC5321.mailfrom" -> "RFC5321.MailFrom" 
  
  "RFC5321.HELO/EHLO" -> "RFC5321.HELO/.EHLO" 

  "RFC5321.Helo" -> "RFC5321.HELO/.EHLO"
  
  "RFC5322.from" -> "RFC5322.From" 

I note that RFC5322.Foo usage other than RFC5322.from appears to be correct. 

I will add that I take no position on the style chosen in RFC 5598, in
particular the RFC5321.HELO/.EHLO form. But if we're going to use RFC 5598
conventions we need to be consistent with them.

The document variously, and more or less interchangeably, uses the terms

   "bounce" message
   
and 

   delivery status notification
   
to refer to messages with a null RFC5322.MailFrom. Neither term is ideal;
"bounce" message is too informal and potentially covers messages with
non-NULL RFC5322.MailFrom, and both terms are insufficiently general.

The term RFC 5321 uses is "notification message", but only in a narrow
context. I therefore suggest defining this term in the conventions section
as follows:

   The term "notification message" (RFC 5321 section 4.5.5) is used to refer
   a message with a null RFC5321.MailFrom.
   
And then use this term throughout the document whereever it currently
says "bounce" message or delivery status notification.

The Introduction ends with:

   Also, some practices which are in use at the time of this document
   may or may not be "best practices" as future standards evolve.

This statement doesn't seem to connect with anything. Is this talking
about practices described in this document? It so, it should be changed
to something like:

   Note that some practices described in this document and presently in use
   may or may not be "best practices", especially as future standards evolve.

Or perhaps drop the statement completely. (It's axiomatic that best practices
are going to change over time.)

In 1.1 Document Conventions:

   Notation regarding structured fields is taken from [RFC5598].
  
   Organizational Domain and Authenticated Identifiers are specified in
   DMARC [RFC7489].

The first is a sentence fragment and both are incomplete. How about:

   The notation used to document references structured fields is defined in
   [RFC5598] section 1.3.

   The terms "Organizational Domain" and "Authenticated Identifier" are
   specified in DMARC [RFC7489] section 3.

There probably should be a paragraph break before the last sentence in
section 2.

The first paragraph in section 2.1 says:

   The identifiers which are used by DKIM and SPF are technical components of
   the transport process for SMTP.

This is true of SPF, which uses RFC5321.mailfrom and RFC5321.HELO/HELO. But
DKIM doesn't really take identifiers from the message and certainly not from
the SMTP transport layer.

I'm not entirely sure how to fix this since I'm not sure what this note is
trying to say. The obviou thing to do is simply remove the reference to DKIM
entirely.

The last sentence of section 2.1 says:

   The mitigations described in this document generally require the relaxed
   mode of Identifier Alignment.

Maybe I'm missing something, but I don't think this is true - in fact from what
I can tell few if any of the mitigations absolutely require relaxed mode. I
suggest changing this to read:

   Some of the mitigations described in this document only work with the
   relaxed mode of Identifier Alignment.

In section 2.1.1 we need to clarify whether "multiple DKIM signatures"
refers to multiple signatures for the same domain, multiple signatures for
different domains, or both. (Since I don't know the state of interoperability
here I can't answer this question.)

Section 2.2, second paragraph:

   "forwarding behavior involves" -> "forwarding operations involve"

In section 2.3, third paragraph the document states:

   The latter allows
   for trivial modifications (largely regarding whitespace and folding)
   that maintain the integrity of the content of the email. 

The wording here is awkward, but more to the point, this ignores space
adjustment attacks on the message body, per RFC 6376 section 8.1. I suggest
changing this to something like:

   The latter is designed to accomodate trivial modifications to 

Re: [dmarc-ietf] Moving on to our next phase?

[ned+dmarc]

> Hi Kurt,

> > On 1 Apr 2016, at 19:13, Kurt Andersen (b) <kb...@drkurt.com> wrote:
> >
> > Since we've completed the task of identifying the interoperability problems 
> > with some mitigations (phase I), is it time for us to move on to our next 
> > activity phase?
> >
> > Also, is there some admin-magic that has to happen to move a document from 
> > "draft" to "hey! all done!" status? 
> > (https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/)

> One of the chairs should do shepherding write up and request publication
> using datatracker. Or find another person who can serve as the document
> shepherd.

I'll take care of it.

> >
> > From the group charter:
> >> Phase I:
> >>* Draft description of interoperability issues for indirect mail flows 
> >> and plausible methods for reducing them.
> >> Phase II:
> >>* Specification of DMARC improvements to support indirect mail flows
> >>* Draft Guide on DMARC Usage
> >> Phase III:
> >>* Review and refinement of the DMARC specification
> >>* Completion of Guide on DMARC Usage
> >

> > I think that we need to update our target milestones a bit since they still
> > call for everything to be completed by May 2015.

> That would be great!

> Alexey,
> Who would become the responsible AD for this group on Wednesday evening.

I won't be there but may be online.

Ned

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

Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt

[ned+dmarc]

> On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote:
> >> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote:
> >
> >>> While the I-D will likely expires they will not be removed from the
> >>> website, so references will still work, so I don't see as that bad that
> >>> they are properly referenced in this document. I however agree we should
> >>> provide a quick summary for people that do not need the details.
> >>>
> >
> >> On the flipside, I don't see what value they add; the ones that gain
> >> consensus will be published in their own right, and the details of the ones
> >> that don't probably aren't interesting to later readers anyway.
> >
> > Generally speaking IETF Consensus/Publication != Adoption and Use. There 
> > are a
> > number of drafts that never made it to RFC that contain information on stuff
> > that did in fact deploy. (Although the best example of this by far  is 
> > actually
> > in X.400, where one of the most widely used text bodypart types was only 
> > ever
> > described in a preliminary draft.)
> >
> > That said, I'm dubious of the value of this section in a more general sense,
> > since in-progress work is likely to shift and change in unexpected ways,
> > which could easily make any description we provide more confusing than not.

> Somewhat agree, unless we're able to say more on the reasons why a specific
> approach failed to get broad consensus/ adoption.  I'm thinking of RFC6541, 
> for
> which the text in -10 (of the transient nature of I-Ds) doesn't hold.

> OTOH, conditional signatures have been discussed for more than five years (my
> dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha
> (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document 
> (John's
> dkim-conditional-02) which would match the charter's "form of DKIM signature
> that is better able to survive transit through intermediaries".  Can the WG
> coordinate publication of these two I-Ds?

THat's a good point. However, I have to say that while it would be nice in
theory to include information about whatever conditional scheme ends up getting
standardized in this document and/or what's in deployed code, deferring this
document in order to make that possible isn't really feasible from a process
standpoint.

Ned

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

Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt

[ned+dmarc]

> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin <fra...@peachymango.org>
> wrote:

> > While the I-D will likely expires they will not be removed from the
> > website, so references will still work, so I don't see as that bad that
> > they are properly referenced in this document. I however agree we should
> > provide a quick summary for people that do not need the details.
> >

> On the flipside, I don't see what value they add; the ones that gain
> consensus will be published in their own right, and the details of the ones
> that don't probably aren't interesting to later readers anyway.

Generally speaking IETF Consensus/Publication != Adoption and Use. There are a
number of drafts that never made it to RFC that contain information on stuff
that did in fact deploy. (Although the best example of this by far  is actually
in X.400, where one of the most widely used text bodypart types was only ever
described in a preliminary draft.)

That said, I'm dubious of the value of this section in a more general sense,
since in-progress work is likely to shift and change in unexpected ways,
which could easily make any description we provide more confusing than not.

I personally would prefer to limit this sort of thing to descrptions of
things we know are currently deployed to some degree. It's then up to
future work to describe it's own interoperability issues, which is going
to be a requirement for anything that makes it to RFC status anyhow.

And yes, this does leave the door open for something that doesn't make it to
RFC but does achieve some degree of deployment. But I think we have enough
current issues to cover without trying to detail the nature of future ones.

Ned

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

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

[ned+dmarc]

Responding to this late, but I think there are some important points not
previously covered.

> On 10/3/2015 10:08 AM, John R Levine wrote:
> > I suppose the version bump to v=2 is an open issue, but I don't really
> > see what the problem is.  Since the current spec says that unknown tags
> > are ignored, there's no way to add mandatory tags without a version
> > bump.  I believe when this came up before, people looked at common DKIM
> > libraries including yours, the perl and python ones, and found that the
> > current code would all fail a v=2 signature, so the version bump should
> > do what we want it to.


> Claiming that something is mandatory, as part of a version bump, is
> meaningless, when the installed base will be using the older version and
> ignoring the supposedly-mandatory new feature.

There's always a context to terms like "mandatory". In this case the context
is that of v2 signatures. The term is hardly meaningless in that context.

> If the installed base can legally ignore a new feature, then it is not
> mandatory.

The nature of DKIM is such that many signatures end up getting ignored as
part of normal operation. That doesn't make any aspect of the various
mandatory aspects of processing those signatures any less mandatory.

> The only way to make a feature mandatory in a new version is to provide
> it in a fashion that makes it only available to folks adhering to the
> new set of mandatory features.[*]

>  FWIW, this is equivalent to saying that adding new
>  mandatory features is equivalent to creating a new
>  protocol.

I suppose you can define it that way if you like, but doing so ignores
the substantive overlap both in terms of syntax, processing semantics, and
most important of call, usage. 

> So if you want to modify DKIM to change the set of mandatory features,
> then specify that the signature use a /different header field name/,
> such as DKIM-Signature2.  Only adherents to the new scheme will see this.

This approach has the significant downside that it's more costly in terms
of code. Not a lot more costly, and if John's proposal had significant
associated cost I'd say it's a wash.

But John's proposal isn't costly at all. As a result I'd say that of using a
different header versus building off existing version suport just about doubles
the complexity.

Given this, I need significant to see significant justification - such as
reports that existing implementations don't properly handle DKIM versions - 
before I will support a proposal to use a different field.

Such reports have not appeared AFAIK.

> If the signer wants legacy folk who only understand older DKIM to also
> be able to evaluate a signature, then the signer needs to create two
> signatures.

That's not an argument for using a different field.

Ned

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

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

[ned+dmarc]

On 9/29/2015 1:08 PM, John Levine wrote:
> I refreshed this draft so it wouldn't expire.  Not very different,
> mostly changed the @fs= to !fs= per Murray's suggestion.
>
> I still think this is the least broken way I've seen to let
> mailing lists coexist with DMARC.



I am going to look at adding support for this in our Wildcat! List
Server package. Seems simple enough via a template system. Lets see
how it works.



Thanks for keeping it alive.


FWIW, I agree that this is technology we should pursue.

    Ned

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

Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt

[ned+dmarc]

  If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non-
  aware MTA, the EAI/SMTPUTF8-aware system may transform the
  RFC5322.From header field of the message to include group syntax to
  allow the non-aware MTA to receive the email.
 
  Specifically, this sort of downgrading is only defined in the context of an
  EAI-aware POP or IMAP server returning a message to a non-EAI-aware client.
  While it's  true that such a message can be resubmitted to the transport
  infrastructure, at that point its a new message, with all that implies.
 
  An MTA performing such a downgrade in the context of handling EAI mail is
  engaging in an egregious standards violation. Talking about such standards
  violations is an interoperability document is fine, but (1) The standards
  violation aspect needs to be made clear and (2) There needs to at least some
  evidence that such things are happening on a wide enough scale to care 
  about.
 
  As such, I agree with John: This section needs to be deleted.

 I may not have read everything EAI, but I think the above is not necessarily
 spelled out in the EAI protocol,

In regards to addresses, it's spelled out very explicitly. RFC 6530, section 9:

9.  Downgrading in Transit

   The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321])
   states that due to a long history of problems when intermediate
   hosts have attempted to optimize transport by modifying them, the
   local-part MUST be interpreted and assigned semantics only by the
   host specified in the domain part of the address.  This is not a new
   requirement; equivalent statements appeared in specifications in 2001
   [RFC2821] and even in 1989 [RFC1123].

   Adherence to this rule means that a downgrade mechanism that
   transforms the local part of an email address cannot be utilized in
   transit.  It can only be applied at the endpoints, specifically by
   the MUA or submission server or by the final delivery MTA.

There's probably text elsewhere that further emphasizes the point, but I didn't
bother to look.

 and someone not knowing the history of EAI may interpret the spec quite
 differently. This is why I guess you have operational testing before an RFC 
 get
 the standard status...

I don't think cannot be transformed is in any way ambiguous.

Ned

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

Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt

[ned+dmarc]

(chair hat off)

 Please submit stuff that needs to be fixed

 The worst problem is still section 3.1.2.3 which needs to be deleted,
 since most of what it says is wrong, and what little isn't wrong is
 irrelevant.

 RFC 6854 is not about EAI, since an ASCII MUA can create mail with an
 empty group From: as easily as an EAI MUA.  The assertion that RFC
 6854 allows empty groups during the transition period to SMTPUTF8 is
 false.

RFC 6854 does mention EAI, but only as one of its possible uses. The primary
stated use is for utomated systems that wish to send email but cannot handle
replies.

 Empty group syntax has nothing to do with DMARC since there is no
 domain on the From: line to check.  From a DMARC point of view, there
 is no difference between a From: with an empty group and one with an
 address in a domain that publishes no DMARC record.

Agreed.

 This sentence is completely false.  EAI MTAs never downgrade mail in transit:

If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non-
aware MTA, the EAI/SMTPUTF8-aware system may transform the
RFC5322.From header field of the message to include group syntax to
allow the non-aware MTA to receive the email.

Specifically, this sort of downgrading is only defined in the context of an
EAI-aware POP or IMAP server returning a message to a non-EAI-aware client.
While it's  true that such a message can be resubmitted to the transport
infrastructure, at that point its a new message, with all that implies.

An MTA performing such a downgrade in the context of handling EAI mail is
engaging in an egregious standards violation. Talking about such standards
violations is an interoperability document is fine, but (1) The standards
violation aspect needs to be made clear and (2) There needs to at least some
evidence that such things are happening on a wide enough scale to care about. 

As such, I agree with John: This section needs to be deleted.

 Section 4.1.2.3 is equally wrong for the same reasons and also needs to go.

Agreed.

 Section 4.1.3.1 doesn't mention rewriting the From: address to a valid
 forwarding address in a domain for which the list can sign.  It's not
 just me doing it, LISTSERV can do that, it's widely implemented.

Our list server supports it as well, and it is being used this way. So: Agreed.

 Take
 out .invalid, nobody does that because (as I discovered and you
 mention) many spam filters dislike From: addresses with domains that
 don't resolve.

I don't mind mentioning .invalid as long as the problematic nature of 
using this mechanism is made clear.

Ned

___
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] Formal specification, URI

[ned+dmarc]

 Alessandro Vesely writes:

   If the spec is going to be read by ignorants like me, it's better
   to repeat than to omit.

 -1.  It's good that you read the spec, but that's not the primary
 purpose of the spec.  It's a bad idea to repeat definitions clearly
 stated in another document (even in informal comments on the formal
 spec) when you refer to the original document; you're just asking for
 new ambiguity.

+1. Repeating stuff like this is in the long term a surefire of silly states,
where one repetition gets updated but not another.

The running code that comes to mind is the MIME specification, which
originally had a bunch of repeated and overlapping syntax definitions. In this
case it only took one revision for it to get out of sync and cause confusion.

Ned

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

Re: [dmarc-ietf] interoperability draft for review

[ned+dmarc]

 nook and cranny out there. As such, I'm very
reluctant to make statements like there is very little reason to modify the
encoding of a message. What if there are good reasons to somwhere? Do we 
really want another round of the charset wars in this context?

And as for transport encodings, like it or not, the standards say that if 
you're in possession of an 8bit message and the system you're sending it
to doesn't support 8bitMIME, you either downgrade or bounce. Of course you
can argue that this is obsolete, but do we really want to open this 
particular can of worms in this document?

And on a similar note, try selling what 4.4.1.2 says to a financial institution
that is bound by laws saying what must be and cannot be in the messages it
emits as well as what's inbound messages destined for employees. I'm sure
they'll find it amusing.

That's it for now.

/chair hat off

Ned

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

Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it

[ned+dmarc]

 DMARC leverages the Mail From identity, so I don't see how independent HELO 
 checks can be relevant.

 If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable
 interpretation is that you check the HELO identity, and if you get a
 definitive policy result, you're done and return that to the caller.

 So a message comes from host mail.provider.com with From:
 b...@customer.com.  The recipient host does an SPF check on
 mail.provider.com, it passes, so SPF is done.  DMARC sees that the SPF
 domain isn't aligned so it ignores it, and DMARC says it's unaligned,
 even though an SPF check of customer.com might have passed.

 I can't say whether this is a bug in 7208 or a fundamental flaw in
 DMARC, but something is clearly wrong and this does not match what
 running code does.  As things are written now, I don't see any way to
 demand that SPF look at the MAIL FROM if it likes the HELO.

 Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL
 FROM check first and only do the HELO check otherwise.  This may match
 some running code, I haven't looked.

 Fix 2: change 7208 to say that SPF can return multiple results.  Ugh.

Filing an erratum for purposes of documenting the issue is fine, but since this
is a substantive change to the protocol it far exceeds the scope of what
approval of an erratum is allowed to do. As such, I believe the best outcome
you can get here would be held for document update.

Ned

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

Re: [dmarc-ietf] Jim Fenton's review of -04

[ned+dmarc]

 On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote:
  It's still not quite right:
 
  DMARC evaluation can only complete and yield a pass result when one
 
 
  of the underlying authentication mechanisms passes for an aligned
 
  identifier.  If this is not the case and either or both of them
 
  suffered some kind of temporary error (such as a transient DNS
 
  problem), the Receiver evaluating the message is also unable to
 
  conclude that the DMARC mechanism failed and thereby apply the
 
  advertised DMARC policy.  Rather, the Receiver can either skip DMARC
 
 
  processing for this message due to incomplete evaluation, or it can
 
 
  arrange to defer handling of the message in the hope that the
 
  temporary error will be resolved when the message is retried.  When
 
 
  otherwise appropriate due to DMARC policy, receivers MAY send
 
  feedback reports regarding temporary errors.
 
 
  The problem is with:
 
  If this is not the case and either or both of them suffered some
  kind of temporary error (such as a transient DNS problem),...,
  Specifically the use of either or. If only one (SPF or DKIM) has a
  transient DNS error then presumably the other, which has not had an
  error, can be evaluated (resulting in a pass or DMARC failure. It
  only becomes an issue when BOTH SPF and DKIM have concurrent
  temporary errors.  I'm thinking that removing the either or is
  appropriate. I'm still cogitating on the rest of the paragraph.


 Good catch.  This is complicated by there really being two conditions.

 The first is the negative that neither method authenticates.  The second
 is the affirmative that one of them failed with a temporary error.

 So perhaps something like:

 FROM:

  DMARC evaluation can only complete and yield a pass result when one
  of the underlying authentication mechanisms passes for an aligned
  identifier.  If this is not the case and either or both of them
  suffered some kind of temporary error (such as a transient DNS
  problem), the Receiver evaluating the message is also unable to
  conclude that the DMARC mechanism failed and thereby apply the
  advertised DMARC policy.


 TO:

 DMARC evaluation can only complete and yield a pass result when one
 of the underlying authentication mechanisms passes for an aligned
 identifier.  If neither passes and one or both of them failed due to a
 temporary error, the Receiver evaluating the message is also unable to
 conclude that the DMARC mechanism had a permanent failure and thereby
 can apply the advertised DMARC policy.

This looks good to me.

Ned

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

Re: [dmarc-ietf] thoughts re. DMARC impacts

[ned+dmarc]

Folks,


co-chair hat on


Many of us just had to deal with the impacts of DMARC on our lists.



In the aftermath, I've been participating on the dmarc-ietf email list -
trying to discuss ways to fix DMARC to better coexist with lists and
other 3rd-party services (like send this article to).



Unfortunately, it seems like the discussion is bogged down in two regards:
- the ietf-dmarc working group is charted to enhance DMARC - dealing
with its impacts is not really the focus


Please reread the charter. This is not at all what it says.

Among other things, the charter states that:

 The working group will specify mechanisms for reducing or eliminating
 the DMARC's effects on indirect mail flows, including deployed
 behaviors of many different intermediaries, such as mailing list
 managers, automated mailbox forwarding services, and MTAs that
 perform enhanced message handling that results in message
 modification. 


I don't see that as in any way in line with your assertion that the wg is not
chartered to deal with the impact of DMARC. In fact it seems to be exactly the
opposite. And in particular, nowhere in that paragraph is there any requirement
that this must necessarily be done by enhancing DMARC.


- folks want a general purpose solution


Of course they do. Unfortunately, people's desires do not magic such a solution
into existence. And if someone has described a viable and deployable
general-purpose solution, I must have missed it. So we are left with
consideration of various partial solutions and compromises.


Personally, I'd like to see a short-term solution to make our lives
easier, as list managers - sort of the way that NAT has been dealing
with IPv4 address exhaustion, while we wait for IPv6 to happen.



I've been thinking along the lines of an update to RFC2369 - the
16-year-old document defines the List-* headers.  Say by adding a couple
of headers along the lines of:
List-Original-Author: the original author
List-Original-Reply-To: the original message's Reply-To
List-Reply-To: the list-specific reply-to - either author of list



Seems to me that this would:
1. give us a standard way to find the original author (and for HTML
mail, to reply by clicking on a mailto: URL in the header)
2. provide standardized information that could be used by MUAs for
identifying, and presenting reply options (maybe leading to reply to
list and reply to author buttons starting to show up on toolbars)
3. set the stage for adding some authentication mechanisms that
accomplish what DMARC is intended to do (e.g. by adding a few more
headers that cryptographically authenticate the new List- headers and
bind them to the message body)



It strikes me that this might proceed rather quickly, if incorporated
into an RFC co-authored and submitted by folks from the mailing list
software community (i.e., the folks who'd write the patches to Sympa,
Mailman, ezmlm, etc) - particularly if some running code were to be
implemented as part of the process.  (Can you say, rough consensus and
running code?)



Reactions?  Anybody want to collaborate on a draft RFC for submission
through the independent submissions path? Any thoughts on who needs to
be involved from the Sympa community, and/or from the other mailing list
software communities?


What in the charter makes you think such a draft would be in any way
incompatible with being a product of this group? Indeed, this fits quite nicely
into phase I, which is, you know, what we're supposed to be working on now. (As
opposed to phase II, which is where we will start looking at possible changes
to DMARC itself.)

Of course the fact that this fits within our charter doesn't mean there's
consensus on this particular approach. But to that end, if you want to get
people on board, might I suggest that rather than in effect asking people to
abandon the wg effort for something else, that you instead do what countless
others have done before you, and start by writing a draft that describes your
proposal in detail so participants can assess it?

Ned

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

Re: [dmarc-ietf] wiki vs. list?

[ned+dmarc]

  -Original Message-
  From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of John Levine
  Sent: Friday, October 10, 2014 12:12 AM
  To: dmarc@ietf.org
  Cc: r.e.sonnev...@sonnection.nl
  Subject: Re: [dmarc-ietf] wiki vs. list?
 
  A more general comment: reading the wiki and the discussions on this
  list, it get the impression that we seem to focus more on the issues
  related to the 'DKIM part of DMARC' then on issues related to the 'SPF
  part of DMARC'. Is my observation correct, do we tend to forget SPF here?
 
  I agree with Scott, there's not much to say about it.  If you forward or 
  remail a
  message, the origin IP changes, and there's nothing you can do about it.
 
  Perhaps we can note that in theory the original sender could add mailing 
  list
  IPs to its own SPF, but I never heard of anyone doing that.
 

 An issue that I have been thinking on - and it is the reverse of this
 discussion - is that it is operationally difficult to maintain accurate SPF
 records for organizations with a lot of domains where the SPF records vary
 across the domains. I recently found this situation with one of our domains 
 (an
 acquisition). This is similar to other situations where organizations are
 fairly good with adds and changes but not so much with deletes. This isn't
 anything that can be addressed through an RFC but I think it is worth noting.

chair hat off

This looks to me to be an operational issue with deploying SPF at scale. This
WGs charter is pretty specific that we're focusing on issues caused by mail
that does not flow from operators having a relationship with the domain owner,
directly to receivers operating the destination mailbox. I don't see how this
fits within that scope.

So, while I'm sympathetic to the difficulties using SPF in this way,
I don't think it's in scope for the present effort.

Ned

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

Re: [dmarc-ietf] Fwd: RFC 7372 on Email Authentication Status Codes

[ned+dmarc]

Hi,



On 09/16/14 05:08, Murray S. Kucherawy wrote:
  URL: https://www.rfc-editor.org/rfc/rfc7372.txt

 This document registers code points to allow status codes to be
 returned to an email client to indicate that a message is being
 rejected or deferred specifically because of email authentication
 failures.

 This document updates RFC 7208, since some of the code points
 registered replace the ones recommended for use in that document.



I hope this is not off topic here:


(chair hat on)

It is. I've cc'ed and directed replies to the ietf-smtp list, where 
this sort of discussion belongs.


(chair hat off)


RFC 7372 proposes to use a 550 response code for reverse DNS auth
failures, see section 3.3.


Correct.


Reverse DNS checks are usually done early in the connection (like IP
blocks) in the connection establishment stage of the SMTP dialog.



RFC 5321 allows only a 554 error response there, see section 4.3.2.


You're misreading RFC 5321. Nowhere does it say that its lists of possible
responses are exhaustive. So it is perfectly permissible for RFC 7372 to
specify additional possible responses as long as they fit into the overal
theory of reply codes.

This sort of thing has been done many times.


So, shouldn't a 554 code be used here? Or does RFC 5321 need an update?


Neither. See above.

Ned

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

Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version

[ned+dmarc]

 I do not understand this predilection for trying to change the DKIM base
 engine.  It doesn't need it.

 Actually, I claim that a version bump is the approach least likely to
 break existing clients.

 I also don't understand the construct of 'special handling', never mind
 not liking the idea of it, especially since it explicitly creates the
 complexity of depends on the header field.

 I think we agree that the goal here is to have a weak signature that
 verifiers disregard unless it's associated with a delegated signature.
 Your plan, as I understand it, was that verifiers will ignore a
 signature that is too weak.  One might argue clients that accept weak
 signatures are already broken, but in that case there are an awful lot
 of broken clients, starting with spamassassin.  (I just checked.)

Out of curiousity, did you try having two signatures in various different
orders and combinations of validity?

Mind you, even if this leads to a way of structuring these things
that works for the current crop of clients, I would not be inclined to
trust it. I'm just curious.

 Until now there's been no reason other than playing games to use weak
 signatures, so in practice it hasn't mattered.  Now it does, so
 clients have to change their code to check for too weak, probably in
 inconsistent ways, to check for l= and what headers are signed and so
 forth.

Agreed. Like it or not, this calls for, let's call it a clarification
of existing DKIM semantics. And to do that you either bump the version
or overload some other existing field in the protocol.

 Murray's trick, add a new canonicalization that's only valid if
 there's a paired signature, many not require a version bump, but to be
 useful it does require a change to the verifier library interfaces.

Six of one, half a dozen of the other.

 Libraries and clients are not upgraded in sync, so there will be old
 clients calling upgraded libraries.  The libraries can't just accept
 the new canon and return valid, since old clients won't know to look
 for the paired signature.  They can't return conditionally valid,
 since clients won't know what to do with it.  So the libraries will
 need a new entry point, or at least a new option, for the client to
 say that it understands a conditionally valid result.  A few moments
 thought should confirm that's semantically the same as an option for a
 client to say it understands v2 signatures, just kludgier.

Exactly.

 With respect to Stephen's concern about libraries knowing when to
 construct v1 or v2 signatures, really, that's no big deal.  We've been
 doing that sort of stuff for version bumps since approximately
 forever, and it's a nit compared to the other stuff it'll have to do
 to interpret the conditional signatures.

 It also occurs to me that there are all sorts of ways that a
 conditionally valid signature would be useful.  For example:

 * valid if this DNS lookup resolves, for per-signature revocation

 * valid if the body has this S/MIME signature, to allow for list
 software that reformats the message but keeps the signed body part
 (mailman and mj2, for example) or that resigns with its own S/MIME
 signature (sympa)

 * valid if the body has this PGP signature (mailman's working on it)

 Some of these can be done with kludges, but most can't.

Exactly why I think that as long as we're bumping the version, building in some
additional extensibility seems like a really good idea. The only question
is how much and in what form.

Ned

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

[ned+dmarc]

   If a signature has an rsf= tag, verifiers ignore it unless there's a
   matching signature from a domain the rsf= points to.
  
   This is not backward compatible, since verifiers that don't understand
   rsf= will often get the wrong answer, so it needs a version bump.
 
 Can't both the version bump issue and the token signature issue be
 ameliorated by incorporating the token signature in the DKIM-Delegate
 field?

 Yes, you could do the equivalent of the version bump by changing the
 name of the header, but I don't see the point.

If you're going to bump the version, you need to use the opportunity to
solve the more general underlying problem.

I'm not sure I can completely characterize that problem, but it's something
along the times of there need to be some way to state the intention behind this
particular signature. Is this a signature tied to use by third parties?
Whitelisting? Something else?

Ned

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