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 tracker contains a few i

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 ambiguity, correcting min

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 If a domain publishes a "p=reject/quarantine" (restrictive policy), the published intent and expectation is to reject or quarantine failures. If the receiver wishes to further relax how it ha

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 >> >> possibility of still getting deliv

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

One would be a spec revision to deal with ARC. Does DMARC still 'fail'? Yet the whole point of ARC is to create the possibility of still getting delivered, in spite of this. My position on this is that the decision by a validator/mailbox provider to use ARC and accept mail that would oth

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

On 3/13/2018 9:42 AM, Dave Crocker wrote: On 3/12/2018 6:57 PM, Barry Leiba wrote: Not all 25 minutes are for that; that is included in the time slot, along with anything else we put into "next steps". ... I do expect that we'll discuss "path toward a Proposed Standard version of DMARC," and I

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

On 3/12/2018 6:57 PM, Barry Leiba wrote: Not all 25 minutes are for that; that is included in the time slot, along with anything else we put into "next steps". ... I do expect that we'll discuss "path toward a Proposed Standard version of DMARC," and I'll put that into the "next steps" section

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 di

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

On Sat, 28 Mar 2015 04:07:51 +0900, "Stephen J. Turnbull" 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 indirect mail

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

On Friday, March 27, 2015 09:12:19 PM J. Gomez wrote: > > Isn't DMARC holding itself to a different standard? What's a receiver > > supposed to do with unaligned mail whose "From:" domain specifies > > p=reject? Clearly, the domain owner is explicitly asking that the > > message be rejected. If D

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

On Friday, March 27, 2015 12:12 AM [GMT+1=CET], Michael Jack Assels wrote: > On Thu, 26 Mar 2015 15:23:08 PDT, > "Murray S. Kucherawy" wrote: > > > On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez > > wrote: > > > > > That is why, in my view, DMARC's p=reject has to either be > > > reliable to be re

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

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 indirect mail flows, and that it's up > to MLM developers (and other producers of indirect

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

On Fri, 27 Mar 2015 15:22:04 +0900, "Stephen J. Turnbull" 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 sender, the

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* tha

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

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

On Thu, Mar 26, 2015 at 11:59 PM, Murray S. Kucherawy 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 > everywhere, and

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

On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull wrote: > Murray's point is that "proof of illegitimacy" is probably a pipe > dream, as shown by past experience with "policy frameworks".[1] > Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows > in daily use by financial i

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

- Original Message - > From: "Stephen J. Turnbull" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Thursday, March 26, 2015 10:28:18 PM > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > Franck Martin writes: > > >

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 in

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)

- Original Message - > From: "Steven M Jones" > 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

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 h

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

- Original Message - > From: "Michael Jack Assels" > To: "Murray S. Kucherawy" > Cc: dmarc@ietf.org, "J. Gomez" > Sent: Thursday, March 26, 2015 4:12:13 PM > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > On Thu, 26 Ma

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

On Thu, 26 Mar 2015 15:23:08 PDT, "Murray S. Kucherawy" wrote: > On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez 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 and be done > > with costly email

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

On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez 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 and be done > with costly email. > > That is why, in my view, DMARC's p=reject has to either be reliable to

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

- Original Message - > From: "J. Gomez" > 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 tells you, you sh

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 > (which is a financi

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

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 (which is a financial institution and uses that domain for transactional mailflows), has at least once used his

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 ad

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

On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez 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 in a row when s

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

from mine, I hope I didn't gaffe it...) Original 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 wrote: > >> I know for su

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 authenticati

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

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 obvi

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 5

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 had

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 ha

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 assumpt

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 Mar 24, 2015, at 2:19 PM, Anne Bennett wrote: > > Michael Hammer writes: > >> A person who used to be active in the email space once >> told me that the extent to which messages are placed in >> quarantine/junk/spam folders is a reflection of how well >> or poorly the systems evaluating the

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

On Tue, Mar 24, 2015 at 2:19 PM, Anne Bennett 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 mailing > lists, m

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

Michael Hammer writes: > A person who used to be active in the email space once > told me that the extent to which messages are placed in > quarantine/junk/spam folders is a reflection of how well > or poorly the systems evaluating the mail work. If it works > really well then nothing should end

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

On Tue, Mar 24, 2015 at 2:08 PM, MH Michael Hammer (5304) wrote: > > No, p=quarantine is a problem WE cause. All these experts and algorithms > can't figure it out so we toss it in quarantine/junk/spam folder and then > tell the user to figure it out. WE cause the problem. A person who used to >

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:47 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET

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]

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

On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez 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 > p=reject. > I'm n

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

On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET], Anne Bennett wrote: > > In practical and operational terms, the point of all this is to > > allow filtering engines to make better decisions about > > possibly-spoofed mail. > > ... and again, if those decisions result merely in rejecting a > messa

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 se

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

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 is ugly to > boot. Wel

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)

Dave Crocker responds to my suggestion: >> rfc6376 has: [...] >> Would it be so awful to change that to: >> >> Note that Verifiers may treat unsigned header fields (or >> unsigned parts of header fields) with extreme skepticism, >> including refusing to display them to the end user, displa

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 r

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)

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 ab

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)

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. >

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 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

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 usele

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 lis

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:" h

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

> -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Anne Bennett > Sent: Monday, March 23, 2015 4:08 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > > Dave Crocker writes: > > > As alw

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

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 meani

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

On Sat, Mar 21, 2015 at 5:45 PM, Dave Crocker wrote: > > > And note that without DMARC, these days users typically don't see > > > the domain. In other words, it isn't presented to the user. This > > > inconvenient fact is ignored or dismissed every time someone touts > > > the user's role i

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

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.

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

On Sunday, March 22, 2015 9:25 PM [GMT+1=CET], John Levine wrote: > > 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? > > M

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 no

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

J. Gomez writes: > It's about time that MLM software that modifies the in-flight > message, rendering its DKIM signature invalid, takes ownership as > Author of the new modified message they are resending. Not going to happen. GNU Mailman list owners have had the option since November 2013, m

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

On 3/22/2015 1:39 PM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > Folks tend to promote DMARC's choice of From field due to the fact > > that it's presented to the end-user, as if the end-user will behave > > differently with DMARC active. The end-user won't. > > I haven't noticed

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

Dave Crocker writes: > Folks tend to promote DMARC's choice of From field due to the fact > that it's presented to the end-user, as if the end-user will behave > differently with DMARC active. The end-user won't. I haven't noticed anybody advocating that. The claim is that the user behavior

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

On Sun, Mar 22, 2015 at 8:06 AM, J. Gomez wrote: > I consider that any "3rd party authorization scheme" for DMARC will fail > --not to fail technically, but to fail be implemented in the real world-- > if it happens to need, to be workable, the nuanced and labour-intensive > participation of the

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 s

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 e

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

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

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 add

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 wr

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

On 3/21/2015 12:23 AM, Murray S. Kucherawy wrote: > In particular, it does not matter what user's 'see'. The information is > processed by a filtering agent, independent of the user. > > So what matters is that the From: field domain is the > only field certain to be pro

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

On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker 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 be of benef

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

Dave Crocker writes: > 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 be of benefit. > > > I'd like to tr

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 yo

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

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 be of benefit. I'd like to try to get us to phrase this differently. I

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

On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez 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 extra notch of

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

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 t

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

On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink 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 really see every time, I'm

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

m: dmarc [mailto:dmarc-boun...@ietf.org] 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, t

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

marc [mailto:dmarc-boun...@ietf.org] 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 W

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 https://tools.ietf.org/htm