Re: [dmarc-ietf] "next steps?"

On 3/15/2018 7:01 AM, Tim Draegen wrote: On Mar 13, 2018, at 9:42 AM, Dave Crocker > wrote:   Phase III:  Review and refinement of the DMARC specification Is there technical work on the base specification that would improve it? The bug

Re: [dmarc-ietf] "next steps?" (was: Re: Agenda for IETF 101 DMARC session)

On Mar 13, 2018, at 9:42 AM, Dave Crocker wrote: > >> Phase III: >> Review and refinement of the DMARC specification > > Is there technical work on the base specification that would improve it? The bug tracker contains a few items around clarification, removing

Re: [dmarc-ietf] "next steps?"

On 3/14/2018 5:37 PM, Brandon Long wrote: On Tue, Mar 13, 2018 at 3:44 PM Hector Santos

Re: [dmarc-ietf] "next steps?"

On Wed, Mar 14, 2018 at 2:37 PM Brandon Long wrote: > > > > On Tue, Mar 13, 2018 at 3:44 PM Hector Santos wrote: > >> >> >> >> One would be a spec revision to deal with ARC. Does DMARC >> >> still 'fail'? Yet the whole point of ARC is to create the >>

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Murray, Thanks for your comments. The key difference today is that we have finally achieved the long term engineering considerations of: 1) Getting domains to publish DNS policy records, 2) Receivers performing the DNS policy record lookup, 3) Receivers honoring the mail handling. We

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Thu, Mar 26, 2015 at 11:59 PM, Murray S. Kucherawy superu...@gmail.com wrote: There are those among you that disagree, I know. Does anyone have actual data (not theory, not passion, but data) that any of the policy or third-party solutions we've discussed before can work, work just about

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Michael Jack Assels writes: I can't think of any. Some, many, or most of them were supposed to be, but it has never turned out that way. I don't know why DMARC is being held to a different standard. Isn't DMARC holding itself to a different standard? That's a reasonable

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Murray S. Kucherawy writes: Does anyone have actual data (not theory, not passion, but data) that any of the policy or third-party solutions we've discussed before can work, work just about everywhere, and work at scale? Speaking only for myself, at this stage I would accept *theory* that

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Franck Martin writes: Hard Bounce: no such mailbox/user/email address here (SMTP enhanced status code, like 5.1.1), usually a permanent failure Soft Bounce: there may be a valid mailbox/user/email address here, but we are not accepting this email (SMTP enhanced status code like 5.7.1),

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Fri, 27 Mar 2015 15:22:04 +0900, Stephen J. Turnbull step...@xemacs.org wrote: Michael Jack Assels writes: What's a receiver supposed to do with unaligned mail whose From: domain specifies p=reject? Whatever they want to. If they think they can do filtering better than the

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Sat, 28 Mar 2015 04:07:51 +0900, Stephen J. Turnbull step...@xemacs.org wrote: Michael Jack Assels writes: As I read it, that means AOL and Yahoo are taking the position that DMARC's p=reject is The Right Thing To Do, while accepting that it's going to give wrong answers for

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Franck Martin writes: 2) Mailing lists should be able to differentiate between an Hard bounce and a Soft bounce (by now). http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml is 7 years old now. They can, but the problem that caused

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Thursday, March 26, 2015 3:08 AM [GMT+1=CET], Hector Santos wrote: SPF had a strong REJECTION concept with RFC4408 and with the latest spec RFC7202, it was relaxed with allowing for quarantining ideas (mail separation). RFC7208 made RFC4408 more costly by adding more complexity for an

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Thursday, March 26, 2015 4:08 AM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: But I would love to be able to reliably rely on DMARC's p=reject. Even if you can in practice, you can't get to 100.0%. Even at ducks-in-a-row sites like

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

- Original Message - From: J. Gomez jgo...@seryrich.com That is why, in my view, DMARC's p=reject has to either be reliable to be relied on, or be suppressed from DMARC's formal specification if it is going to mainly be equal to p=do-whatever. when you see a p=reject and DMARC

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 03/26/2015 04:22 PM, Franck Martin wrote: What I learn for all the combinations: It does not change much, people still ignore my posts :P Franck, that's wy outside the charter of this working group... ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

- Original Message - From: Steven M Jones s...@crash.com To: dmarc@ietf.org Sent: Thursday, March 26, 2015 4:38:08 PM Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On 03/26/2015 04:22 PM, Franck Martin wrote: What I learn for all the combinations: It does not change

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Thu, 26 Mar 2015 15:23:08 PDT, Murray S. Kucherawy superu...@gmail.com wrote: On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez jgo...@seryrich.com wrote: If DMARC is going to increase support costs for small email operators, I may as well migrate all my clients to Google Apps or Office 365

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

