Re: [dmarc-ietf] Reversing modifications from mailing lists
> 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
>>> 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
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
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
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
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
> 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] Ticket #55 - Clarify legal and privacy implications of failure reports
> On Tue, Dec 22, 2020 at 11:39 AM John R Levine wrote: > > I think that text is way too long and overspecific but we've already spent > > too much time on this so I'll stop and see if there are other opinions. > > > > > > On Tue, 22 Dec 2020, Alessandro Vesely wrote: > > > OLD > > > > > > "Failure reports," or "failed message reports," provide diagnostic > > > information about messages that a Mail Receiver has determined do not > > > pass the DMARC mechanism. These reports are generally sent at the > > > time such messages are received and evaluated, to provide the Domain > > > Owner with timely notification that such failures are occurring, and > > > to provide information that may assist in diagnosing the cause of the > > > failures. > > > > > > > > > NEW > > > > > > 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 extreme cases where a domain owner is unable to detect > > > why > > > failures reported in aggregate form did occur. As an extension of other > > > kinds of failure notifications, these reports can contain either the > > > content > > > of a failed message or just its header. The latter characteristic > > > entails > > > severe privacy concerns. For that reason, and because it turned out > > > not to > > > be important, failure reporting is usually disabled. > The following is factually and technically incorrect: " The latter > characteristic entails severe privacy concerns." The latter characteristic > "the header". In fact, the full message can contain much more PII and/or > PHI. Quite right. It's also unforunate that we appear to be spending more arguing about what consistutes a legitimate privacy concern than reviewing proposed text. I also note that saying what's "usually done", even if currently correct, is at best the province of a BCP. It has no business being in a standard. > I agree with John. I'll go further and say that the working group should > focus on what the IETF does best - technical specifications that involve > interoperability - and avoid straying too far into the realms of law and > politics. While the EU and GDPR may impact choices that operators make, > there are other legal jurisdictions in the world. Further, my experience > has been that many operators (receivers) only provide failure reports when > contractual relationships (direct or indirect) exist between the parties > involved. This can certainly meet the privacy requirements of GDPR and > other privacy regulations. Agreed, but none of this belongs in the standard either. All the standard needs to say is that message header and bodies can contain personally identifiable information and that this may affect the choice of whether or not to send failure reports. Something like: 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. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup
> 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
... 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
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
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
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
> 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
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
> 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
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)
on.
> >>
> >> I'm not sure how persuaded I am by this 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?
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?
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
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] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt
Given that this work is specificall for the benefit of DMARC/ARC, it makes sense to me to do the work on this list/in this group. Ned > On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker wrote: > > On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote: > > > >> -01 will be up soon, incorporating the suggested changes in prose and > >> ABNF discussed previously on this list. > >> > > > > > > If I missed this, I apologize, but would it be possible to post a message > > which summarizes the nature/goals of the changes that are planned? > > > > I'm not challenging the work, but just wanting to make sure the wg is in > > synch about how the doc should be adjusted. > > > > Thanks. > > > > d/ > The intent is outlined in high level within the -10 version (section 5.2) > of the protocol doc. The better explanation is in Seth's email from > September ( > https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0): > 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601. > Unfortunately, authres-header was defined in a way that makes this > difficult. Is there a better way to say that the AAR inherits the A-R > payload, and if anything modifies the definition of authres-header in 7601, > the AAR also needs to inherit this change? > To be super specific, this is the current authres-header ABNF from 7601: > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > Optimally, there would be: > authres-payload = [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > And then we could have: >arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info > authres-payload > --Kurt ___ 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
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
> 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
> > > > > 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
> On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman > 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] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts
Let's break this down. If we're going to include recipients in the DKIM signature, it seems we have at least three key design decisions to make: (1) Whether or not to (a) Enumerate the recipients, or some representation of them, outside the DKIM hash, and sign that, or (b) Include the recipients, or some representation of them, under the DKIM hash only and don't expose them otherwise. (2) Whether we enumerate recipients as: (a) Cleartext (b) Hashes (c) Encrypted form (d) Some combination of forms Note that (2)(b)-(d) are still choices even in the case of (1)(b). (3) Whether or not the recipient check is an (a) mandatory or (b) optional part of the validation operation. (If you change what's signed in some way it's effectively mandatory, if you add a header containing either the hash of the recipients or a representation of the recipients and include it in the DKIM signature in the normal way it's optional.) Now, in regards (1), I have to say I regard (1)(b) as a complete nonstarter, for all the reasons previously given. The complete lack of control the sender has over how recipient lists get split along the way has the potential to cause all sorts of subtle failures. And given past behavior I don't trust senders using this feature to use mitigations like single recipient messages when necessary. In fact I skeptical most senders will even understand the issues in play well enough to do the right thing. I also categorically reject arguments along the lines of "this problem only happens outside the intended use cases for this capability so we don't need to worry about it". Given the way DMARC has deployed it would be utter folly to base our design decisions on limited use case claims. This is especially true since this mechanism can be employed, albeit in a crude way, to try and prevent people from forwarding messages the message sender doesn't want them to forward. And I absolutely can see people noticing this capability and trying to use it. In fact given the history here it's going to be seriously tempting to view (1)(b) as yet another attack on existing email infrastructure, with all that implies. I'll also note that the implicit claim that the (1)(b)/(2)(a) combination avoids exposing recipient information is in fact false. A simple counterexample would be a message to a single Bcc: recipient in addition to the whoever is listed in the various headers. If I receive such a message I can simply perform the DKIM operation on the recipients listed in the headers, and if it doesn't match I know there's a Bcc:. I then try inserting possible Bcc: recipients into the list until I get a match. And in many cases I'll have a pretty good idea what addresses to try, so in those cases this attack will be many, many, many orders of magnitude more effective than brute force. I believe this last point makes (2)(a) a nonstarter regardless of how (1) is answered. As for whether or not (2)(b) or (2)(c) makes the most sense, the fact that in many cases a recipient can come up with a list of likely addresses to try as noted above is a really serious problem for any hash-based scheme. I'm not exactly wild about the idea of all the public key operations (2)(c) calls for, but I'm even less enthusiastic about adding to the reicpient leakage problem in any way. As for (2)(d), I see little point in using it in conjuction with (2)(b) - it's much simpler to hash them all and be done with it. The combination of (2)(c) and (2)(d), however, has the potential of eliminating some/most of the public key overhead. (Another variation would be to use (2)(c) when a public key is available and (2)(b) when it isn't.) And that brings us to (3). It's important to note that making recipient checks a mandatory part of validation doesn't make enforcement mandatory - a reciever can simply detect and ignore DKIM signatures that require recipient checks. The capability optional recipient validation provides is that a receiver has the option of using the signature in the usual way. (That, and backwards compatibility.) Finally, I note that there is in fact a (0): (0) This scheme can be applied to (a) Any message (b) Single recipient. Requiring separate copies for each recipient in order to cover the recipient with a signature renders (1) and (2) moot. In fact this scheme is so simple that it merits serious consideration. The big problem I see with (0)(b) is the overhead it imposes downstream. But as I noted previously, so many messages are already sent separately to different recipients it's unclear to what extent this is a factor. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts
> 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)
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
> 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?
> On Fri, Jun 3, 2016 at 3:44 PM, Barry Leiba 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)
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
> On Wed, May 11, 2016 at 1:45 PM, 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
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 whites
Re: [dmarc-ietf] Moving on to our next phase?
> Hi Kurt, > > On 1 Apr 2016, at 19:13, Kurt Andersen (b) 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
> 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
> 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.
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
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
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
> > >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
(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
> >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
> 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
bout how it's actually used or refer to some place that does. The Internet is a big place, and none of us are in a position to fully assess the state of play in every 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. 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
> >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
> 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] draft-kucherawy-dmarc-base feedback
but the realities are what they are. > > > Given all that, here's my suggested revision to Section 5.6.1.: > > > > > > - > > > 5.6.1. Extract Author Domain > > > > > > In order to be processed by DMARC, the domain(s) must be extracted from > > > the domain of the email address(es) within the addr-spec portion of the > > > RFC5322.From field. If the domain is encoded with UTF-8, the domain name > > > must be converted to an A-label for further processing. If no domain is > > > found, the message SHOULD be rejected (as it is forbidden under RFC 5322 > > > > I still don't think a null From filed is any business of DMARC the > > protocol. That's really an issue for (a) the security considerations > > section or (b) the planned BCP. > > > I think we're all in agreement on that point so far. > > > [MAIL]). If more than one domain identifier is found, the full set of > > > domains MAY be collected as a set of identifiers for DMARC processing. > > > > But this seems to be the insecure approach I describe above: > > > > >5. Conduct identifier alignment checks. With authentication checks > > >and policy discovery performed, the Mail Receiver checks if > > >Authenticated Identifiers fall into alignment as described in > > >Section 3. If one or more of the Authenticated Identifiers align > > >with an identifier extracted from the addr-spec of the > > >RFC5322.From domain, the message is considered to pass the > > >DMARC mechanism check. > > > > AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to > > send spam that passes DMARC on your behalf, as long as my mailbox appears > > in From, too. Am I misunderstanding your proposed algorithm? > No, because in (6) the strictest rule applies. Your throwaway domain might > pass, but the other advertised author's would not. Agreed. > > >All other conditions (authentication > > >failures, identifier mismatches) are considered to be DMARC > > >mechanism check failures. > > Bottom line, I think both messages where no Authenticated Identifiers can > > be extracted and those where multiple Authenticated Identifiers can be > > extracted should be defined to be mechanism check failures. In the former > > case, policy discovery is impossible, in the latter, the strictest policy > > should be applied. > Right, I think that's what Trent is also saying. > And everyone seems to agree on just dropping STARTTLS as well. Good. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
> >What sort of remedy would you suggest here? Off the top of my head, here > >are some suggestions: > > > >1) Evaluate all the domains you find, and if any of them have published > >DMARC policies, apply the strictest one ... > Given the anti-phishing goals of DMARC, I don't see how anything else > makes any sense. Or you could skip a step, say that DMARC doesn't > permit multi-address From headers, assume that validation failed on > all of the domains and proceed directly to the punishment phase. That's fine if any of the domains have an associated DMARC record - of any sort. My concern is the case where none of them do, or when there are no domains present. > For From: headers with address-free groups, recall that the motivation > for this was EAI downgrades at delivery time. The un-downgraded > message had a normal From: header, so normal DMARC applies. If the > address is smashed in the downgrade I don't see any reason that the > DMARC result needs to change. Neither do I. > It also happens to enable an alternative to those > do-not-re...@bigbank.com addresses in mail from robots, something I > haven't seen yet, but wouldn't be totally silly. I'd say that > whatever you do with them is out of scope for DMARC. That's exactly my position. If you want to reject them on the basis that the mess up user agents, you have a pathological hatred of group syntax, or whatever, fine. Local policy choices always win. But DMARC should not be saying that valid things should be rejected when there's no DMARC records in sight. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
eiver MUST communicate reports using the method described in [STARTTLS] whenever it is offered by a Report Receiver. I seriously question the value or appropriateness of this paragraph. So your DMARC agent, assuming it actually goes through a SUBMIT server and not through an internal API, uses STARTTLS to secure that connection. Now what? At present there's no standardized way to indicate in a message that it has to be transported securely. So if you really want that, that leaves configuration - a configuration that spans an essentially arbitrary set of transport agents, to enforce this. At least part of which would have to be enforced by the target of the mailto: to have any chance of being effective. It's poor practice to have MUSTs in specifications that we know are going to be ignored. It's also poor practice to have MUSTs that don't actually accomplish much of anything as written. As such, I strongly recommend dumping this, or at least making it a SHOULD. BTW, I took a glance at the source for opendmarc-reports. I don't see any place where it even tries to use STARTTLS, let alone requires it when talking to something other than the local host, which is supported via command line parameters. Section 9.3 recommends using reply codes during the SMTP session rather than doing anything that would require sending a DSN later, but doesn't come out and say that the reason for doing this is to avoid blowback spam. I think it would be clearer to be explicit about why these policies are a good idea. That's it! Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] End of thread! was: Re: wiki vs. list?
> > On Oct 29, 2014, at 7:20 PM, Hector Santos wrote:
> >
> > If they are going to rewrite, then at the very least we MUST make 3rd party
> > protocol options and algorithms available as well to ALL implementators as
> > part of the DMARC protocol to complete the total picture.
> Hi Hector, this thread is no longer productive to the work that this working
> group needs to immediately accomplish. What you're referring to is more
> properly part of a latter phase/milestone, but first the WG needs to finish
> compiling the actual list of "indirect email flows".
> The WG is focused now on compiling this list to avoid issues that arise when
> the problem space is too narrowly defined. Unfortunately this means you need
> to wait for the WG to catch up to you. To make sure the WG isn't delayed,
> I'm asking for reviews of the current work:
> http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki
> Anything else right now is simply a distraction.
> 1/2 of the WG Chair,
+1 from the other 1/2.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] thoughts re. DMARC impacts
Folks, 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: List-Original-Reply-To: List-Reply-To: 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?
> >> 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. > > > > > I was surprised to see you take your chair hat off when responding to a > discussion of scope. Being still fairly green when it comes to IETF process > I’m not sure about this, but I would have presumed one role of the chair is to > help ensure the WG stays within its approved scope. Your presumption is correct. > I’m asking about thi because I believe managing scope is critically > important to the success of this WG and I’d like to know who plays what > role in helping us stay on track. Thank you. That would be the chairs. > > This looks to me to be an operational issue with deploying SPF at scale. > > This > > WG"s 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 > The charter also states the WG "will also provide technical implementation > guidance and review possible enhancements elsewhere in the mail handling > sequence that could improve DMARC compatibility.” While I’m personally not > too > concerned about deploying SPF at scale, I am concerned about this particular > aspect of the charter and preserving it. If we forget this aspect of our > charter then we are left with nothing in our toolbox but to change DMARC > itself > to accommodate MLM’s and other "mail that does not flow from operators having > a > relationship with the domain owner, directly to receivers operating the > destination mailbox” with no ability to at least “guide” other processors > toward practices that would help them improve their compatibility with DMARC. So let me see if I understand you correctly. You were surprised that I posted a query (not an assertion) about something being in scope in my capacity as a WG participant rather than as chair. And you are concerned that there be effective scope management. But at the same time you're concerned that we not tighten the scope so much as to exclude implmentation guidance that you view as an important tool in addressing DMARC issues. If that's correct, then I confess I completely fail to understand your concern/point here. The reason I posted as a participant and not as chair was precisely because I *didn't* want to make an ex cathedra statement about the appropriateness of discussing this SPF issue. What I wanted was feedback as to whether or not people consider SPF deployment advice on this issue to be in scope of the WG. I received one private response to that agreeing that it isn't in scope and notihng on the list. And since public discussion of that point has ceased, further consideration of the matter seems moot. Finally, in regards to the implementation advice aspect of our work, and again speaking as a participant, I don't see how this particular issue meets the criteria for that either since it has everything to do with not sending out bogus SPF information and nothing to with with the interaction of SPF with DMARC. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] wiki vs. list?
> > -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. This looks to me to be an operational issue with deploying SPF at scale. This WG"s 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
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] Milestones changed for dmarc WG
On 8/30/14 12:52 AM, Stephen J. Turnbull wrote: > Pete Resnick writes: > >> Good point: >> >> Mar 2015Complete draft specification on DMARC improvements to better >> support indirect email flows > > Up to this point the discussion on the dmarc mailing list has focused > on alternative channels (Otis's TPA-labels, Kucherawy-Crocker's > DKIM-Delegate) for communicating authorization, not changes to DMARC. > > Given that *all* of these specifications focus on authorization rather > than denial with the single exception of DMARC's p=reject/quarantine, > it's not obvious to me that improvements to DMARC are needed/feasible > beyond acknowledging existence of other authorization protocols to > which recipient policy may give precedence. > > How about s/DMARC improvements/protocol improvements/ ? If necessary, > a nod to "including changes to DMARC" could be added. > While I agree in principle, this is a distinction that is likely to be lost on people outside of the WG. "DMARC improvements" in the charter was meant to encompass possible changes to the DMARC spec, deletions from the DMARC spec, and additions to the DMARC spec (e.g., extra header fields in the message meant to indicate to implementations to do something different than the current DMARC spec says to do). I think most folks would understand all of those to be "DMARC improvements", whether or not they actually call out a change in the base spec. We in the WG understand what we mean, and we can certainly be clear about it in the wiki. But I see no need for a change to the milestone text. I'm in agreement with Pete. I also fail to see why people not familiar with the group are going to spend time drawing conclusions from reading the milestones in isolation, and in the unlikely event they do, why we should care. 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
> >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
If a signature has an rsf= tag, verifiers ignore it unless there's a
matching signature from a domain the rsf= points to. ...
> 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?
That's what the rsf is supposed to mean.
I understand that. The question is what happens when another, similar
proposal comes along. Unless I'm missing something, rsf is quite specific
to this delegation proposal.
I suppose we could factor it out and do a version bump and add a new
"conditional signature" cs= field, which means that a verifier only uses
this signature if the conditions are met. There's a registry of cs field
values, and if there is a cs field whose condition isn't satisfied, or
that the verifier doesn't know about, the verification fails.
That's one of the axes we could proceed along. The other would be
to focus instead on the purpose of the signature, and make the conditions
part of that.
I don't know which is better. There's a serious design decision to make here.
So it'd be something like this:
DKIM-Signature: v=2; ... cs=fwd; ... ft=t,c,foo.example
That is, the condition is that it's also signed by one of the targets in
the forwarding target "ft=" field. ("t" and "c" are the to and cc
headers, on the perhaps overoptimistic theory that there will never be
single letter TLDs.)
You can safely add new cs values without a version bump, since the
verifiers will fail until they've been upgraded to understand them.
Yes, that's the general idea. But I'm not sure this is the right way to do it.
___
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
> > > 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
