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

[Dave Crocker]

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 items around clarification, removing 
ambiguity, correcting minor mistakes. Nothing major.


I was expecting someone to come up with a new tag that defined a 
mechanism for exception querying. EG, I have a piece of email that falls 
under a DMARC record where the Domain Owner is telling me I can query 
some resource to figure out if the identifier combination is OK. Aside 
from hallway conversation, haven't seen anything like it yet.


Hmmm.  Could you describe this in a bit more detail?  Not an actual 
spec, but to give more of a sense of what it could do and why it would 
be helpful (ie, what current problem it alleviates)?




d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Tim Draegen]

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 minor mistakes. Nothing major.

I was expecting someone to come up with a new tag that defined a mechanism for 
exception querying. EG, I have a piece of email that falls under a DMARC record 
where the Domain Owner is telling me I can query some resource to figure out if 
the identifier combination is OK. Aside from hallway conversation, haven't seen 
anything like it yet.

>>  Completion of Guide on DMARC Usage
> 
> What will it take to complete this doc?

Focus & cycles. The document is meant for future implementors. There has been 
*some* leg work done to collect information. There was talk of rechartering to 
remove this deliverable, but I hope that has been addressed.

=- Tim

> 
> One example would be a spec revision effort that targets clarification, 
> based on experience coding and deploying DMARC.
> 
> 
> I'll also suggest that it would help allay public concerns about DMARC to 
> be able to have this document include experience-based text about ARC usage; 
> both discussing how to use it and how effective it is.
> 
> d/

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

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

[Hector Santos]

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 handles
failures, that would be a specific local policy, not "general policy."
   Overall, the protocol intent is to Reject/Quarantine.

The ARC question is how does ARC change this existing
"psuedo-standard" protocol logic?

I prefer an explicit DMARC extended tag (or a author domain ARC seal)
that publishes the domain intent to use ARC to relax "some"
p=reject/quarantine failure in some fashion which is not defined at
the moment.  The preference is to remove/reduce receiver ambiguity of
what is to be expected when DKIM/DMARC is augmented with the ARC.


I still object to this concept on the same basis as the last two times
we had this discussion.

Brandon


Brandon,

Quite possible you haven't been clear in your DKIM Policy Modeling 
engineering reasoning.


The concept has been written across multiple RFCs since DKIM Policy 
Modeling architecture, including SPF.


If a domain publishes a DNS-based Public Record policy, you SHOULD 
honor its wishes as defined by the protocol recommendations.


You can do what you please with Local policy,  you can even prepare 
your product in the market place (if any) to behave as you want. 
Other implementations can do the same product designs that follow 
closely with the specifications.  That is what the system 
cooperatively competitive. Both SPF and DKIM POLICY docs have been 
very clear a,long these lines and its the #1 reason why we are still 
here after 10+ years trying to resolve same original  "indirect" 
rejection issues, are we not?  First it was SSP, then it was ASDP and 
now its these issues with DMARC.



So if you backing off and are advocating that receivers should ignore 
or add a "Don't really Mean it" rejection semantic regarding Hard Fail 
Policies, with SPF or DMARC, then you need to change the 
specifications and make it more clear in the new specs.


But I suspect a top marketing, security interest, the highest payoff, 
will continue to be to seek and support hard deterministic protocols. 
  That doesn't stop us  from working on new stuff that deal with the 
fuzzy non-deterministic classification decisions. We add some learning 
to it if you want.  Just make it very clear in your DKIM ARC 
augmentation what you want.  If you want ARC to change how DMARC 
words, then you have to say so in your specs.  You just can't assume 
people will blindly ignore what is already in place.


Thanks


--
HLS


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

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

[Brandon Long]

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 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 otherwise fail DMARC
>> > falls under the heading of "local policy". There does not need to be a
>> > spec revision to deal with ARC from this perspective. A sending domain
>> > publishing a DMARC policy is expressing it's wishes, not making
>> > demands (it cannot enforce). This is true with respect to any local
>> > policy a validator/mailbox provider implements.
>> >
>>
>> 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 handles
>> failures, that would be a specific local policy, not "general policy."
>>   Overall, the protocol intent is to Reject/Quarantine.
>>
>> The ARC question is how does ARC change this existing
>> "psuedo-standard" protocol logic?
>>
>> I prefer an explicit DMARC extended tag (or a author domain ARC seal)
>> that publishes the domain intent to use ARC to relax "some"
>> p=reject/quarantine failure in some fashion which is not defined at
>> the moment.  The preference is to remove/reduce receiver ambiguity of
>> what is to be expected when DKIM/DMARC is augmented with the ARC.
>>
>
> I still object to this concept on the same basis as the last two times we
> had this discussion.
>
> Brandon
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Hector Santos]

 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 otherwise fail DMARC
falls under the heading of "local policy". There does not need to be a
spec revision to deal with ARC from this perspective. A sending domain
publishing a DMARC policy is expressing it's wishes, not making
demands (it cannot enforce). This is true with respect to any local
policy a validator/mailbox provider implements.



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 handles 
failures, that would be a specific local policy, not "general policy." 
 Overall, the protocol intent is to Reject/Quarantine.


The ARC question is how does ARC change this existing 
"psuedo-standard" protocol logic?


I prefer an explicit DMARC extended tag (or a author domain ARC seal) 
that publishes the domain intent to use ARC to relax "some" 
p=reject/quarantine failure in some fashion which is not defined at 
the moment.  The preference is to remove/reduce receiver ambiguity of 
what is to be expected when DKIM/DMARC is augmented with the ARC.



--
HLS


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

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

[mham...@americangreetings.com]

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'll put that into the "next steps" section on
the next update to the agenda.


I suggest broaching this topic here and now, so the agenda entry can 
show something other than an off-charter draft.


Wise choice. +1




To prime that pump...



   Phase II:

  Specification of DMARC improvements to support indirect
mail flows


1.  Besides ARC, are there other wg efforts that should be pursued to 
satisfy this?


   ARC targets intermediary action in mail that originated with a 
DMARC-satisfying configuration.  ARC does not attend to mail that 
starts without that.  That is, mail starting from an independent third 
party source, such as a kiosk.




  Draft Guide on DMARC Usage


Current version is -04, so this charter item appears to be satisfied.



   Phase III:

  Review and refinement of the DMARC specification


Is there technical work on the base specification that would improve it?

 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 otherwise fail DMARC falls under 
the heading of "local policy". There does not need to be a spec revision 
to deal with ARC from this perspective. A sending domain publishing a 
DMARC policy is expressing it's wishes, not making demands (it cannot 
enforce). This is true with respect to any local policy a 
validator/mailbox provider implements.




    And from a note I posted last August:  "BTW, the DMARC spec uses 
the terms 'pass' and 'fail' with respect to the underlying 
authentication mechanisms of DKIM and SPF. It also uses it within the 
context of DMARC processing, itself, but it does not define what those 
terms mean, in that context.  Beyond reference to DMARC 'policy' 
records, text in the specs that talk about processing DMARC policy is 
similarly implicit, rather than explicit. The only clear, explicit 
directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply 
policy."




I need to think on this a bit more and go re-read the spec before 
formulating a response.





  Completion of Guide on DMARC Usage


What will it take to complete this doc?

 One example would be a spec revision effort that targets 
clarification, based on experience coding and deploying DMARC.



 I'll also suggest that it would help allay public concerns about 
DMARC to be able to have this document include experience-based text 
about ARC usage; both discussing how to use it and how effective it is.


If this is the case, I would suggest renaming the document to "Guide on 
DMARC and ARC Usage" rather than the original title.


Mike

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

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

[Hector Santos]

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 did not have this with ADSP when ATPS was first introduced as an 
extended ADSP add-on.  ADSP, the DKIM WG proposed standard track item, 
was in conflict with what we reestablished today as "indirect mail 
flows" and the key cogs of the DKIM WG was focused on eliminating the 
Author Domain Identity (ADID) from the specification and making 3rd 
party Trust Signers (SDID) the key focus identity for DKIM evaluation. 
 ADSP was being abandoned and you help kill it by eventually 
replacing it with DMARC.