- Original Message - From: Michael Jack Assels mjass...@encs.concordia.ca To: Murray S. Kucherawy superu...@gmail.com Cc: dmarc@ietf.org, J. Gomez jgo...@seryrich.com Sent: Thursday, March 26, 2015 4:12:13 PM Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On Thu, 26 Mar

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Tuesday, March 24, 2015 10:08 PM [GMT+1=CET], MH Michael Hammer (5304) wrote: On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET], Anne Bennett wrote: ... and again, if those decisions result merely in rejecting a message, the user isn't involved, but as soon as those decisions can

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Tuesday, March 24, 2015 10:32 PM [GMT+1=CET], Steve Atkins wrote: Mailing lists are only an issue if the domain owner of the email addresses of the participants have published a DMARC p=reject record, despite having actual users who are legitimate source of email that fails authentication.

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Message From: Murray S. Kucherawy To: J. Gómez Cc: dmarc@ietf.org Sent: Tuesday, March 24, 2015 10:01 PM Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez jgo...@seryrich.com wrote: I know for sure I will publish only p=none for my client's

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez jgo...@seryrich.com wrote: No. It is unreliable for Receivers to apply it. Sure, for the Sender p=reject is perfectly reliable, if he happens to have all his ducks neatly in a row. But the Receiver cannot know if the Sender has all his ducks neatly

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Mr. Gomez, Traditionally, many in the IETF and the mail industry had an aversion towards strong deterministic transport (system) level filtering ideas. This is burned into RFC2821/5321: 7. Security Considerations 7.1 Mail Security and Spoofing This specification does not further

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Tuesday, March 24, 2015 1:54 AM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. This is

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 3/24/2015 1:02 PM, Stephen J. Turnbull wrote: Dave Crocker writes: A mailing list typically defines a 'community' for discussion. At least some of the modifications it does are to assert that community in some visible ways. Sure, but From-munging is not an assertion of

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 03/24/2015 01:38 PM, J. Gomez wrote: I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 3/24/2015 10:59 AM, Anne Bennett wrote: Dave, You make an assumption about user assumptions. Forgive me, but I doubt you have a reliable, objective, empirical basis for making that assertion or much that derives from it. In fact there's a reasonable chance that your assumption is

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Tue, Mar 24, 2015 at 2:19 PM, Anne Bennett a...@encs.concordia.ca wrote: But yes, the ideal situation is where we sort every message correctly and unambiguously. Meanwhile... Even if we grant that p=quarantine is a problem WE cause, the fact is that until we have a *good* solution for

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Dave, You make an assumption about user assumptions. Forgive me, but I doubt you have a reliable, objective, empirical basis for making that assertion or much that derives from it. In fact there's a reasonable chance that your assumption is flawed. I have a 24-year-long parade of users

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

J. Gomez writes: I think we are not talking about the same thing: when I said depends on DMARC's success, I meant depends on DMARC's success as an implemented technology in the real world, whereas it seems you understood depends on a successful DMARC check. No, we are talking about the

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

For nearly 10+ years we have discussed the same basic design issues. Nothing has changed other than the fact it is DMARC, as it is currently written as the replacement protocol for a DKIM POLICY SSP/ADSP framework, is very lacking intentionally. We don't have enough of the advocates we once

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

J. Gomez writes: On Tuesday, March 24, 2015 7:02 PM [GMT+1=CET], Stephen J. Turnbull wrote: From-munging is hardly open-and-shut philosophically legitimate. It has its advocates, but it sucks for many users because of the way their MUAs handle it, it arguably violates RFC 5322, and

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Steve Atkins writes: Mailing lists are only an issue if the domain owner of the email addresses of the participants have published a DMARC p=reject record, despite having actual users who are legitimate source of email that fails authentication. False. Mailing lists only have an obvious

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