If you redid ATPS as an add-on DMARC, I suspect we will have a higher 
interest in its exploration.   The marketing and need would be much 
higher than before.  It will certainly push forward our own update 
efforts (Replaced ADSP with DMARC and I would like believe other mail 
product and EPS vendors, including MLS developers would also would 
update DMARC to support a new SDID (Signer Domain Identity) optional 
parameter in the DNS policy record lookup:


  DMARC = DKIM_POLICY_DMARC(ADID [,SDID])

We are already doing the lookup as a function of ADID. We established 
that. Thats the difference today than yesteryears.  Now we just 
proposing to make it flexible for the 3rd party signature condition 
when the ADID != SDID.


We also long established, which I believe all the trust advocates 
agreed, that resigners are good.  They are needed when the original 
authenticity is lost, i.e MLM.


Will the vendors support it?Who knows? But the market is different 
today and that is all I am saying, you can't judge the lack of 
interest before because ADSP was being abandoned.   DMARC is not being 
abandoned.  It now needs to be completed with that 3rd party component.


I suggest a simple update of ATPS to anchor off DMARC and see if we 
will get the exploration.  You will get two immediate packages to 
support it.  Yours and mine.


If in the mean time, you come up with something better, great. I don't 
see it because it will always need to be verifiable with the 1st party 
again, but now we will be able to explore all the scalability issues. 
 I personally don't think the the non-ESP domains will need to worry 
about that.   Perhaps the biggest challenge for the larger ESP is how 
to best register the domains.   But thats an implementation issue, 
perhaps using a Web site with other business decisions such as free or 
fee-based.   Let the each market vendor decide that. In the mean time, 
we need the 3rd party Authorization extension for DMARC.


Thanks

--
HLS


On 3/27/2015 2:59 AM, Murray S. Kucherawy wrote:

On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull
mailto:step...@xemacs.org>> 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 institutions and in other transactional mail
flows.


Put another way, you only really know something when DMARC, DKIM, SPF,
etc. produce a passing result.  (Due credit to Dave for this
observation.)  All of them have false negatives with respect to
anything that's not a direct mail flow, so "fail" results don't tell
you anything conclusive if you plan to accept any sort of mail that
isn't direct.  What Hector characterizes as a watering down of SPF
with the publication of RFC7208 was merely this fact put into text,
even though it's been true since RFC4408.

Footnotes:
[1]  Hector is right that they haven't really been tried, but I don't
think the chance that they'll be tried in the future is high, because
the reasons they've been hard to implement in the past remain true.


I agree.  And although Hector likes to ascribe considerable power and
influence to me, I'm not the one standing in the way of their
success.  I would happily embrace any such solution that stood a
chance of working.  I, and others, simply ask some basic questions
about scalability of such solutions, their complexity, and their
ability to be "gamed", and then they never go anywhere because there
simply aren't any good answers to those questions.  Thinking I might
be wrong, and since the same people insist I am, I published RFC6541
(ATPS) as an experimental draft to try to tackle the third-party
problem, and made a free version of it available via open source.
That was over three years ago.  There has been exactly one site (one
person, rather) that tried it besides me and reported back about its
effectiveness.  Though Doug will shortly claim that ATPS saw no uptake
because it is "flawed", I also had a grand total of zero operators
report that they were using it in any modified form or asking 

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

[Michael Jack Assels]

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 flows, and that it's up
>  > to MLM developers (and other producers of indirect flows) to deal with
>  > it.
> 
> First, I don't think that interpretation is tenable, because their
> explanations to us are along the lines of "we know that we're a little
> out of line, but we have no choice."

So it's more like "p=reject is The Wrong Thing To Do, and it's up to
you to deal with it"? :-)

> Second, the relevant producers of indirect mail flows are not the
> MLMs.  They generally produce a direct mail flow, albeit unaligned.
> It's the mailbox provider's own users who produce indirect mail flows,
> by posting to the mailing lists.

You're right.  "Producers" was certainly the wrong word.  I should have
said "players" or "participants" -- entities involved in indirect flows.

>  > > We have a serious spoofing problem.  It is so serious compared to
>  > > the potential damage due to rejecting legitimate messages that we
>  > > accept all responsibility for nondelivery and collateral damage if
>  > > you choose to reject.
>  > 
>  > I can accept that that may be what p=reject means, but I can't take
>  > seriously the idea that domain owners with p=reject really do take
>  > all responsibility for nondelivery of legitimate messages.  When
>  > one of my users bangs on my door demanding to know why her message
>  > message wasn't delivered, can I really refer her to a giant ESP for
>  > an explanation?  I don't think so.
> 
> No, of course you can't, because they'll tell her that's not what they
> intended, and that it wouldn't be a problem if the third party behaved
> well.  However, you can tell her that the giant provider told the
> receiver not to accept her messages.  That's what DMARC actually says,
> and that's why I phrase it "accept reponsibility".

Actually, there's some ambiguity of emphasis in Section 6.3 of RFC7489:

   p: Requested Mail Receiver policy (plain-text; REQUIRED for policy
  records).  Indicates the policy to be enacted by the Receiver at
  the request of the Domain Owner. [...] Possible values are as
  follows:

   [...]
  reject:  The Domain Owner wishes for Mail Receivers to reject
 email that fails the DMARC mechanism check.

A "policy to be enacted by the Receiver at the request of the Domain Owner"
sounds compulsory, while "[t]he Domain Owner wishes for Mail Receivers to
reject email" sounds optional.  I'm pretty sure my boss will go with
"optional" for mail that we receive.

>  > I'd be happier to interpret "p=reject" as meaning
>  > 
>  > Spoofing is a serious problem.  With a very high degree of certainty,
>  > we assert that the message you're handling is not legitimate direct
>  > mail.  Please take this into account when deciding whether to accept
>  > or reject the message.
> 
> There's only one problem with that interpretation, and that is that
> you don't need DMARC p=reject to make it: it's a logical deduction
> from the mere fact of lack of From alignment.

That's right.  The Domain Owner's policy becomes a consideration if, and
only if, there's a lack of From alignment.  Otherwise everybody's happy.
But notice that the hypothetical Domain Owner who makes me happy (a) is
only certain that the message is not legitimate *direct* mail, and (b) is
asking me to take that into account.  In an earlier message, you wrote
that a receiver would have to be crazy not to reject a direct message that
had no From alignment, and I'm just sane enough to agree.  What I don't
like is the idea that DMARC-failed *indirect* mail should be rejected
solely on the From Domain Owner's say-so.  I'm willing to consider
rejection as a default option if other factors don't indicate the message's
legitimacy, but please leave me the freedom to consider other factors
without falling into the "RFC-ignorant" category.  (Is this message a
mailing list post?  Is the SMTP client one of the SPF-authorized mailers
for the mailing list's domain?  Does the list appear in my database of
legitimate mailing lists?)

>  > For DMARC participants, legitimacy and illegitimacy are equally
>  > easy to prove for transactional mail flows, and equally hard to
>  > prove for indirect flows.
> 
> That's actually false.  There are many indirect flows that don't cause
> signatures to be invalidated, such as Unix-style .forwards and GNU
> Mailman mailing lists configured with no subject tag, no header, and
> no footer.

I didn't mean that you can't prove legitimacy or illegitimacy for any
indirect flows, only that there doesn't exist a reliable method of proving
either in all cases, the point being that there are plenty of cases of
DMARC-failing legitimate indirect mail to match 

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

[Scott Kitterman]

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 DMARC intends that this be merely one of
> > many factors to consider, then doesn't it boil down to nothing more
> > than p=do-whatever?
> 
> +1.
> 
> As it currently is, p=reject already means p=quarantine or p=none, so
> "do-whatever".
> 
> We could try to add some extra --and defaulted to be empty/none-- qualifier
> to the DMARC TXT record in order to optionally, at the Sender's will,
> upgrade the plain old p=reject to mean
> "reject-and-yes-i-mean-it-always-dammit-i-dont-indulge-in-indirect-email-fl
> ows", so that Receivers can get that extra info from the Sender and
> therefore be able to guess, with more certainty, that said Sender does
> indeed has all his ducks neatly in a row when he publishes p=reject; but
> the proposal to do so has already seen very negative reception, repeatedly,
> so I will not insist on it anymore.

Looked into this once before for SPF (which despite the hand wringing here has 
been through a lot of these same policy considerations before).  There's no 
point in adding a "I really mean it" flag since nothing prevents a sender from 
adding it even if they don't.  

Eventually enough domains that perhaps shouldn't publish the "I really mean it 
flag" the receivers want a "NO, I REALLY, REALLY mean it" flag.  Pretty soon 
it's added flags all the way down.

In the data I see, I see some receivers overriding p=reject and using 
p=quarantine for some set of the mail they think is indirect.  Mostly though 
the policy applied is p=reject for a domain that publishes that policy.

Scott K

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

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

[J. Gomez]

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 relied on, or be suppressed from DMARC's formal
> > > specification if it is going to mainly be equal to p=do-whatever.
> > 
> > Can anyone point to a single instance of a sender-receiver policy
> > protocol that was "reliable" by this definition, enough that
> > receivers would blindly agree to do whatever the sender
> > asked/suggested/demanded? 
> > 
> > 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?  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 DMARC intends that this be merely one of
> many factors to consider, then doesn't it boil down to nothing more
> than p=do-whatever?

+1.

As it currently is, p=reject already means p=quarantine or p=none, so 
"do-whatever".

We could try to add some extra --and defaulted to be empty/none-- qualifier to 
the DMARC TXT record in order to optionally, at the Sender's will, upgrade the 
plain old p=reject to mean 
"reject-and-yes-i-mean-it-always-dammit-i-dont-indulge-in-indirect-email-flows",
 so that Receivers can get that extra info from the Sender and therefore be 
able to guess, with more certainty, that said Sender does indeed has all his 
ducks neatly in a row when he publishes p=reject; but the proposal to do so has 
already seen very negative reception, repeatedly, so I will not insist on it 
anymore.

> Yes, I know that receivers can and will do as they please, but some
> receivers would be pleased as punch to cooperate in a scheme that gave
> solid proof of a message's illegitimacy in every case where it was
> asserted.  The problem is that publishing p=reject effectively
> asserts that almost all submissions to mailing lists by users in the
> domain are illegitimate, and I'm afraid the real world doesn't
> believe that to be the case.

+1.

Some argue p=reject is fine as it stands and that the problem is just that 
Yahoo and AOL are abusing it. But the real world is as it is, and at the end of 
the day after all has been said it does not matter if the real world is abusive 
or not, we still have to interoperate with it.

Regards,
J.Gomez

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

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

[Stephen J. Turnbull]

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 flows) to deal with
 > it.

First, I don't think that interpretation is tenable, because their
explanations to us are along the lines of "we know that we're a little
out of line, but we have no choice."

Second, the relevant producers of indirect mail flows are not the
MLMs.  They generally produce a direct mail flow, albeit unaligned.
It's the mailbox provider's own users who produce indirect mail flows,
by posting to the mailing lists.

 > > No, there is valuable information in the policy.  As far as I can see,
 > > the semantics of "p=reject" are
 > > 
 > > We have a serious spoofing problem.  It is so serious compared to
 > > the potential damage due to rejecting legitimate messages that we
 > > accept all responsibility for nondelivery and collateral damage if
 > > you choose to reject.
 > 
 > I can accept that that may be what p=reject means, but I can't take
 > seriously the idea that domain owners with p=reject really do take
 > all responsibility for nondelivery of legitimate messages.  When
 > one of my users bangs on my door demanding to know why her message
 > message wasn't delivered, can I really refer her to a giant ESP for
 > an explanation?  I don't think so.

No, of course you can't, because they'll tell her that's not what they
intended, and that it wouldn't be a problem if the third party behaved
well.  However, you can tell her that the giant provider told the
receiver not to accept her messages.  That's what DMARC actually says,
and that's why I phrase it "accept reponsibility".

 > I'd be happier to interpret "p=reject" as meaning
 > 
 > Spoofing is a serious problem.  With a very high degree of certainty,
 > we assert that the message you're handling is not legitimate direct
 > mail.  Please take this into account when deciding whether to accept
 > or reject the message.

There's only one problem with that interpretation, and that is that
you don't need DMARC p=reject to make it: it's a logical deduction
from the mere fact of lack of From alignment.

 > For DMARC participants, legitimacy and illegitimacy are equally
 > easy to prove for transactional mail flows, and equally hard to
 > prove for indirect flows.

That's actually false.  There are many indirect flows that don't cause
signatures to be invalidated, such as Unix-style .forwards and GNU
Mailman mailing lists configured with no subject tag, no header, and
no footer.

And that's where the shoe pinches for mailing lists: the absolutist
advocates of sender policy blame the victim and say we should stop our
traditional value-added practices so that posters from p=reject
domains can have their posts delivered.


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

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

[Michael Jack Assels]

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, they may choose to ignore it, and there's nothing
> that can be done about it.  Furthermore, I don't see why anyone other
> than the receiver's mailbox users should care what the receiver
> chooses to do.

Right, but that leaves DMARC as just another factor to consider when
calculating a spam score.  Actually, it's a little better than that;
it comes pretty close to the desired "really reliably reliable" for direct
mail flows. 

>  > Clearly, the domain owner is explicitly asking that the message be
>  > rejected.
> 
> No, they are not, not in the case of AOL and Yahoo!.  Representatives
> of both domains have thanked MLM developers for providing mitigations
> so that messages that in the normal (until DMARC) course of events
> would fail From alignment can be delivered to DMARC-participating
> receiving domains which (since DMARC) would reject them.  Thus, Yahoo! 
> and AOL are clearly taking the position that they would like those
> messages to be delivered.

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 flows) to deal with
it.

> Hector, J. Gomez, Franck, and others take the position that the world
> has changed due to spam and phishing, and therefore "what *was*
> normal" is now irrelevant.  The new norm is conform to DMARC and other
> dictatorial sender policy frameworks or you're part of the problem.
> 
> I disagree.  Spamming and phishing are the problem, traditional
> practices of mailing lists are not.
> 
>  > If DMARC intends that this be merely one of many factors to
>  > consider, then doesn't it boil down to nothing more than
>  > p=do-whatever?
> 
> No, there is valuable information in the policy.  As far as I can see,
> the semantics of "p=reject" are
> 
> We have a serious spoofing problem.  It is so serious compared to
> the potential damage due to rejecting legitimate messages that we
> accept all responsibility for nondelivery and collateral damage if
> you choose to reject.

I can accept that that may be what p=reject means, but I can't take
seriously the idea that domain owners with p=reject really do take
all responsibility for nondelivery of legitimate messages.  When
one of my users bangs on my door demanding to know why her message
message wasn't delivered, can I really refer her to a giant ESP for
an explanation?  I don't think so.

I'd be happier to interpret "p=reject" as meaning

Spoofing is a serious problem.  With a very high degree of certainty,
we assert that the message you're handling is not legitimate direct
mail.  Please take this into account when deciding whether to accept
or reject the message.

This is worth a lot, despite the fact that it leaves the receiver with
two tasks:  Determining the message is direct or indirect, and if indirect,
determining whether it's legitimate.

>  > Yes, I know that receivers can and will do as they please, but some
>  > receivers would be pleased as punch to cooperate in a scheme that
>  > gave solid proof of a message's illegitimacy in every case where it
>  > was asserted.
> 
> 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 institutions and in other transactional mail
> flows.

I agree that absolute proof of illegitimacy for arbitrary messages is
hopeless, but DMARC actually provides a decision procedure for legitimacy
of in the restricted area of direct mail flows (assuming that mail from
compromised accounts is "legitimate").  For DMARC participants, legitimacy
and illegitimacy are equally easy to prove for transactional mail flows,
and equally hard to prove for indirect flows.

MJA

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

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

[Stephen J. Turnbull]

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
it *can work*, with the caveat that it must be accompanied by an
analysis of all possible failure modes, and preferably with
(theoretical :-) mitigations for the failures.  I haven't seen
anything like that, just handwaving about "if we implement the policy
framework, spam will go away and the mailing lists will have to come
to heel (ie, register with the author domains for 3rd party auth)."

Again speaking for myself, I think it's inappropriate to ask for data
about working at scale at this point (although that's a bridge that
eentually needs to be crossed).

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

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

[Stephen J. Turnbull]

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), a permanent or temporary failure

That's not the terminology we use around Mailman: a "hard bounce" is
exactly a "permanent failure".  I'll keep it in mind that you at least
use the term differently here.

Nor is the "soft bounce" as you define it useful if it is permanent
(5.x.x).  Even if the site admits it's a policy bounce, you have to
parse the error text in hope of determining whether there's something
wrong with the message (the next message might go through, even from
the same author), or if the receiver doesn't like the mailing list
(messages aren't going to go through period) or doesn't like the
author (the next message might or might not go through, depending on
the author).  And usually it's useless for the purpose, so has to be
passed on to the site admin for forensic analysis.

And even that doesn't help with sites that deliberately don't use
appropriate codes.  I don't really see that (from a protocol
standpoint) we're any better off than we were before the enhanced
status codes for the purpose of determining whether to stop mail to or
unsubscribe a bouncing address.


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

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

[Murray S. Kucherawy]

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 work at scale?  If the answer to that is "no" (or, as
> usual, silence), then I suggest this (still!) isn't a productive use of our
> precious time or energy.
>

...by which I mean we should really not spend any more time re-hashing the
past, and instead focus on figuring out the future.  I'm all for learning
from our past mistakes, but I think we've gotten all the blood we're going
to get out of that particular stone.

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

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

[Murray S. Kucherawy]

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 institutions and in other transactional mail
> flows.
>

Put another way, you only really know something when DMARC, DKIM, SPF, etc.
produce a passing result.  (Due credit to Dave for this observation.)  All
of them have false negatives with respect to anything that's not a direct
mail flow, so "fail" results don't tell you anything conclusive if you plan
to accept any sort of mail that isn't direct.  What Hector characterizes as
a watering down of SPF with the publication of RFC7208 was merely this fact
put into text, even though it's been true since RFC4408.


> Footnotes:
> [1]  Hector is right that they haven't really been tried, but I don't
> think the chance that they'll be tried in the future is high, because
> the reasons they've been hard to implement in the past remain true.
>

I agree.  And although Hector likes to ascribe considerable power and
influence to me, I'm not the one standing in the way of their success.  I
would happily embrace any such solution that stood a chance of working.  I,
and others, simply ask some basic questions about scalability of such
solutions, their complexity, and their ability to be "gamed", and then they
never go anywhere because there simply aren't any good answers to those
questions.  Thinking I might be wrong, and since the same people insist I
am, I published RFC6541 (ATPS) as an experimental draft to try to tackle
the third-party problem, and made a free version of it available via open
source.  That was over three years ago.  There has been exactly one site
(one person, rather) that tried it besides me and reported back about its
effectiveness.  Though Doug will shortly claim that ATPS saw no uptake
because it is "flawed", I also had a grand total of zero operators report
that they were using it in any modified form or asking me to add this or
that to it before they would deploy it to production.  It wasn't just an
idea, it was a reality, but nobody came to play.

Policy and third-party solutions haven't failed because of some cabal
keeping them from seeing the light of day, unless by "cabal" you mean
"group of people who agree that this won't work."

These are hard problems, and the last thing any of us should want to do is
foist yet another blob onto the global email infrastructure that has not
been properly vetted.  If an idea doesn't stand up to scrutiny or gets no
uptake, or can't even get consensus in a small working group, what prayer
does it have for success on the greater Internet?  I want to make things
better, not worse.

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 work at scale?  If the answer to that is "no" (or, as
usual, silence), then I suggest this (still!) isn't a productive use of our
precious time or energy.

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

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

[Franck Martin]

- 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:
> 
>  > 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 collateral damage to subscribers
> is hard bounces, and "p=reject" is a hard bounce.  Perhaps you mean
> discriminating between "technical hard bounces" and "policy hard
> bounces", but even there (a) I don't understand why you think there's
> a difference in the way the ML should treat them, and (b) many
> receiving sites deliberately conceal policy bounces, and especially
> the reason for them.

There is:
Temporary Failure: SMTP Status code 4xx (mainly): try again in a few minutes or 
on a different MX/IP
Permanent Failure: SMTP Status code 5xx (mainly): don't try again, get the user 
to fix it
and:
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), a permanent 
or temporary failure

Before the SMTP enhanced error codes existed, you had to parse the text portion 
of the error message and tried to figure out what it meant. You still kind of 
do it today.

http://help.campaignmonitor.com/topic.aspx?t=26#soft-vs-hard
https://sendgrid.com/blog/email-bounce-management/
http://www.boogietools.com/Products/Linux/BounceStudioAPI/Email-Bounce-Boogie-Bounce-API-Categories.asp

I admit, it is a bit of rocket science here, and if you can't deliver email 
reliably after several repeated soft bounces, then you should mark the email 
address as bounced and get the user to re-confirm it. Your mileage may vary.

Also there is the notion of bouncing vs rejecting which I prefer to call 
asynchronous bounce vs synchronous bounce, because even when you reject, an 
email (bounce) is usually created to be placed in the mailbox of the sender to 
inform him/her the email was not sent.

as for DMARC:
http://tools.ietf.org/html/rfc7489#section-10.3
and AFAIK, the text portion of the current implementations I know of gives a 
hint, it is because of DMARC.

I know mailman 3.0 has a better bounce management system, and I think it will 
be a separate library, which would be awesome, because it can be included in 
other open source projects. So when the mailing list recognize the bounce is 
due to DMARC, then it could either ignore the bounce, or mark that against the 
original sender rather than the receiver. No more collateral damage.

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

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

[Stephen J. Turnbull]

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 interpretation given the choice of mood ("reject"
is a command), but in the end it's untenable.  As Murray says,
"policy frameworks" have been tried before, and they just don't work
for "generic" email, although they work very well (as indeed DMARC
does) for several important, but restricted, mail flows.

The problem with "generic" email is that the incentives of Author
Domains which provide mailboxes for personal use are poorly aligned
with the incentives of their mailboxes' users.  Specifically, Author
Domains consider spam-fighting priority one, and consider mailing
lists and other indirect flows at best neutral, and often on net a
nuisance, while their users want to participate freely in indirect
flows (leaving the costs of spam-fighting up to the Author Domains).

 > 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, they may choose to ignore it, and there's nothing
that can be done about it.  Furthermore, I don't see why anyone other
than the receiver's mailbox users should care what the receiver
chooses to do.

 > Clearly, the domain owner is explicitly asking that the message be
 > rejected.

No, they are not, not in the case of AOL and Yahoo!.  Representatives
of both domains have thanked MLM developers for providing mitigations
so that messages that in the normal (until DMARC) course of events
would fail From alignment can be delivered to DMARC-participating
receiving domains which (since DMARC) would reject them.  Thus, Yahoo! 
and AOL are clearly taking the position that they would like those
messages to be delivered.

Hector, J. Gomez, Franck, and others take the position that the world
has changed due to spam and phishing, and therefore "what *was*
normal" is now irrelevant.  The new norm is conform to DMARC and other
dictatorial sender policy frameworks or you're part of the problem.

I disagree.  Spamming and phishing are the problem, traditional
practices of mailing lists are not.

 > If DMARC intends that this be merely one of many factors to
 > consider, then doesn't it boil down to nothing more than
 > p=do-whatever?

No, there is valuable information in the policy.  As far as I can see,
the semantics of "p=reject" are

We have a serious spoofing problem.  It is so serious compared to
the potential damage due to rejecting legitimate messages that we
accept all responsibility for nondelivery and collateral damage if
you choose to reject.

In the case of direct mail flows, the potential damage due to
rejection of legitimate mail is very low, and the potential damage
from accepting spoofed mail is extremely high.  If you know that a
mail flow is direct, as a receiver you'd be crazy not to reject, and
as a sender you'd be crazy not to accept the responsibility for
receivers rejecting.

In the case of indirect flows, receivers may (or may not) want to
prefer their judgment to that of the author domain, because often the
expected damage from accepting is much lower, and the expected damage
from rejecting much higher.

 > Yes, I know that receivers can and will do as they please, but some
 > receivers would be pleased as punch to cooperate in a scheme that
 > gave solid proof of a message's illegitimacy in every case where it
 > was asserted.

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 institutions and in other transactional mail
flows.


Footnotes: 
[1]  Hector is right that they haven't really been tried, but I don't
think the chance that they'll be tried in the future is high, because
the reasons they've been hard to implement in the past remain true.

The big problem is that policy frameworks proposed so far "work" only
if you define "legitimacy" tautologically: if it gets past the policy
framework, it's legit, else not.  That's not what my users want,
though.  They want to receive the mail they want to receive, and
otherwise not, and no policy framework so far has shown promise of
implementing that.

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

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

[Stephen J. Turnbull]

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 collateral damage to subscribers
is hard bounces, and "p=reject" is a hard bounce.  Perhaps you mean
discriminating between "technical hard bounces" and "policy hard
bounces", but even there (a) I don't understand why you think there's
a difference in the way the ML should treat them, and (b) many
receiving sites deliberately conceal policy bounces, and especially
the reason for them.

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

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

[Franck Martin]

- 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 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...
> 
We were there a few posts back already...

Can people please review the last version of 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ and comment?

This document still needs some improvemments and its completion is a milestone 
to progress further.

Thanks.

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

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

[Steven M Jones]

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
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- 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 Mar 2015 15:23:08 PDT,
> "Murray S. Kucherawy"  wrote:
> 
> > On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez  wrote:
> > 
> 
> That's not to say that DMARC should change anything about itself.  It's
> just recognition that making it a great success will depend on someone
> finding a way to let mailing lists collaborate with DMARC without
> alienating their list users, owners or managers.
> 

You can't please everyone at the moment, and there are solutions to please 
various subsets of your lists.

I'm on various mailings lists, some friendly to DMARC, some not, with email 
with a domain with p=reject, or not...

What I learn for all the combinations: It does not change much, people still 
ignore my posts :P

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

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

[Michael Jack Assels]

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.
> >
> > 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.
> 
> Can anyone point to a single instance of a sender-receiver policy protocol
> that was "reliable" by this definition, enough that receivers would blindly
> agree to do whatever the sender asked/suggested/demanded?
> 
> 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?  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 DMARC intends that this be merely one of many factors to
consider, then doesn't it boil down to nothing more than p=do-whatever?

Yes, I know that receivers can and will do as they please, but some
receivers would be pleased as punch to cooperate in a scheme that gave
solid proof of a message's illegitimacy in every case where it was
asserted.  The problem is that publishing p=reject effectively asserts that
almost all submissions to mailing lists by users in the domain are
illegitimate, and I'm afraid the real world doesn't believe that to be the
case.

That's not to say that DMARC should change anything about itself.  It's
just recognition that making it a great success will depend on someone
finding a way to let mailing lists collaborate with DMARC without
alienating their list users, owners or managers.

I'd love to announce that I've found the way, but I'm as befuddled as
anyone else.

MJA

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

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

[Murray S. Kucherawy]

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 be
> relied on, or be suppressed from DMARC's formal specification if it is
> going to mainly be equal to p=do-whatever.
>

Can anyone point to a single instance of a sender-receiver policy protocol
that was "reliable" by this definition, enough that receivers would blindly
agree to do whatever the sender asked/suggested/demanded?

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.

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

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

[Franck Martin]

- 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 should bounce the email, then 
just bounce it. Why?

1) there are reports to tell the sender why you bounced the email. And it 
should get the bounce too. If it is not what the sender wants, he has all the 
tools to assess if it was important for the receiver to receive this message or 
not and what can the sender do to change that.
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.

If you do anything else, it is because you want to be nice to the sender. 
(pulling leg here)

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

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

[J. Gomez]

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 "ACCEPT/SEPARATE" mode of operation for failed SPF
> messages as opposed to just REJECTING failed SPF messages.
> 
> Part of the problem is that the idea of quarantine does presumed a
> backend mail storage design that mail separation was even possible.
> It is not an universal concept to have this multiple mail folders
> idea, ability and/or MUA/UI infrastructure for end-users.  So in that
> vain, it does come with a high support and also high implementation
> cost to include Mail Quarantine functionality into a specification.
> REJECTION is a must lower design implementation cost.

+1.

For Google/Hotmail/big-ESP, the support costs are already accounted for in 
their cost structure. For small or "boutique" Email Service Providers, support 
costs are very important and can grow very fast: an user has a problem with 
suspect or missing email?, we go on-site, we hand-hold them, we give face, we 
remote into their system and get to deal with the mess, we do whatever until 
the troubled user finds peace...

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 be 
relied on, or be suppressed from DMARC's formal specification if it is going to 
mainly be equal to p=do-whatever.

Regards,
J.Gomez

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

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

[J. Gomez]

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 financial institution and uses that domain for
> transactional mailflows),  has at least
> once used his/her "p=reject" address to post to a mailing list I
> subscribe to (which didn't implement DMARC).  These things happen.

Yes, but then in that DMARC rejection which you describe above the Receiver can 
blame it on the Sender, who did not put his ducks neatly in a row as he should 
have done.

The question is: who bears the cost of DMARC's p=reject "false positives"? As a 
Receiver, I will be blind and will not obey to Sender's p=reject unless I can 
blame on said Sender the rejection --derived form the Sender's declared DMARC 
of p=reject-- of legitimate email.

> > The set (DMARC + p=reject) is unreliable, in the current situation,
> > because it fails to describe the legitimate and real scenario of
> > mailing lists.
> 
> Technically, it does describe them: author domains "should not" use
> p=reject if it authorizes indirect mailflows From its mailboxes.  AOL
> and Yahoo! were abusing p=reject according to the draft of April 2014.

That Yahoo and AOL are "abusing p=reject" is a way to see the case. Another way 
to see it, is that DMARC's p=reject fails to describe real email usage, and 
therefore is unreliable (i.e., cannot be relied on).

Regards,
J.Gomez

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

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

[Stephen J. Turnbull]

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/her "p=reject" address to post to a mailing list I
subscribe to (which didn't implement DMARC).  These things happen.

It's possible that the rate of occurance is low enough that you would
be happy to set your receiving MTA to reject that post because it
failed alignment with the "p=reject" domain.  But I might not,
preferring to rely on a filter that weights "reject legitimate" (eg,
"reject existing correspondent") far more negatively than yours does.

Of course it's up to you what you do.  I'm just saying that the
protocol needs to deal with extreme preferences like the ones I
(hypothetically) attribute to myself.

 > The set (DMARC + p=reject) is unreliable, in the current situation,
 > because it fails to describe the legitimate and real scenario of
 > mailing lists.

Technically, it does describe them: author domains "should not" use
p=reject if it authorizes indirect mailflows From its mailboxes.  AOL
and Yahoo! were abusing p=reject according to the draft of April 2014.

The reason I bring this up is that I find it hard to imagine a world
in which, even after that experience, non-transactional mailflows
currently covered by p=none would have all of their third party relays
registered with a third-party authorization protocol.  On the other
hand botnets mean that draft-kucherawy-dkim-delegate and
draft-levine-dkim-conditional can be massively exploited if ordinary
users at those sites are allowed to use those mechanisms without
oversight by the author domain.  So I suspect that a registry of third
parties is an essential precondition for p=reject to be compatible
with open-subscription mailing lists.

AFAICS, that means that any such protocol is going to be unreliable
in the face of a security breach like those at AOL and Yahoo!.

Of course you could imagine a world where everybody implements DMARC
and p=none doesn't exist.  Then Mediators must register or their
messages won't be delivered, period.  But to me, that's not email. :-(

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

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

[Hector Santos]

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 address the authentication issues
   associated with SMTP other than to advocate that useful functionality
   not be disabled in the hope of providing some small margin of
   protection against an ignorant user who is trying to fake mail.

The text different between 2821 and 5321 is that the "user" is no 
longer "ignorant."


Many preferred to pass the buck to the user for making decisions on 
what is considered accepted mail. The DMA, the "Spammer" world, good 
or bad, want you to ACCEPT the mail to pass to the user.  CAN-SPAM 
also plays a role here too in the area of User Vendor contracts.


So in general, whenever we had new strong deterministic rejection 
protocols, we had the friction of dealing with "ACCEPT/SEPARATE" or 
"Quarantine" ideas embedded as well as means to reduce the potential 
false positive nature of rejection policies.


Case in point with SPF.

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 "ACCEPT/SEPARATE" mode of operation for failed SPF 
messages as opposed to just REJECTING failed SPF messages.


Part of the problem is that the idea of quarantine does presumed a 
backend mail storage design that mail separation was even possible. 
It is not an universal concept to have this multiple mail folders 
idea, ability and/or MUA/UI infrastructure for end-users.  So in that 
vain, it does come with a high support and also high implementation 
cost to include Mail Quarantine functionality into a specification. 
REJECTION is a must lower design implementation cost.


In theory, rejection or quarantine, both must provide the same end of 
result of protecting users from harm and also the domain from being 
exploited.  If you are going to quarantine mail instead of rejecting 
it, then  you need to make sure the USER does not get the mail 
directly in the natural in-box, including the POP3 mail stream -- it 
must not be part of the pick up.


--
HLS

On 3/25/2015 3:17 PM, J. Gomez wrote:

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 result in tagging a message for possible consideration by the
user (probably via different display by the UI), we can't ignore
the user.

I agree that this isn't the place to delve deeply into user
behaviour and UI design.  But we shouldn't ignore the context of
our work.


+1

Email is for the users. p=quarantine is a USER PROBLEM.



No, p=quarantine is a problem WE cause.


Yes, but a problem that ultimately the user gets directly planted before his 
eyes, and which the user has to roll up his sleeves to deal with as well/bad as 
he can possibly manage.

Translation: p=quarantine has vey high support costs.

As I understand it, in the beginning of the coming up with DMARC, p=quarantine 
was designed as a stepping stone in the journey towards p=reject. In that view, 
the high support costs of p=quarantine were tolerable because p=quarantine was 
meant to be a temporary situation for the sender domain Owner. Now that 
p=reject is a dead end for all practical purposes, p=quarantine has less and 
less utility. Only p=none is safe to use unless you do not have real people as 
users.

We must work hard to find a solution which makes p=reject a viable setting 
which can be reliably relied on.

Regards,
J.Gomez



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

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

[Murray S. Kucherawy]

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 said Sender publishes p=reject. Question that the
> Receiver asks to himself: Is the Sender aware of p=reject drawbacks and can
> therefore the Receiver rely on the Sender's declared p=reject? Answer to
> that question: The Receiver has no way to know, therefore p=reject is
> unreliable from the point of view of the Receiver, irrespective of what the
> Receiver ultimately decides to do with the Sender's declared p=reject.
>

I think you're actually saying exactly what I thought you meant.  Thanks
for confirming.  I just wanted to be clear for context.

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

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

[J. Gomez]

Hi, Murray.

(Aside: Your email client is sending messages in "multipart/alternative" 
format, but then its "text/plain" section has the quoting broken...  Could you 
fix that, please? I had to manually add ">>" below to differentiate your text 
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 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 not sure I agree with the claim that p=reject is unreliable.  It
> seems to me that it's working as designed, and the results are
> deterministic.  It's not flaky.  How receivers use it is the mushy
> part, but that's really outside of the protocol.   

The set (DMARC + p=reject) is unreliable, in the current situation, because it 
fails to describe the legitimate and real scenario of mailing lists.

> Even if DMARC didn't have these mediator problems, there still would
> be no ultimate compulsion for receivers to do what domain owners ask.
> It might be a lot more likely that they would comply without
> reservations, but there would still be some operators that don't.   
> 
> So just to be clear, are you using "reliable" here to talk about how
> receivers apply it? 

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 
said Sender publishes p=reject. Question that the Receiver asks to himself: Is 
the Sender aware of p=reject drawbacks and can therefore the Receiver rely on 
the Sender's declared p=reject? Answer to that question: The Receiver has no 
way to know, therefore p=reject is unreliable from the point of view of the 
Receiver, irrespective of what the Receiver ultimately decides to do with the 
Sender's declared p=reject.

Regards,
J.Gomez

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

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

[J. Gomez]

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.
> 
> That's a small enough set of domains at the moment (I can think
> of about five) that there are several obvious solutions for mailing
> lists - a blacklist of DMARC records to treat specially would be
> the simplest, though something more nuanced might be better.

That "blacklist of DMARC records [with p=reject] to treat specially" I'm afraid 
is a solution which will not scale. You say there are now "about five" of such 
domains. Well, about five big enough for everyone to notice them, but surely 
there are many more which are small enough to fly under our radar.

It would take just some more data breaches and we might get to a "blacklist for 
DMARC records with p=reject" in the form of: "*"  ;-)

Regards,
J.Gomez

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

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

[J. Gomez]

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 result in tagging a message for possible consideration by the
> > > user (probably via different display by the UI), we can't ignore
> > > the user. 
> > > 
> > > I agree that this isn't the place to delve deeply into user
> > > behaviour and UI design.  But we shouldn't ignore the context of
> > > our work. 
> > 
> > +1
> > 
> > Email is for the users. p=quarantine is a USER PROBLEM.
> > 
> 
> No, p=quarantine is a problem WE cause.

Yes, but a problem that ultimately the user gets directly planted before his 
eyes, and which the user has to roll up his sleeves to deal with as well/bad as 
he can possibly manage.

Translation: p=quarantine has vey high support costs.

As I understand it, in the beginning of the coming up with DMARC, p=quarantine 
was designed as a stepping stone in the journey towards p=reject. In that view, 
the high support costs of p=quarantine were tolerable because p=quarantine was 
meant to be a temporary situation for the sender domain Owner. Now that 
p=reject is a dead end for all practical purposes, p=quarantine has less and 
less utility. Only p=none is safe to use unless you do not have real people as 
users.

We must work hard to find a solution which makes p=reject a viable setting 
which can be reliably relied on.

Regards,
J.Gomez

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

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

[Stephen J. Turnbull]

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 problem if p=reject is
published, but DMARC doesn't say that you can't differentiate between
aligned mail and unaligned mail, only that you can't differentiate
between a failed signature verification and no signature at all.

Sites can and do assign negative spam points to verified signatures,
so there is a (smaller, but still real) problem for MLs even if nobody
publishes p=reject.


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

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

[Stephen J. Turnbull]

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 is ugly to
 > > boot.
 > 
 > Well, it seems to me the above paragraph could also be written like
 > this: MLM taking ownership of the Header-From
 > (a.k.a. "From-munging" in your terms) has its detractors, but it
 > works fine for many users who don't have a problem with it,
 > arguably conforms to RFC 5322, and looks just nice.

OK, well, we'll just have to agree to disagree.

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

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

[Hector Santos]

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, pushing the COMPLETE DKIM POLICY 
FRAMEWORK concept.  Either they got tired walked away, they saw can't 
beat a dead horse or realize the people in "IETF control" were pushing 
other ideas that were not necessarily wrong, but they PUT barriers up 
to support the AUTHOR domain framework.


We will not move forward in a major way until the 3rd party SIGNATURE 
authorization methodology is worked out.  It was a thorn on the side 
then and it continues to be a thorn on the side today.


We have quite a few RFCs related to DKIM signature methodologies and 
we never did properly resolved it (3rd party signers) because the key 
folks running the show were pushing a 3rd party TRUST methodology. 
They were militarily adamant about making sure the AUTHOR domain would 
not be dictating anything, hence the DKIM myth the AUTHOR DOMAIN was 
not related to the DKIM SIGNER AUTHENTICATION and AUTHORIZATION.  That 
SEPARATION was impossible to ACHIEVE because the AUTHOR was a minimal 
hash binding requirement.


But today, the TRUST part has gone no where, i.e. VBR was the closest 
thing to a DKIM TRUST model (we support it, do you?). It was AUTHOR 
POLICY that has prevailed but DMARC crippled it by sticking with the 
same problems ADSP had.


Add 3rd party POLICY extensions and we will begin to get sensible 
software solutions again.   We done it with ADSP/ATPS. So can large 
boys too with DMARC/ATPS.   Add ATPS support or similar and we will 
begin to move forward with a framework for proper SOFTWARE CHANGE at 
the MLM.


Wasting too much time again.  Just update ATPS for DMARC and get MURRY 
to support the idea and maybe we will get others to get it a try.  But 
if he is going to continue to block it, talk negative about it, well, 
 we have a technical marketing problem that is not representative of 
a good technical, plug and play, easier solution for DKIM SIGNATURE 
AUTHORIZATION PROTOCOL.


--
HLS

On 3/24/2015 4:38 PM, J. Gomez wrote:

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 understood "depends on a successful DMARC check".


No, we are talking about the same thing.  What I am saying is that
DMARC is already a "success as an implemented technology in the real
world" by any reasonable standard, because it *does* work for exactly
the transactional mail flows you worry about.


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 already said 
in another post to this list. Which is nice, but is not a "success as an implemented 
technology in the real world" for DMARC, because DMARC aims to be more than just a 
reporting tool.

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.

In fact, I think that if at the end of all this process we cannot find a way to 
make p=reject to be reliably relied on, then p=reject should be suppressed from 
the DMARC formal specification, as p=reject would effectively be equal to 
p=do-whatever-who-cares.

Regard,
J.Gomez

___
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] Next steps for RFC 7489 (DMARC)

[Steven M Jones]

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 already said in another post to this list. Which is nice, 
> but is not a "success as an implemented technology in the real world" for 
> DMARC, because DMARC aims to be more than just a reporting tool.

DMARC is not some declaration of the divine right of domain owners to
exercise absolute control over any message where their domain appears.

DMARC is a protocol that enables domain owners/senders and receivers to
*collaborate* in detecting and eliminating fraudulent messages that
claim to originate from a given domain. There is implicit and explicit
give-and-take in that relationship.

Policy expressions from domain owners ("p=reject") are requests - ones
that are followed in most cases - but no receiver is offering an
unreserved, 100% guarantee that they won't act otherwise when they feel
doing so is in the best interest of their users.

The fact that receivers can and will do what they think best, even in
the face of a given policy request, runs throughout the DMARC specification.


> In fact, I think that if at the end of all this process we cannot find a way 
> to make p=reject to be reliably relied on, then p=reject should be suppressed 
> from the DMARC formal specification, as p=reject would effectively be equal 
> to p=do-whatever-who-cares.

Again, in my experience, receivers do honor policy assertions in an
overwhelming majority of cases.

The reporting mechanisms in DMARC are there to help domain
owners/senders improve the authentication rates of their legitimate
mailflows - so the receivers can block more fraudulent messages, more
reliably. Without the support for so-called "blocking policies," you
have eliminated the reason for receivers to pay for complex, expensive
DMARC filtering and reporting.

--Steve.

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

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

[Dave Crocker]

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 flawed.
> 
> I have a 24-year-long parade of users worried that their account was
> compromised because they're receiving bounces for spam they never
> sent,

Forgive me (yet again) but that wasn't the issue.  Yes there's a
problem.  Long-standing, real and serious.

However the issue on the table is an assertion of efficacy by presenting
certain kinds of information to end-users.  And it's that assertion that
is (highly) problematic.  Which is why I urge everyone to bypass it.



> But we're straying from the topic, which is indeed to come up with
> technical specs that software can obey.  Having said that:
> 
>>> One could argue, I suppose, that once again we're talking
>>> about the behaviour of software, but the point of all this,
>>> unless I woefully misunderstand, is to protect the user from
>>> fraud due to the faked provenance of a message. 
>>
>> As a very general mission statement -- or an even higher-level motivator
>> for working in this space -- perhaps, but that has essentially no effect
>> on design choices here.


> If "the point of all this" has "essentially no effect on design
> choices", we have a serious problem.  It's all very well do do
> things right, but we have to make sure we're doing the right
> thing too.

Protecting users does not automatically or necessarily entail presenting
spoofing/validity information to those users.


>> 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
> message, the user isn't involved, but as soon as those decisions
> can result in tagging a message for possible consideration by the user
> (probably via different display by the UI), we can't ignore the user.

The presumption that 'tagging a message for possible consideration by
the user' is in any way relevant or helpful is problematic.  Highly
problematic.


> I agree that this isn't the place to delve deeply into user behaviour
> and UI design.  But we shouldn't ignore the context of our work.

Any consideration here, which leads to assumptions or expectations of
things being presented to end users for their consideration, is a pure
distraction -- at its best.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Dave Crocker]

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 community, it's an
> assertion that there's a war out there, and the community is taking
> hits from friendly fire.

Your 'but' suggests that your comment counters mine, but I said 'some'
not all and I didn't mention the From field.  Nor did I intend to count
>From munging as an exemplar.


>  > Mailing lists therefore have the right to make the changes they
>  > make.
> 
> That's an incomplete statement.  They have the right to make the
> changes as long as they are compatible with community standards.

There is a very long list of additional qualifiers and requirements one
might choose to include.

However I think they distract from the point I was making, which really
merely reflects what is in the Email Architecture RFC:

 When an intermediary is re-posting a message, it owns the message
it is re-posting and has the right to do what it wants.

That's a system architecture "right", not a "social' right.


> Back to Dave:
> 
>  > I think the historical challenge has less been a case of
>  > philosophical legitimacy
> 
> From-munging is hardly open-and-shut "philosophically legitimate."

So it's probably good that I wasn't talking about that.


>  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.  Nevertheless, GNU Mailman has a From-Munging option.[1]

There are three operational problems with From munging:

   1.  The recipient sees a different string than they are used to, for
identifying the author of the message.  That invites confusion.

   2.  The recipient's filtering engine will misbehave if it keys off of
author's name; a related problem is that message threading software will
misbehave.

   3.  From munging teaches spoofers how to bypass DMARC protections.


>  > and more of inability to gain active, constructive participation of
>  > mailing list software maintainers.
> 
> Hey, I resent that.  You guys use GNU Mailman; you know where to find
> us if you want participation.

I was making an historical comment.  Many years ago.  Ancient Internet.
 Most of you folk probably weren't born yet. (just kidding.)  (maybe.)



> It's not the MLM developers you have a problem getting cooperation
> from.  It's our users.

We need to stop worrying about users.  They are simply a distraction.

Or maybe...


> Bottom line: making indirect mail flows compatible with DMARC-style
> spoof-protection is a hard problem.

+1


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Steve Atkins]

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 mail work. If it works
>> really well then nothing should end up in quarantine /junk/spam
>> folders.
> 
> The number of messages sorted as "not sure" is hardly the
> best or only measure of how well the system works; to take
> the above to an extreme, if I reject all mail, does my system
> work perfectly?  ;-)
> 
> 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, most of us don't dare publish p=reject, which leaves us
> with p=none, or no DMARC records at all.  Which means that (a)
> many of us cannot benefit from using DMARC under the current
> circumstances, and (b) many sites don't have the resources to
> implement it yet, but we still have to deal with their mail.
> I'm not willing to throw the baby out with the bathwater.

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.

That's a small enough set of domains at the moment (I can think
of about five) that there are several obvious solutions for mailing
lists - a blacklist of DMARC records to treat specially would be
the simplest, though something more nuanced might be better.

Cheers,
  Steve

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

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

[Murray S. Kucherawy]

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, most of us don't dare publish p=reject, which leaves us
> with p=none, or no DMARC records at all.  Which means that (a)
> many of us cannot benefit from using DMARC under the current
> circumstances, and (b) many sites don't have the resources to
> implement it yet, but we still have to deal with their mail.
> I'm not willing to throw the baby out with the bathwater.


+1.  To be a bit flippant about it: Now that we have everyone's attention,
possibly moreso than ever before, maybe it's possible to come up with a
compromise that all corners of the email ecosystem can accept.

But that doesn't mean we need to settle for creating schisms in that
ecosystem.  Entrenching is not the answer.

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

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

[Anne Bennett]

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 up in quarantine /junk/spam
> folders.

The number of messages sorted as "not sure" is hardly the
best or only measure of how well the system works; to take
the above to an extreme, if I reject all mail, does my system
work perfectly?  ;-)

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, most of us don't dare publish p=reject, which leaves us
with p=none, or no DMARC records at all.  Which means that (a)
many of us cannot benefit from using DMARC under the current
circumstances, and (b) many sites don't have the resources to
implement it yet, but we still have to deal with their mail.
I'm not willing to throw the baby out with the bathwater.


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

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

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

[Murray S. Kucherawy]

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
> 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 up in quarantine/junk/spam folders.
>
>
That's not how I characterize the spam folder, at least at the operators
where I have mailboxes.  It's more like: "We have reason to believe this is
spam or otherwise illegitimate.  We will silently set it aside and
automatically discard it in X days, unless you come looking for something
you feel might've been miscategorized and rescue it."

That's different from telling the user to figure it out, which I take to
mean something more like an ongoing and fairly constant filter training
exercise.

Of course, this only highlights again that different receivers will treat
DMARC's output in whatever way suits them.

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

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

[MH Michael Hammer (5304)]

> -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], 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
> > message, the user isn't involved, but as soon as those decisions can
> > result in tagging a message for possible consideration by the user
> > (probably via different display by the UI), we can't ignore the user.
> >
> > I agree that this isn't the place to delve deeply into user behaviour
> > and UI design.  But we shouldn't ignore the context of our work.
> 
> +1
> 
> Email is for the users. p=quarantine is a USER PROBLEM.
> 

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 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 up in 
quarantine/junk/spam folders.

Mike

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

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

[MH Michael Hammer (5304)]

> -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:
> 
> > 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 same thing.  What I am saying is that
> > DMARC is already a "success as an implemented technology in the real
> > world" by any reasonable standard, because it *does* work for exactly
> > the transactional mail flows you worry about.
> 
> 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 already said in another post to this list. Which 
> is
> nice, but is not a "success as an implemented technology in the real world"
> for DMARC, because DMARC aims to be more than just a reporting tool.
> 

Mailbox providers/ISPs are going to do what they do. Recognizing local policy 
is one of the reasons that the large mailbox providers/ISPs decided to validate 
DMARC and play ball. By and large they get it right (at least in my experience 
and I've been doing DMARC since before it was public). Even for transactional 
mail from originators which have control over their mail flows, there will 
always be some small percentage of mail that gets broken because of certain 
types of forwarding (beyond mail lists). From my perspective, when a mailbox 
provider/ISP chooses to implement local policy over my request (through a 
published p=reject policy) then they are taking responsibility for their 
decision. To demand more from them is simply unrealistic. Any organization can 
publish a standard - the real proof is the extent to which people adopt that 
standard.

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

My experience is that the overwhelming majority of time you can reliably rely 
on DMARC's policy implementation - and I'm looking at a corpus of Billions of 
sent mail. You can check this yourself by looking at the reporting you receive. 
If mailbox providers would have overridden your p=reject it will show in the 
reporting you receive and you can gauge the potential outcome yourself. You are 
making assertions that the data doesn't support. Mailbox providers have no 
incentive to randomly override DMARC with local policy for non-trivial reasons. 
The real problem is that once you get past the top mailbox providers, the 
remainder of them don't have the resources/expertise/large enough data sets to 
implement local policy overrides in a manner that is workable and sustainable. 
Perhaps someone can make a go of offering this as a service - perhaps not.

> In fact, I think that if at the end of all this process we cannot find a way 
> to
> make p=reject to be reliably relied on, then p=reject should be suppressed
> from the DMARC formal specification, as p=reject would effectively be equal
> to p=do-whatever-who-cares.
> 

Mike

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

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

[Murray S. Kucherawy]

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 not sure I agree with the claim that p=reject is unreliable.  It seems
to me that it's working as designed, and the results are deterministic.
It's not flaky.  How receivers use it is the mushy part, but that's really
outside of the protocol.

Even if DMARC didn't have these mediator problems, there still would be no
ultimate compulsion for receivers to do what domain owners ask.  It might
be a lot more likely that they would comply without reservations, but there
would still be some operators that don't.

So just to be clear, are you using "reliable" here to talk about how
receivers apply it?

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

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

[J. Gomez]

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
> message, the user isn't involved, but as soon as those decisions
> can result in tagging a message for possible consideration by the user
> (probably via different display by the UI), we can't ignore the user.
> 
> I agree that this isn't the place to delve deeply into user behaviour
> and UI design.  But we shouldn't ignore the context of our work.

+1

Email is for the users. p=quarantine is a USER PROBLEM.

Lets not forget that.

Regard,
J.Gomez

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

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

[J. Gomez]

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 understood "depends on a successful DMARC check".
> 
> No, we are talking about the same thing.  What I am saying is that
> DMARC is already a "success as an implemented technology in the real
> world" by any reasonable standard, because it *does* work for exactly
> the transactional mail flows you worry about.

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 already said in another post to this list. Which is nice, but 
is not a "success as an implemented technology in the real world" for DMARC, 
because DMARC aims to be more than just a reporting tool.

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.

In fact, I think that if at the end of all this process we cannot find a way to 
make p=reject to be reliably relied on, then p=reject should be suppressed from 
the DMARC formal specification, as p=reject would effectively be equal to 
p=do-whatever-who-cares.

Regard,
J.Gomez

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

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

[J. Gomez]

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.

Well, it seems to me the above paragraph could also be written like this: MLM 
taking ownership of the Header-From (a.k.a. "From-munging" in your terms) has 
its detractors, but it works fine for many users who don't have a problem with 
it, arguably conforms to RFC 5322, and looks just nice.

> Bottom line: making indirect mail flows compatible with DMARC-style
> spoof-protection is a hard problem.

It's only a hard problem if mailing list operators insist on clinging to their 
old-style habits (mailing lists users largely either don't care or don't 
understand the difference; and any other indirect email flows --apart from 
mailing lists-- are extremely legacy and obsolete).

Regards, 
J.Gomez

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

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

[Stephen J. Turnbull]

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 the community is taking
hits from friendly fire.

 > Mailing lists therefore have the right to make the changes they
 > make.

That's an incomplete statement.  They have the right to make the
changes as long as they are compatible with community standards.  For
example, some lists provide advertising space in the footer.  Others
would have a revolution if you tried.  From-munging is just not part
of the community standard in most lists I participate in (and I've
heard that some Yahoo! and AOL users object violently to the
mitigations used to keep their posts from bouncing all over the world).

Anne Bennett:

 > > I'm not against the idea that mailing list software might have to
 > > adapt to the new reality (of the need for protection against
 > > spoofing), even though there will be a lengthy transition period.

Hardly.  It's already done, at least in GNU Mailman: all of the
transformations that invalidate DKIM signatures are optional.
From-munging was *released* in October 2013 (in 2.1.16 IIRC).  That's
right, *before* the April DMARC Debacle.  We have continued to refine
the features (it's now possible in 2.1.18-1 to condition mitigations
on a DNS lookup for "p=reject").  The software is not the problem.
The list owners and list subscribers are.

Back to Dave:

 > I think the historical challenge has less been a case of
 > philosophical legitimacy

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.  Nevertheless, GNU Mailman has a From-Munging option.[1]

 > and more of inability to gain active, constructive participation of
 > mailing list software maintainers.

Hey, I resent that.  You guys use GNU Mailman; you know where to find
us if you want participation.

Sure, we resist doing what is proposed.  The fact is that choices
we've been offered suck.  Go away (the choice offered by experimental
early versions of SPF)?  You jest.  From-Munging?  Yuck -- and guess
what, you're no fan, yourself.  No subject tags, no footers?  Excuse
me, but prohibiting a valuable feature is exactly the opposite of a
constructive change -- and you don't like this mitigation yourself.
Note that these mitigations are now in GNU Mailman, as options.  But
most list owners don't want them.

We've come up with our own (RFC-conforming) mitigations.  They suck,
too (MUAs are not prepared to deal with them gracefully, or in the
case of iOS Apple Mail, at all).

It's not the MLM developers you have a problem getting cooperation
from.  It's our users.

Bottom line: making indirect mail flows compatible with DMARC-style
spoof-protection is a hard problem.


Footnotes: 
[1]  Patch courtesy of Franck Martin.


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

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

[Anne Bennett]

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, displaying
>>   them with an indication of unreliabiliy, or even ignoring the
>>   entire signature if it does not cover certain header fields.
>> 
>> So, risking Dave's wrath once again by discussing possible UI
>> approaches to verification information, if a header tag format
>> were specified (for example) to be contained within square
>> brackets, the UI could display the verified part one way,
>> and the tagged-and-ignored part another way.

> To make any assertions about preferred or appropriate UI behavior is to
> require establishing the basis that the behavior will be useful.

I dispute the idea that the above text makes assertions about
"preferred" UI behaviour - rather, it mentions what might
be possible (and yes, implies that it could be appropriate),
without excluding other approaches.

> The problem here is that the empirical basis for efficacy is lacking.

True, and I agree that it's not up to us to propose
user interface designs.  But our work will be used by UI
designers; how can we best make sure that we give them the
informational tools they need in order to display a given
message "appropriately"?

Do you propose that since the UI is outside our scope, that
we give no consideration at all to the tools that might be
needed in order to implement a UI?



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

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

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

[Dave Crocker]

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, even if it has had to be adopted as a workaround
> in the short run.

Formally and practically, they are more than mere re-distributors.

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.

Mailing lists therefore have the right to make the changes they make.

That said, recipients consider the message to be 'from' and 'by' the
original author, not the mailing list.


> As for subject tags and list trailers, at least the former is
> really helpful to me as a user (sorry, Dave! ;-) ), as it lets

Huh?  I /like/ Subject tags.  They help to distinguish list mail from
personal mail.


> me know that a given message is in the context of a public or
> semi-public discussion.

Right.


> I'm not against the idea that mailing list software might have to
> adapt to the new reality (of the need for protection against
> spoofing), even though there will be a lengthy transition period.

I think the historical challenge has less been a case of philosophical
legitimacy and more of inability to gain active, constructive
participation of mailing list software maintainers.


> rfc6376 has:
> 
>   Note that Verifiers may treat unsigned header fields with
>   extreme skepticism, including refusing to display them to
>   the end user or even ignoring the signature if it does not
>   cover certain header fields.
> 
> 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, displaying
>   them with an indication of unreliabiliy, or even ignoring the
>   entire signature if it does not cover certain header fields.
> 
> So, risking Dave's wrath once again by discussing possible UI
> approaches to verification information, if a header tag format
> were specified (for example) to be contained within square
> brackets, the UI could display the verified part one way,
> and the tagged-and-ignored part another way.

This is less a case of wrath -- should I be glad of such de facto and
automatic intimidation, even when it doesn't work well enough to squelch
others' views I disagree with?  Hmmm... -- and more a case of efficacy.

To make any assertions about preferred or appropriate UI behavior is to
require establishing the basis that the behavior will be useful.

The problem here is that the empirical basis for efficacy is lacking.

So making a recommendation might serve to make the specification writers
feel better, but they won't help fight abuse.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Anne Bennett]

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 Header-From for the messages whose DKIM
> signature they break, and all is back to working great again!

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, even if it has had to be adopted as a workaround
in the short run.

As for subject tags and list trailers, at least the former is
really helpful to me as a user (sorry, Dave! ;-) ), as it lets
me know that a given message is in the context of a public or
semi-public discussion.

I'm not against the idea that mailing list software might have to
adapt to the new reality (of the need for protection against
spoofing), even though there will be a lengthy transition period.

But we can also consider whether there are any changes to DKIM
which would enable mailing lists not to break, or at least,
which would not require changes which negatively affect the
user experience for mailing list subscribers.  Please forgive
me if this has been discussed before (it seems inconceivable
to me that it hasn't), but it should be possible to specify
a format for header tags such that the tag is not included in
the DKIM signature check for the Subject: line.

rfc6376 has:

  Note that Verifiers may treat unsigned header fields with
  extreme skepticism, including refusing to display them to
  the end user or even ignoring the signature if it does not
  cover certain header fields.

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, displaying
  them with an indication of unreliabiliy, or even ignoring the
  entire signature if it does not cover certain header fields.

So, risking Dave's wrath once again by discussing possible UI
approaches to verification information, if a header tag format
were specified (for example) to be contained within square
brackets, the UI could display the verified part one way,
and the tagged-and-ignored part another way.

I do freely admit that I don't know the implications of
making it possible to sign only part of a given header.
And I suspect that my suggestion may belong more on a DKIM
discussion list than a DMARC discussion list...


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

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

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

[Stephen J. Turnbull]

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 same thing.  What I am saying is that
DMARC is already a "success as an implemented technology in the real
world" by any reasonable standard, because it *does* work for exactly
the transactional mail flows you worry about.  And it is possible to
*prove* that it does work by looking at the properties of checks for
individual messages.

On the other hand, DMARC and similar technologies *cannot* solve the
problem of spam and other abuse by those with whom you've had no
previous relationship.  That's easy to prove too: anybody with access
to a DNS server can add DMARC and DKIM records and sign their mail.

Mailing lists (among other indirect mail flows) do have problems
interacting with DMARC, and it's worth trying to solve those problems.
But they are not going to reverse DMARC's success.

 > I know that DMARC is not the silver bullet.

If you know that, I do not understand how you can classify DMARC as
anything but a success.  I'm an MLM developer; I hate p=reject with a
passion.  But I can't deny that for the vast majority of mail, DMARC
works as advertised, p=reject included.

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

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

[Anne Bennett]

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 worried that their account was
compromised because they're receiving bounces for spam they never
sent, wondering why their best friend is suddenly sending them ads
or malware, or responding to phish messages.  In the first two cases,
they believe the "From:" header when they shouldn't; in the last case,
too often they don't even look at the domain in the From: header.

I haven't kept incident stats, so I cannot give you data that
we could reliably use to measure the likely effectiveness of
one approach or another, but my experience is objective and
empirical, in the sense of having been "acquired by means of
observation or experimentation".

But we're straying from the topic, which is indeed to come up with
technical specs that software can obey.  Having said that:

>> One could argue, I suppose, that once again we're talking
>> about the behaviour of software, but the point of all this,
>> unless I woefully misunderstand, is to protect the user from
>> fraud due to the faked provenance of a message. 
> 
> As a very general mission statement -- or an even higher-level motivator
> for working in this space -- perhaps, but that has essentially no effect
> on design choices here.

If "the point of all this" has "essentially no effect on design
choices", we have a serious problem.  It's all very well do do
things right, but we have to make sure we're doing the right
thing too.

> 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
message, the user isn't involved, but as soon as those decisions
can result in tagging a message for possible consideration by the user
(probably via different display by the UI), we can't ignore the user.

I agree that this isn't the place to delve deeply into user behaviour
and UI design.  But we shouldn't ignore the context of our work.



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

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

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

[J. Gomez]

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 an error of logic.  *Authenticity* (defined as "did the
> message satisfy DMARC From alignment when injected?") of *each*
> message *can* be verified independently of other messages, and if From
> alignment is verified, the message *is* authentic (modulo black
> helicopters with 4096-bit encryption breaking equipment).  It's what
> to think about non-verifiable mail that becomes unclear.

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

So I say it again, now in fully qualified terms: Verifiable authenticity of 
email greatly depends on DMARC's success as an implemented technology in the 
real world.

> Since the "important" mail is direct mail, From alignment will be
> preserved until received by the addressee.  Therefore list behavior
> only affects DMARC verifiability of list traffic, *not* those other
> mail flows, as far as I can see.

I explain: if mailing-lists configured old-style keep DMARC from being a 
success in the real world, then mailing-lists are hindering the extra notch of 
trustworthiness that DMARC could bring to important email communications for 
end users as a whole. So it's not about individual messages, as you seem to be 
talking about, but about the big picture.

And it is that big picture which is begging for mailing-lists operators to 
abandon their old-style practices and to begin to take ownership in the 
Header-From of the email they relay and modify while in-flight rendering its 
original DKIM signature invalid.

> The "requirement" you propose is not implementable in a software
> system alone, whether it is satisfied or not cannot be verified from
> the behavior of software alone, and therefore cannot be posited as a
> requirement in the sense used in software engineering.

I know that DMARC is not the silver bullet. That's way I said it "brings an 
extra notch of trustworthiness" to email, I didn't say DMARC brings final and 
ultimate trustworthiness.

Regards,
J.Gomez

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

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

[Stephen J. Turnbull]

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 From alignment when injected?") of *each*
message *can* be verified independently of other messages, and if From
alignment is verified, the message *is* authentic (modulo black
helicopters with 4096-bit encryption breaking equipment).  It's what
to think about non-verifiable mail that becomes unclear.

Since the "important" mail is direct mail, From alignment will be
preserved until received by the addressee.  Therefore list behavior
only affects DMARC verifiability of list traffic, *not* those other
mail flows, as far as I can see.

 > Well, I posit the user requirement is, at large, to take email to
 > the next level a viable medium for important communications.

I understand what you're saying, and we all agree that email as we
currently know it has an important role for Internet communication,
and that for it to continue to fulfill that role we need to improve
its security in several ways.  But (as Dave Crocker is emphasizing in
another subthread), we need to be very careful to define requirements
in terms of what the software can do, and then do our best to
define and implement protocols that satisfy the requirements and
*prove* that the software does satisfy those requirements.

The "requirement" you propose is not implementable in a software
system alone, whether it is satisfied or not cannot be verified from
the behavior of software alone, and therefore cannot be posited as a
requirement in the sense used in software engineering.

Please think about what I've written.  It's a very useful way to think
about software systems, and IETF discussions are normally phrased
using this kind of language.  If you don't use it, people will not
know what you're talking about, and your ideas will not be picked up.

Steve

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

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

[J. Gomez]

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 change anyone's mind.  False
> assertions are like these are utterly useless.
> 
> Please stop.

To castle into old denial will not change anyone's mind, either.

But please, go on.

Regards,
J. Gomez

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

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

[John Levine]

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

Please stop.

R's,
John

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

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

[J. Gomez]

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)
> > > > delivered to their inbox?
> 
> I don't see why enabling mailing lists to continue their traditional
> practice of adding tags to Subject and footers to the message body
> would cause any problems whatsoever for authentic direct mail from the
> businesses you mention.

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.

If mailing-lists configured old-style hinder the adoption and ultimate success 
of DMARC, then received email will not be able to be verified as authentic in 
any systematic way, but only heuristically. That greatly lessens the value of 
email as a viable medium for important[*] communications that users want to 
receive.

[*] I define here "important" as: "potentially expensive for the user if missed 
and/or potentially expensive for the user if successfully spoofed".

Therefore, as per the above reasoning, given that the "traditional practice of 
mailing lists adding tags to Subject and footers to the message body" breaks 
DMARC, it is also breaking the mechanism (DMARC) which could take email to the 
next level as a viable medium for important communications.

I vote for steam-rolling mailing lists configured old-style to the history 
books. Mailing list operators just need to take ownership in the Header-From 
for the messages whose DKIM signature they break, and all is back to working 
great again!

> > You say that as if a solution that works but you don't like is not
> > a solution but a kludge.
> 
> It is.  A *solution* is a practice or product that satisfies user
> requirements.  If there's only one such user, OK, you can say "tough
> on you."  However, *many* mailing list users wish to have the author's
> address in "From" where it will be automatically and naturally used
> for reply-to-author in almost all MUAs.  As far as I know there is no
> configuration of From and Reply-To that satisfies this requirement in
> all use cases.

Well, I posit the user requirement is, at large, to take email to the next 
level a viable medium for important communications.

Regards,
J.Gomez

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

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

[Dave Crocker]

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

Unfortunately, user references for this sort of work have no productive
use to that work, but instead often prove counter-productive.

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.

That's why I keep stressing the importance of keeping user references
out of these discussions.  They are not helpful to the work and they are
distracting.


> not unreasonable to suppose that the writer of a user interface
> would want to indicate somehow to the user that the message was
> (or was not) vetted as coming from where it says it came from.
> The DMARC results seem like an obvious source of information
> for such an indication.

"Not unreasonable' is a common justification for UI design choices.

The reality of successful UI design is that many choices that are "not
unreasonable" don't work or work poorly.

Consequently, "not unreasonable" is a singularly insufficient
justification.  At the very best, it can serve to provide input to
experimental processes that investigate actual efficacy.


> One could argue, I suppose, that once again we're talking
> about the behaviour of software, but the point of all this,
> unless I woefully misunderstand, is to protect the user from
> fraud due to the faked provenance of a message. 

As a very general mission statement -- or an even higher-level motivator
for working in this space -- perhaps, but that has essentially no effect
on design choices here.

In practical and operational terms, the point of all this is to allow
filtering engines to make better decisions about possibly-spoofed mail.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[MH Michael Hammer (5304)]

> -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 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 not without sympathy to your point of view.
> DMARC is obviously intended to be applied by the software, and it's
> tempting to think that the message is either accepted or rejected, end of
> story, so this shouldn't affect the user interface or user behaviour.  In
> practice I don't think it's that simple.
> 
> 
> Of course, because of the way DMARC is applied (in the DNS) and messages
> are signed (by the ISP), the sending user is not of concern here.  The
> expressed concerns center on the perceptions and behaviour of the
> receiving user.

Messages can be (DKIM) signed by any entity that handles the messages in 
question, not just by an ISP. Aligned (DKIM) signing can only be done with the 
permission of the domain owner/administrator. Messages may be unsigned and 
validated on the basis of SPF. 

> 
> If p=none (or if DMARC is not used), then the receiving user gets the
> message (modulo other de-spamming techniques), but nothing can be
> implied about its authenticity, so nothing changes with respect to the non-
> DMARC behaviour (of the software or the user!).
> 

Certainly something can be implied about its authenticity. All p=none says is 
don't apply policy to the validation.

> And if the message is rejected due to p=reject, then the user never gets the
> message at all, so we needn't be concerned with the receiving user's
> behaviour.
> 

Sure we can - if it's a false positive for an expected message and it never 
arrives. The receiving user's behavior !=happiness.

> 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.  It seems not unreasonable to suppose that the writer of a
> user interface would want to indicate somehow to the user that the message
> was (or was not) vetted as coming from where it says it came from.
> The DMARC results seem like an obvious source of information for such an
> indication.
> 

DMARC addresses only the specific case of direct domain abuse. If I go out and 
register the domain concordia.co and I send messages from 
a...@encs.concordia.co to targeted recipients with SPF/DKIM/DMARC properly 
configured, do you really want to give a trust indicator to those end users 
based on messages passing DMARC? Presumably Concordia.co would ultimately end 
up on a block list but would you really want to give trust indicators in the 
interim?

> One could argue, I suppose, that once again we're talking about the
> behaviour of software, but the point of all this, unless I woefully
> misunderstand, is to protect the user from fraud due to the faked
> provenance of a message.  I don't think it will ever be the case that we can
> sort 100% of messages as "authentic" or "fake" before they reach the user;
> we have to accept that even if we block the "known fakes" based on
> DMARC, there will still be authenticated and not-checkable messages that
> reach the user - and ideally we'd have a way to indicate which are which.
> 
> 
> 
> Anne.
> --
> Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal
> H3G 1M8
> a...@encs.concordia.ca+1 514 848-2424 
> x2285
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

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

[Anne Bennett]

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 not without sympathy to your
point of view.  DMARC is obviously intended to be applied by
the software, and it's tempting to think that the message is
either accepted or rejected, end of story, so this shouldn't
affect the user interface or user behaviour.  In practice I
don't think it's that simple.


Of course, because of the way DMARC is applied (in the DNS)
and messages are signed (by the ISP), the sending user is
not of concern here.  The expressed concerns center on the
perceptions and behaviour of the receiving user.

If p=none (or if DMARC is not used), then the receiving
user gets the message (modulo other de-spamming techniques),
but nothing can be implied about its authenticity, so nothing
changes with respect to the non-DMARC behaviour (of the software
or the user!).

And if the message is rejected due to p=reject, then the user
never gets the message at all, so we needn't be concerned with
the receiving user's behaviour.

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.  It seems
not unreasonable to suppose that the writer of a user interface
would want to indicate somehow to the user that the message was
(or was not) vetted as coming from where it says it came from.
The DMARC results seem like an obvious source of information
for such an indication.

One could argue, I suppose, that once again we're talking
about the behaviour of software, but the point of all this,
unless I woefully misunderstand, is to protect the user from
fraud due to the faked provenance of a message.  I don't think
it will ever be the case that we can sort 100% of messages as
"authentic" or "fake" before they reach the user; we have to
accept that even if we block the "known fakes" based on DMARC,
there will still be authenticated and not-checkable messages
that reach the user - and ideally we'd have a way to indicate
which are which.



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

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

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

[Dave Crocker]

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
meaningful analysis or development of technologies like DMARC.

At a minimum, a reference to users tends to cause people to project
benefits that will not accrue.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Murray S. Kucherawy]

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 in DMARC.
> >
> > What's so inconvenient about it?
>
> 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.  They mostly don't
> see the domain name, and it mostly doesn't matter when they do.
>
> On the other hand, the fact that the From field is the only domain name
> reliably associated with content creation and that receiving filtering
> engines can do an assessment of validity when DMARC validates, is
> extremely meaningful.  But there is no 'user' in the handling equation
> for DMARC.
>

That's true, I suppose, but there are lots of components of a message
system that don't include user input.  Spam filters don't have user input
but they do care about what gets past them, because their purpose is to
identify and prevent delivery of things that are either annoying or
deceptive.  The user is most certainly the focus.

I'm not disagreeing, but I'm not sure where you're going with this...

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

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

[Stephen J. Turnbull]

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 their traditional
practice of adding tags to Subject and footers to the message body
would cause any problems whatsoever for authentic direct mail from the
businesses you mention.

 > You say that as if a solution that works but you don't like is not
 > a solution but a kludge.

It is.  A *solution* is a practice or product that satisfies user
requirements.  If there's only one such user, OK, you can say "tough
on you."  However, *many* mailing list users wish to have the author's
address in "From" where it will be automatically and naturally used
for reply-to-author in almost all MUAs.  As far as I know there is no
configuration of From and Reply-To that satisfies this requirement in
all use cases.



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

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

[Stephen J. Turnbull]

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 didn't say that, but I'll say it now, too.  (Ignoring the underying
 > truth that users get tricked, which provides the motivation for worrying
 > about spoofing.)

Ignoring motivation was appropriate for Milestone 1, which was
concerned with ensuring a lack of ambiguity in RFC 7489, which has a
well-defined set of requirements.

But we are now looking at "next steps", ie, a new set of requirements,
because implementing the RFC 7489 requirements turned out to be
insufficient to enable many use cases people participating in this WG
care about, and to have some rather nasty side effects in combination
with preexisting systems.  I think discussion of motivation and agent
(not limited to mail recipients) behavior is exactly what is needed at
this stage, even if it's rather speculative and not founded in formal
user interface research.


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

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

[J. Gomez]

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? 
> 
> My impression is that most users put a very low value on commercial
> bulk mail.  I'm not aware of any statistics available to the public.

Authentic email from eBay, Amazon, Paypal and American Airlines may not be 
"commercial bulk email." Instead, it can be email confiming the success of 
important transactions, account break-in attempts, or notifying changes in 
schedules, etc., and therefore be of very high value to end-users.

> > Also, your mailing list would work again in a heartbeat, in a
> > DMARC-world, if you just configured them to put the original
> > Header-From into the "description" of a new Header-From, like:
> 
> We are aware of the various kludges to circumvent DMARC breakage.  We
> have a whole wiki about them at
> http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail
> 
> Rehashing them here and asserting that they are solutions rather than
> kludges would not be productive.

You say that as if a solution that works but you don't like is not a solution 
but a kludge. Internet Email is built on a pile of kludges after kludges. It 
just wasn't designed to live as long as it has.

Why is this kludge of a solution worst that the kludge of closing down open 
email relays in the past? The disappearance of open email relays surely 
affected badly several legitimate use cases of email...

Regards,
J.Gomez

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

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

[John Levine]

>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 aware of any statistics available to the public.

>Also, your mailing list would work again in a heartbeat, in a DMARC-world, if
>you just configured them to put the original Header-From into the "description"
>of a new Header-From, like:

We are aware of the various kludges to circumvent DMARC breakage.  We
have a whole wiki about them at
http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

Rehashing them here and asserting that they are solutions rather than
kludges would not be productive.

R's,
John

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

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

[Stephen J. Turnbull]

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, many were forced to use it in the Great DMARC
Fiasco of last April, and they hate it.  So we are not going to force
it on anybody.

I can't speak for other MLM maintainers, but I suspect many have had
similar experiences and probably all have some list owners who hate
the idea of "taking ownership" -- they'll probably make it optional
too.

Many of us hate the idea in principle, anyway.  In our interpretation
of RFC 5322 the modifications the MLM makes do not create a new
message any more than adding Received fields does (and of course there
are very good reasons to keep the Message-Id).

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

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

[Dave Crocker]

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 anybody advocating that.  The claim is that the user
> behavior changes with the identity in the From field, and whether they
> trust its authenticity.

Right.

And this is claimed in the absence of supporting research and to the
contrary of usability experience.



>  > But there is no 'user' in the handling equation for DMARC.
> 
> Is that all you are trying to say?  That seems tautological to me,
> since DMARC is a software system that operates (usually) in the MTA.

Heh.


> 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 didn't say that, but I'll say it now, too.  (Ignoring the underying
truth that users get tricked, which provides the motivation for worrying
about spoofing.)


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Stephen J. Turnbull]

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 changes with the identity in the From field, and whether they
trust its authenticity.

People do make a lot of fuss about the display of the domain (eg,
DMARC itself deprecates From munging that puts the address in a
comment or the display name in From).  While that isn't the whole
story (can't be, since often the domain isn't displayed by the MUA),
the address in From is an important part of the correspondent's
identity, and users tend to trust that it's authentic and the MUA is
using the "right" one for each correspondent.  I think it's reasonable
to suppose that the identity in From does affect user behavior.

 > But there is no 'user' in the handling equation for DMARC.

Is that all you are trying to say?  That seems tautological to me,
since DMARC is a software system that operates (usually) in the MTA.

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.

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

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

[Murray S. Kucherawy]

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 sender's domain Owner.
>

I have to agree.  I've seen nothing since the advent of SPF to convince me
otherwise.  Several have been proposed and none have seen anything more
than trivial uptake, even when written down as experimental RFCs or made
freely available in open source code.

An argument has been made that they got no uptake because they are flawed,
but I think that's myopic; the ones that are available are not set in stone
and thus could be easily mutated into something more palatable if there was
actual interest.  That nobody has proposed anything of the form "We would
implement third-party scheme X if only it had Y done to it" tells me that
the general idea is a dead end, not that the specific proposals on the
table are faulty.

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

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

[J. Gomez]

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
> is fairly low, but it is very high value.
> 
> Personally, I would be happy never to get any more mail from my bank,
> if it meant that my mailing lists would work again.

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?

Also, your mailing list would work again in a heartbeat, in a DMARC-world, if 
you just configured them to put the original Header-From into the "description" 
of a new Header-From, like:

From: "Pedro Antunez"   ==>  From: "Pedro Antunez 
pe...@example.com" 

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.

Regards,
J.Gomez

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

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

[J. Gomez]

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"  and if even if you
> do work it, you have to champion it.  One can't write documents nor
> work on ideas while still believing it won't work. If you (the
> authors) don't believe it, no one else will -- the bottom line.

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 sender's domain Owner.

Consider Yahoo and OAL reckless usage of "p=reject". Why would they suddenly be 
any less reckless and choose to take into account any "3rd party authorization 
scheme" for DMARC? Do we have any hint from big ESPs currently using "p=reject" 
that they are willing to take into account any "3rd party authorization scheme" 
for DMARC? If not, we have the risk to taking the effort to design a great "3rd 
party authorization scheme" for DMARC which ultimately will fail to be taken 
into account in any significant way in the real world.

So, Hector, no matter how good "marketing" is, it is going to be next to 
impossible to sell something which is nuanced and labour-intensive, and at the 
same time provides little --perceived-- reward to the agents tasked with 
implementing it and keeping it current and running in a well-oiled fashion.

Regards,
J.Gomez

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

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

[Dave Crocker]

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 'originator' but yeah, I should have
thought of a more generic term.  I meant not to invoke 'originator' and
meant mean "something around the creation of the message, such as
author, originator, gateway mta, whatever..."[*]


>  and there's nothing in RFC 5322 that says it does.  RFC 5322 says
> you shouldn't put an address in From that you don't have the right to
> use, not that it must be aligned with the domain of the injecting MTA.

Thanks for the refresher.


> So I must be missing something, because it seems to me that you've got
> the DMARC From alignment tail wagging the whole RFC 5322 dog here.

No idea what you mean.


>  > 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 in DMARC.
> 
> What's so inconvenient about it? 

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.  They mostly don't
see the domain name, and it mostly doesn't matter when they do.

On the other hand, the fact that the From field is the only domain name
reliably associated with content creation and that receiving filtering
engines can do an assessment of validity when DMARC validates, is
extremely meaningful.  But there is no 'user' in the handling equation
for DMARC.


 There may be other
> subtle channels by which the address can influence user behavior
> without being displayed as a character string.  And sometimes it is
> presented as a string.
> 
> Note that these "subtle channels" are MUA functions, and thus outside
> the purview of current MTA-based DMARC implementations.  I think it's
> quite valid to emphasize the user's role here.

Subtle channels is a fun idea.  Unfortunately there is an infinite
number of fun ideas.

Perhaps you can cite some empirical research evidence of its relevance
to this topic?


d/


[*]  However note that the essence of DMARC is a /very/ tight coupling
between content author's domain owner and the originator.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[John Levine]

>> 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 get any more mail from my bank,
if it meant that my mailing lists would work again.

R's,
John

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

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

[Stephen J. Turnbull]

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 address in From that you don't have the right to
use, not that it must be aligned with the domain of the injecting MTA.

So I must be missing something, because it seems to me that you've got
the DMARC From alignment tail wagging the whole RFC 5322 dog here.

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

What's so inconvenient about it?  I'm apparently missing something,
but I don't see how the fact that the domain sometimes isn't presented
is particularly inconvenient for the position that user behavior
matters.  Specifically, in many cases failure to present the domain as
a character string doesn't mean that the displayed identity isn't
associated with the address in some way such as presentation of an
avatar looked up by address, or in a tool-tip.  There may be other
subtle channels by which the address can influence user behavior
without being displayed as a character string.  And sometimes it is
presented as a string.

Note that these "subtle channels" are MUA functions, and thus outside
the purview of current MTA-based DMARC implementations.  I think it's
quite valid to emphasize the user's role here.

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

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

[Hector Santos]

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 write documents nor 
work on ideas while still believing it won't work. If you (the 
authors) don't believe it, no one else will -- the bottom line.


Just consider that DMARC has a problem that all the previous POLICY 
FRAMEWORKS long had. So how could DMARC replaced ADSP as the "Super 
ADSP" when ADSP was abandoned by the key DKIM people within the IETF? 
 It does the same thing, same problem?  How was that possible?


Marketing.

DMARC did have the REPORTING part that we intentionally left out in 
coming up with SSP/ADSP.  The view was it would eventually could be 
abused and most certainly it would be become a high overhead redundant 
reporting feature -- can't be reporting forever.


Thats the one thing I believe I underestimated when I strongly 
supported and implemented the previous DKIM policy ideas such as SSP 
and ADSP and also my I-D DSAP (DKIM Signature Authorization Protocol) 
where some of the initial MLM interfacing ideas were written down.


Overall, you got to have a solid protocol first that makes sense 
independent of any mail component that touches mail.   I believe we 
had something with DKIM + POLICY but it requires you to change the the 
MLM software or its frontend interface to follow the POLICY concept. 
Until that happens, nothing is going to change.


--
HLS



On 3/20/2015 4:56 PM, J. Gomez wrote:

On Wednesday, March 18, 2015 11:40 PM [GMT+1=VET], 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 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 trustworthiness that DMARC alignment 
provides?

How big is the volume of DMARC-problematic indirect email flows, compared to 
the general volume of email which can readily benefit from DMARC?

Regards,

Regards,
J.Gomez

___
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] Next steps for RFC 7489 (DMARC)

[Dave Crocker]

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 provided by the author.
> 
> Isn't it important that this information is also the most likely to be
> presented to the end user as the author of the content that's also shown
> to the user? Why do you claim it doesn't matter?
> 
> There would be a lot less incentive to be concerned about From:
> alignment if that were not the case.


It's important to distinguish between the initial reason people were
motivated to work on DMARC, versus what DMARC does.

 Users do not process DMARC.

 When talking about a protocol, talk about the entities
 that process it.

From: happens to be the only place that always has the presence of a
domain associated with the origin. 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 in DMARC.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Murray S. Kucherawy]

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 benefit.
>
>
> I'd like to try to get us to phrase this differently.
>
> 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 provided by the author.
>

Isn't it important that this information is also the most likely to be
presented to the end user as the author of the content that's also shown to
the user? Why do you claim it doesn't matter?

There would be a lot less incentive to be concerned about From: alignment
if that were not the case.

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

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

[Stephen J. Turnbull]

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 try to get us to phrase this differently.
 > 
 > 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 provided by the author.
 > 
 > Everything about DMARC derives from the certainty of that presence.

Except for the very existence of DMARC, which was primarily motivated
by phishing and "recommended-by-friend spam", which depend on what the
recipient sees, and the recipient's association of trustworthiness
with the message's apparent author.

So no, the filtering agents don't really matter to DMARC as far as I
can see.  What matters to DMARC is when inauthentic From addresses get
past the filtering agents.  At that point DMARC intervenes and
(optionally at the domain owner's request) interdicts inauthentic
addresses in From:.

Steve


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

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

[Stephen J. Turnbull]

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 thinking of the same thing that Douglas is.  To him,
I suppose "adapting DMARC" includes third-party authorization
mechanisms.  I consider those actually to be "adapting DMARC" because
they require participation of the first party.

YMMV, you may consider that "adapting indirect mail" because often it
will be initiated by the 3rd party applying for authorization.
However, several proposals have been made for limited authorization by
mailbox owners who can't actually change the DMARC policies of the
authorizing domain.  These also require participation of the
authorizing domain but not necessarily the third party.  So I prefer
our interpretation that TPA is "adapting DMARC".

Steve

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

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

[Dave Crocker]

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.

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 provided by the author.

Everything about DMARC derives from the certainty of that presence.

For a mechanism, like DKIM, that seeks a collaborative relationship
between origin and destination, there does not need to be certainty that
the information will be present.  There merely needs to be certainty
that /if/ it is present, it is valid.

DMARC is not like that.  DMARC is an effort to look for spoofing.  This
means that bad actors will attempt to place the trust-related
information (like a domain name) into the message, but without
authorization.

So, what domain name is certain to be in the message, other than the one
in the From field?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Murray S. Kucherawy]

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 trustworthiness that DMARC
> alignment provides?
>
> How big is the volume of DMARC-problematic indirect email flows, compared
> to the general volume of email which can readily benefit from DMARC?
>

I'm pretty sure volumes are not the problem as much as the painful side
effects, most notably unsubscription of uninvolved users from mailing lists
when someone protected by DMARC posts to the list.  (See Section 5.2 of
RFC6377, which describes the same problem in the context of ADSP.  RFC7372
might help with this, if and when it ever gets widely implemented.)

My own view is that we should pursue whichever of the two avenues is the
lower-hanging fruit.  The problem at the moment is that it's not at all
clear to me which of the two that is.  We have among us implementers of
both MLM packages and DKIM/SPF packages and standards, so at least the
right people are "in the room".  There are, however, substantial barriers
in both directions.

We definitely have our work cut out for us.

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

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

[Scott Kitterman]

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 with indirect mail flows
> 
> 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 trustworthiness that DMARC
> alignment provides?
> 
> How big is the volume of DMARC-problematic indirect email flows, compared to
> the general volume of email which can readily benefit from DMARC?

I think it's fair to say it varies a lot.  I took a look at the reports for my 
personal domain for roughly the last week.   All the mail was SPF pass, DKIM 
signed, and aligned went sent.  Here's the numbers (keep in mind that 
receivers are likely to count multiple recipients of mailing list messages as 
multiple message - I don't actually write 5,000 emails a week):

Total: 5,029
My Serverss: 6
Mail List/Forwarded SPF and DKIM fail: 5,022
Mail List DKIM pass: 1

In my case (since a lot of my mail is via email lists) it's essentially all of 
it.

Scott K

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

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

[J. Gomez]

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 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 trustworthiness that DMARC alignment 
provides?

How big is the volume of DMARC-problematic indirect email flows, compared to 
the general volume of email which can readily benefit from DMARC?

Regards,

Regards,
J.Gomez

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

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

[Murray S. Kucherawy]

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 not sure that declaring and supporting yet another
no-seriously-this-is-the-author field would be of benefit.  Rather, I think
it would just confuse things further.

The closest thing I can see is considering use of Sender somehow, since
there are even a few MUAs that do pay vague attention to it.  But that's
extremely hand-wavy to start with.

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

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

[Douglas Otis]

> On Mar 18, 2015, at 4:38 PM, Terry Zink  wrote:
> 
>> Based upon the almost complete lack of interest of
>> bulk email providers at promoting a solution, it seems the path
>> forward is to define a new non-aligned header field able to retain the 
>> author role information, otherwise the From is likely overwritten as 
>> the only practical means of ensuring message acceptance in the face of 
>> provider DMARC (ab)use.
> 
> 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?
> 
> -- Terry

Dear Terry,

Thank you for your comment.  This WG seems indicative of most bulk sender's
who often ask "How is DMARC's disruption of legitimate messaging a problem 
for me?" They are clearly not interested in preserving the social and civic 
benefits derived from open exchanges enabled by email affected by the DMARC 
(ab)use occurring against millions of users.

This is further evidenced by the current DMARC scheme that offers no strategy 
for preserving the role of Author for messages handled by various 
third-parties.  
Those operating a mailing-list are being forced to either reject a large 
percentage of their users, or replace the From header with what was likely to 
have been the Sender header field.  The identity of the Author becomes 
undefined and might be moved to the Reply-to or perhaps x-original-from header 
fields.

Unless DMARC defines a fallback policy which allows alignment with that of 
the Sender header field, the role of Author is placed at risk.  In such 
cases, defining a special "Non-Aligned From" header field could help better 
define where this role might be found in a message without it being
automatically displayed.  This header field might even offer provisions for
the tagging often found in the Subject header field.

Perhaps call this new header field "Author".  Since few MUAs are likely to 
display this header, only those that make extensive use of email that depends
on third-party services are likely to ensure it being displayed.  An
approach that would not require cooperation from Bulk senders, while still
allowing forums a means to track a history of who said what. 

Regards,
Douglas Otis

> -Original Message-
> From: 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, 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/html/draft-otis-dmarc-author-align-01
> was written to highlight possible solutions.
> 
> John Levine's recommendation that mailing-list operators take on 
> the costly burden of having their participants change their providers 
> is not practical.  Based upon the almost complete lack of interest of
> bulk email providers at promoting a solution, it seems the path
> forward is to define a new non-aligned header field able to retain the 
> author role information, otherwise the From is likely overwritten as 
> the only practical means of ensuring message acceptance in the face of 
> provider DMARC (ab)use.
> 
> By defining a new header field, this should reduce disparity in where to 
> find the author role than that caused by current ad hoc solutions.  Such 
> a definition would also better avoid downgrading 'reject' into 
> 'quarantine'.
> 
> Any thoughts?
> 
> Regards,
> Douglas Otis

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

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

[Terry Zink]

> Based upon the almost complete lack of interest of
> bulk email providers at promoting a solution, it seems the path
> forward is to define a new non-aligned header field able to retain the 
> author role information, otherwise the From is likely overwritten as 
> the only practical means of ensuring message acceptance in the face of 
> provider DMARC (ab)use.

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?

-- Terry

-Original Message-
From: 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, 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/html/draft-otis-dmarc-author-align-01
was written to highlight possible solutions.

John Levine's recommendation that mailing-list operators take on 
the costly burden of having their participants change their providers 
is not practical.  Based upon the almost complete lack of interest of
bulk email providers at promoting a solution, it seems the path
forward is to define a new non-aligned header field able to retain the 
author role information, otherwise the From is likely overwritten as 
the only practical means of ensuring message acceptance in the face of 
provider DMARC (ab)use.

By defining a new header field, this should reduce disparity in where to 
find the author role than that caused by current ad hoc solutions.  Such 
a definition would also better avoid downgrading 'reject' into 
'quarantine'.

Any thoughts?

Regards,
Douglas Otis






___
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] Next steps for RFC 7489 (DMARC)

[Douglas Otis]

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/html/draft-otis-dmarc-author-align-01
was written to highlight possible solutions.

John Levine's recommendation that mailing-list operators take on 
the costly burden of having their participants change their providers 
is not practical.  Based upon the almost complete lack of interest of
bulk email providers at promoting a solution, it seems the path
forward is to define a new non-aligned header field able to retain the 
author role information, otherwise the From is likely overwritten as 
the only practical means of ensuring message acceptance in the face of 
provider DMARC (ab)use.

By defining a new header field, this should reduce disparity in where to 
find the author role than that caused by current ad hoc solutions.  Such 
a definition would also better avoid downgrading 'reject' into 
'quarantine'.

Any thoughts?

Regards,
Douglas Otis






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