J. Gomez writes: given that the traditional practice of mailing lists adding tags to Subject and footers to the message body breaks DMARC, [...] I vote for steam-rolling mailing lists configured old-style to the history books. Mailing list operators just need to take ownership in the

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 3/24/2015 11:23 AM, Anne Bennett wrote: In most cases it would be inappropriate for mailing lists to take ownership of the messages. They are merely the distribution mechanism, and wrecking (IMHO) the From: header to avoid a verification failure seems the wrong way to go in the long run,

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: I think we are not talking about the same thing: when I said depends on DMARC's success, I meant depends on DMARC's success as an implemented technology in the real world, whereas it seems you

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez jgo...@seryrich.com wrote: I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Dave Crocker writes: A mailing list typically defines a 'community' for discussion. At least some of the modifications it does are to assert that community in some visible ways. Sure, but From-munging is not an assertion of community, it's an assertion that there's a war out there, and

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

-Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of J. Gomez Sent: Tuesday, March 24, 2015 4:39 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 3/23/2015 3:15 AM, Murray S. Kucherawy wrote: I'm not disagreeing, but I'm not sure where you're going with this... As always, I'm seeking to have thinking and discussion focus on software behavior, not user behavior. Any discussion of end user perception or behavior is distracting to

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

J. Gomez writes: But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox? I don't see why enabling mailing lists to continue

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Anne, On 3/23/2015 3:07 PM, Anne Bennett wrote: But if the message is delivered, either because it passes DMARC, or it fails but is quarantined, then the receiver will see the message, and will make assumptions regarding the authenticity of its origin based, most likely, on the From: header.

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Dave Crocker writes: As always, I'm seeking to have thinking and discussion focus on software behavior, not user behavior. Any discussion of end user perception or behavior is distracting to meaningful analysis or development of technologies like DMARC. I can't entirely agree, though I'm

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Monday, March 23, 2015 7:02 AM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s)

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. Rehashing old arguments will not change anyone's mind. False assertions are like these are utterly useless.

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Monday, March 23, 2015 10:45 PM [GMT+1=CET], John Levine wrote: Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. Rehashing old arguments will not

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

J. Gomez writes: Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. This is an error of logic. *Authenticity* (defined as did the message satisfy DMARC

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Saturday, March 21, 2015 3:36 PM [GMT+1=CET], Hector Santos wrote: As a long time total mail system product(s) developer, at this point, IMV, we have a marketing problem. We did have technical solutions laid out with 3rd party authorization concerns. However, it hasn't been sold enough

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Saturday, March 21, 2015 10:31 PM [GMT+1=CET], John Levine wrote: How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? The numbers I've seen say that the volume of mail that DMARC screws up

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox? My impression is that most users put a very low value on commercial bulk mail. I'm not

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Dave Crocker writes: On 3/22/2015 1:39 PM, Stephen J. Turnbull wrote: I took you to mean that the relationship between the purported identity in From, based on the address in that field, and the user's behavior is irrelevant to specification of DMARC and related protocols. I

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker d...@dcrocker.net wrote: On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote: And since the From field is the only one users really see every time, I'm not sure that declaring and supporting yet another no-seriously-this-is-the-author field would

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Dave Crocker writes: From: happens to be the only place that always has the presence of a domain associated with the origin. Except it doesn't always have a domain associated with the originating MTA, and there's nothing in RFC 5322 that says it does. RFC 5322 says you shouldn't put an

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

As a long time total mail system product(s) developer, at this point, IMV, we have a marketing problem. We did have technical solutions laid out with 3rd party authorization concerns. However, it hasn't been sold enough and if even if you do work it, you have to champion it. One can't

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? The numbers I've seen say that the volume of mail that DMARC screws up is fairly low, but it is very high value. Personally, I would be happy never to

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On 3/21/2015 9:41 AM, Stephen J. Turnbull wrote: Dave Crocker writes: From: happens to be the only place that always has the presence of a domain associated with the origin. Except it doesn't always have a domain associated with the originating MTA, Well, I said 'origin' and not

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

J. Gomez writes: Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? Because they *can't* be adapted by definition. DMARC p=reject prohibits indirect mail, and p=quarantine sends it to the spam bucket. Or perhaps you're

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Wednesday, March 18, 2015 11:40 PM [GMT+1=CET], Douglas Otis wrote: Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows Why is it better for DMARC to be

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Friday, March 20, 2015 09:56:15 PM J. Gomez wrote: On Wednesday, March 18, 2015 11:40 PM [GMT+1=CET], Douglas Otis wrote: Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez jgo...@seryrich.com wrote: Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows to be kept old-style, or the

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink tz...@exchange.microsoft.com wrote: If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution? +1. And since the From field is the only one users

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows These are reviewed by https://tools.ietf.org/html/draft-dmarc-interoperability-00

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

] On Behalf Of Douglas Otis Sent: Wednesday, March 18, 2015 3:41 PM To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve