Re: [dmarc-ietf] DMARC's purpose

[Terry Zink]

> Should we also document in this Murray's draft that MS-Exchange breaks 
> DKIM on forwarding, inventory all the operational cases?

1. If a message is sent via Exchange with a 3rd party DKIM signer, then DKIM 
will not be broken if the next Exchange hop forwards.

2. Messages will be preserved with DKIM in a future release of Exchange, we use 
it internally and it works.

-- Terry

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Franck Martin
Sent: Wednesday, April 16, 2014 10:05 AM
To: Barry Leiba
Cc: Dave Crocker; dmarc@ietf.org; Murray Kucherawy
Subject: Re: [dmarc-ietf] DMARC's purpose





- Original Message -
> From: "Barry Leiba" 
> To: "Dave Crocker" , "Murray Kucherawy" 
> 
> Cc: dmarc@ietf.org
> Sent: Wednesday, April 16, 2014 9:53:15 AM
> Subject: Re: [dmarc-ietf] DMARC's purpose
> 
> > 2.  The spec is clear about how it works and what the implications are.
> > The
> > issue with mailing lists is well-documented.
> 
>  aI'm not sure that any issue with mailing lists is documented in 
> draft-kucherawy-dmarc-base at all, well or otherwise.  A search for 
> "mailing list" (or even "mailing") shows hits in three places, all in 
> back matter, none of substance.
> 
> There's nothing that I can see anywhere that warns of possible 
> consequences (neither considerations for the domain publishing the 
> policy nor discussion of collateral damage to mailing lists) of using 
> "p=reject" -- not in the explanation of "p=reject", not in Section 6 
> ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting 
> Messages"), not in the Security Considerations.
> 
> Where is is well documented?
> 

In the upcoming BCP

Should we also document in this Murray's draft that MS-Exchange breaks DKIM on 
forwarding, inventory all the operational cases? I don't think so. The draft is 
to describe the protocol, the BCP is here to document on how to operationally 
deploy and use it.

The reviews if I recall suggested to limit the draft to the protocol bits 
strictly.

___
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] DMARC's purpose

[Murray S. Kucherawy]

I wouldn't take the lack of answers terribly personally.  There certainly
are a lot of threads to track right now.

As for your specific ideas:

On Mon, Apr 14, 2014 at 10:10 AM, Vlatko Salaj wrote:

> i already mentioned including SRS in check logic. unfortunately, no dmarc
> author rly added much to the topic, and i work alone only on my own
> projects,
> not on collaborative things as these.
>

I seem to remember there was in fact discussion of your SRS advocacy.


> also, my 2nd suggestion, independent from 1st, if we mark SRS as 1st,
> would be:
> a. dmarc alignment is a big issue. read: huge issue.
> b. since alignment is an issue, make it policy optional.
> c. by "make it policy optional" i mean: include an option in dmarc dns
> policy,
> so that domain owners could turn dmarc alignment check on/off.
>

One way of viewing DMARC is that it seeks to allow a domain owner to have
better control of how its domain is used, so I don't know what this would
accomplish.  If alignment is optional, what does DMARC do policy-wise that
DKIM and SPF don't already do?

this could be useful for:
> domains using high volume ML participation,
> domains that use 3rd party services for their email infrastructure,
> domains that use forwarders,
> bunch of other special cases u can find on internet today and in future.
>
> my 3rd suggestion, which would go nicely together with 2nd, is:
> 1. current dmarc spec uses OR logic while processing SPF and DKIM; why?
>

They have complementary failure modes.  Data shows that the vast majority
of mail passes at least one if not both.  OR is the best logic in that
scenario, is it not?

2. make this policy processing logic selectable.
> 3. by "make it selectable" i mean: include an option in dmarc dns policy,
> so that domain owners could turn dmarc processing logic either to OR or
> AND.
>

That might be useful, but isn't that more restrictive, and not less
restrictive?  How would it help your use case, for example?

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/16/2014 10:12 AM, Barry Leiba wrote:

2. There is no reference from dmarc-base to dmarc-bcp, not even an
informative one.  And this is an important enough consideration that I
think it should be a normative reference.



The issue is important, certainly, but there are two reasons I think 
having base point to the draft bcp is the wrong approach:


1. The underlying issue here is essentially architectural rather than 
operations.  DMARC is designed to work for some specialized end-to-end 
scenarios and known to fail for some others,  When a spec defines 
something with those sorts of characteristics, I consider the 
explanation of its implications to be better placed in the 
specification.  At the least, it facilitates understand the underlying 
architectural choices that were made.


2. BCPs usually come after the spec.  A spec should not rely on a 
supporting BCP.  It gets the document usage directionality all screwed up.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Franck Martin]

- Original Message -
> From: "Barry Leiba" 
> To: "Franck Martin" 
> Cc: "Dave Crocker" , dmarc@ietf.org, "Murray Kucherawy" 
> 
> Sent: Wednesday, April 16, 2014 10:12:55 AM
> Subject: Re: [dmarc-ietf] DMARC's purpose
> 
> >> I'm not sure that any issue with mailing lists is documented in
> >> draft-kucherawy-dmarc-base at all, well or otherwise.  A search for
> >> "mailing list" (or even "mailing") shows hits in three places, all in
> >> back matter, none of substance.
> >>
> >> There's nothing that I can see anywhere that warns of possible
> >> consequences (neither considerations for the domain publishing the
> >> policy nor discussion of collateral damage to mailing lists) of using
> >> "p=reject" -- not in the explanation of "p=reject", not in Section 6
> >> ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting
> >> Messages"), not in the Security Considerations.
> >>
> >> Where is [it] well documented?
> >
> > In the upcoming BCP
> 
> 1. I don't see it adequately covered there, on a quick scan.  I
> haven't read it thoroughly, though.

Work in progress, feel free to submit some text to Dave.

> 
> 2. There is no reference from dmarc-base to dmarc-bcp, not even an
> informative one.  And this is an important enough consideration that I
> think it should be a normative reference.
> 
> > Should we also document in this Murray's draft that MS-Exchange
> > breaks DKIM on forwarding, inventory all the operational cases? I
> > don't think so. The draft is to describe the protocol, the BCP is here
> > to document on how to operationally deploy and use it.
> 
> I can't parse the first sentence, nor figure out what you're trying to
> refer to.  But to answer the question that's behind what I think
> you're asking: Yes, we should document, either in the specification or
> in an Applicability Statement that the specification cites as a
> normative reference, considerations that are critical to getting the
> configuration right.

It is well know that MS-Exchange breaks DKIM on forwarding by design, therefore 
breaks DMARC. It is not a trivial problem. Also Blackberries, break DMARC too. 
Should we cite all these cases in the draft? Make a laundry list?

We always said do monitor mode and then decide if it makes sense to move to 
p=reject.

Besides section 2.4 says it is out of scope:

Handling of undesirable or malicious mail that is coming from the
  domain from which it claims to be sent.

> 
> It's fine to separate the protocol bits and the "other information"
> into different documents, but it *all* has to be there in order to
> fight against misconfiguration and the damage that can cause.
> 

As far as I can see (I just did another search on the RFCs) there is no 
misconfiguration as there is no normative RFC to define what a mailing list is, 
how it operates, how it handles bounces, subscriptions, etc. I think this 
is what Ned was referring to in his post.

Section 15.4 gives some advice to all sending systems:

In the latter case, when doing an SMTP rejection, providing a clear
   hint can be useful in resolving issues.  A receiver might indicate in
   plain text the reason for the rejection by using the word "DMARC"
   somewhere in the reply text.  Many systems are able to scan the SMTP
   reply text to determine the nature of the rejection, thus providing a
   machine-detectable reason for rejection allows automated sorting of
   rejection causes so they can be properly addressed.

I don't see the issue with mailing lists (and other systems) be different from 
doing appropriate bounce processing.

So I propose the following to be added in 15.4:

Some forwarding systems (including some mailing lists) are notably known to 
have a simple bounce processing system, in such cases, the forwarding system 
may consider after a few bounces that the recipient address is not valid 
anymore and unsubscribe such recipient.

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

Re: [dmarc-ietf] DMARC's purpose

[Barry Leiba]

>> I'm not sure that any issue with mailing lists is documented in
>> draft-kucherawy-dmarc-base at all, well or otherwise.  A search for
>> "mailing list" (or even "mailing") shows hits in three places, all in
>> back matter, none of substance.
>>
>> There's nothing that I can see anywhere that warns of possible
>> consequences (neither considerations for the domain publishing the
>> policy nor discussion of collateral damage to mailing lists) of using
>> "p=reject" -- not in the explanation of "p=reject", not in Section 6
>> ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting
>> Messages"), not in the Security Considerations.
>>
>> Where is [it] well documented?
>
> In the upcoming BCP

1. I don't see it adequately covered there, on a quick scan.  I
haven't read it thoroughly, though.

2. There is no reference from dmarc-base to dmarc-bcp, not even an
informative one.  And this is an important enough consideration that I
think it should be a normative reference.

> Should we also document in this Murray's draft that MS-Exchange
> breaks DKIM on forwarding, inventory all the operational cases? I
> don't think so. The draft is to describe the protocol, the BCP is here
> to document on how to operationally deploy and use it.

I can't parse the first sentence, nor figure out what you're trying to
refer to.  But to answer the question that's behind what I think
you're asking: Yes, we should document, either in the specification or
in an Applicability Statement that the specification cites as a
normative reference, considerations that are critical to getting the
configuration right.

It's fine to separate the protocol bits and the "other information"
into different documents, but it *all* has to be there in order to
fight against misconfiguration and the damage that can cause.

Barry

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

It is not "an IETF document".  One of those would have a name that
starts with "draft-ietf-", followed by the name of the working group
it's part of.  And even then, it's just a "work in progress."  IETF
documents have RFC numbers.  IETF work in progress has "draft-ietf-".

draft-kucherawy-dmarc-base is an individually posted Internet draft.
Anyone can post one of those (go ahead: try it).  They aren't IETF
documents.  That distinction is important.



In the "fine print" - but most folks don't read the fine print - which
makes it really easy for folks to take liberties in marketing and
management presentations.



Of course, this has been explained multiple times in multiple venues.

There is no way to prevent the actions of people who have no concern for 
speaking carefully and accurately, or who choose to dismiss details they 
find inconvenient.


Such folk fundamentally are engaging in the political effort of 
persuasion, rather than the intellectual effort of understanding.


For group interaction, the differences between the two are fundamentally 
different in terms of style, goals and outcome.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

Barry Leiba wrote:

Just clearing up one point here:


Well, let's see:

...

- DMARC.org defines the "DMARC Base Specification" with a link to
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF
document

It is not "an IETF document".  One of those would have a name that
starts with "draft-ietf-", followed by the name of the working group
it's part of.  And even then, it's just a "work in progress."  IETF
documents have RFC numbers.  IETF work in progress has "draft-ietf-".

draft-kucherawy-dmarc-base is an individually posted Internet draft.
Anyone can post one of those (go ahead: try it).  They aren't IETF
documents.  That distinction is important.


In the "fine print" - but most folks don't read the fine print - which 
makes it really easy for folks to take liberties in marketing and 
management presentations.


It's URL includes "ietf.org," it lives on an IETF server, it's header 
includes "Network Working Group."  If it looks like an IETF document, 
and quacks like an IETF document - that's enough for an awful lot of 
people to claim that it IS an IETF document, and for an awful lot of 
folks to believe it.  From the point of view of most of the world - at 
the level that sees IETF as "the Internet's standards body" - that 
distinction is so invisible as to be meaningless.


From a legal point of view, it could be meaningless as well - in the 
same way that clauses buried in shrink wrapped licenses might or might 
not stand up in court. Example:  "no liability for anything" clauses 
don't cancel out an implied warrant of merchantability. Even as a 
non-lawyer, I know that one.  And again, Kleenex and Xerox and Coke 
spend a lot of money defending their trademarks - apparently, they 
believe that putting Kleenex(tm) on their boxes is not sufficient to 
prevent others from referring to their products as "kleenex."


Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[Franck Martin]

- Original Message -
> From: "Barry Leiba" 
> To: "Dave Crocker" , "Murray Kucherawy" 
> 
> Cc: dmarc@ietf.org
> Sent: Wednesday, April 16, 2014 9:53:15 AM
> Subject: Re: [dmarc-ietf] DMARC's purpose
> 
> > 2.  The spec is clear about how it works and what the implications are.
> > The
> > issue with mailing lists is well-documented.
> 
>  aI'm not sure that any issue with mailing lists is documented in
> draft-kucherawy-dmarc-base at all, well or otherwise.  A search for
> "mailing list" (or even "mailing") shows hits in three places, all in
> back matter, none of substance.
> 
> There's nothing that I can see anywhere that warns of possible
> consequences (neither considerations for the domain publishing the
> policy nor discussion of collateral damage to mailing lists) of using
> "p=reject" -- not in the explanation of "p=reject", not in Section 6
> ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting
> Messages"), not in the Security Considerations.
> 
> Where is is well documented?
> 

In the upcoming BCP

Should we also document in this Murray's draft that MS-Exchange breaks DKIM on 
forwarding, inventory all the operational cases? I don't think so. The draft is 
to describe the protocol, the BCP is here to document on how to operationally 
deploy and use it.

The reviews if I recall suggested to limit the draft to the protocol bits 
strictly.

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

Re: [dmarc-ietf] DMARC's purpose

[Barry Leiba]

> 2.  The spec is clear about how it works and what the implications are.  The
> issue with mailing lists is well-documented.

 aI'm not sure that any issue with mailing lists is documented in
draft-kucherawy-dmarc-base at all, well or otherwise.  A search for
"mailing list" (or even "mailing") shows hits in three places, all in
back matter, none of substance.

There's nothing that I can see anywhere that warns of possible
consequences (neither considerations for the domain publishing the
policy nor discussion of collateral damage to mailing lists) of using
"p=reject" -- not in the explanation of "p=reject", not in Section 6
("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting
Messages"), not in the Security Considerations.

Where is is well documented?

Barry

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

Re: [dmarc-ietf] DMARC's purpose

[Jim Fenton]

On 4/16/14 9:39 AM, Barry Leiba wrote:
> Just clearing up one point here:
>
>> Well, let's see:
> ...
>> - DMARC.org defines the "DMARC Base Specification" with a link to
>> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF
>> document
> It is not "an IETF document".  One of those would have a name that
> starts with "draft-ietf-", followed by the name of the working group
> it's part of.  And even then, it's just a "work in progress."  IETF
> documents have RFC numbers.  IETF work in progress has "draft-ietf-".
>
> draft-kucherawy-dmarc-base is an individually posted Internet draft.
> Anyone can post one of those (go ahead: try it).  They aren't IETF
> documents.  That distinction is important.

Yes, but the boilerplate doesn't help.  From the second paragraph of
"Status of this Memo":

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts.

So it's an IETF document in addition to possibly being someone else's.

-Jim


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

Re: [dmarc-ietf] DMARC's purpose

[Barry Leiba]

Just clearing up one point here:

> Well, let's see:
...
> - DMARC.org defines the "DMARC Base Specification" with a link to
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF
> document

It is not "an IETF document".  One of those would have a name that
starts with "draft-ietf-", followed by the name of the working group
it's part of.  And even then, it's just a "work in progress."  IETF
documents have RFC numbers.  IETF work in progress has "draft-ietf-".

draft-kucherawy-dmarc-base is an individually posted Internet draft.
Anyone can post one of those (go ahead: try it).  They aren't IETF
documents.  That distinction is important.

Barry

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

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

Kurt Roeckx wrote:

On Mon, Apr 14, 2014 at 12:42:25AM -0700, Murray S. Kucherawy wrote:

On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx  wrote:


2.  The spec is clear about how it works and what the implications are.

  The

issue with mailing lists is well-documented.

I don't agree with this.


If you have any specific suggestions for how it can be improved, now would
be a good time to make them.

I thought I made my comments about this in the past, but I can't
actually find them.  Some of them are:
- It does not describe how it (ab)uses existing technology and
   breaks existing things.  It's not clear what the effects of the
   alignment is.
- It does not say anything about how participating mailinglists
   should behave
- It's not clear in how reports should look like for messages that
   don't pass.  It would help that there were examples in it.

What would also help is:
- Implementations that actually follow the spec.  So far I have
   received 0 report mails that follow the specification.

And a definitive statement as to whether or not Yahoo's implementation 
recognizes Original-Authentication-Results - which would represent a 
low-impact way to interoperate with DMARC.


Kind of trying to decide whether to invest time and energy in patching 
our Sympa installation to generate OAR headers - but so far, the only 
folks who claim to support it are Google - and I've received multiple 
anecdotal statements that "nobody has implemented it."
The dmarc.org faq recommends: "Add an Original Authentication Results 
 (OAR) 
header to indicate that the list operator has performed authentication 
checks on the submitted message and share the results. " but a few days 
ago this was added: "*This is not a short term solution.* Assumes a 
mechanism to establish trust between the list operator and the receiver. 
No such mechanism is known to be in use for this purpose at this time. 
Without such a mechanism, bad actors could simply add faked OAR headers 
to their messages to circumvent such measures. OAR was only described as 
a draft document, which expired in 2012. No receivers implementing DMARC 
are currently known to make use of OAR from external sources. "






--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[Terry Zink]

Murray's response is the key point. Large email providers like DMARC because it 
helps cut down on phishing (which results in fewer compromised accounts), user 
complaints (which reduces support calls) and is fairly straightforward to 
implement (which makes the codebase more maintainable). They realize, however, 
that there are some scenarios that DMARC breaks. However, unless that pain is 
greater than the magnitude of pain that it solves, they are unlikely to reverse 
their DMARC implementations.

However, I'm sure they'd be amenable to updating it to fix the scenarios that 
is does break. So, what are the options? There are hundreds of years of email 
experience on this list, I'm sure we can come up with something.
-- Terry

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 14, 2014 12:42 AM
To: Kurt Roeckx
Cc: Dave Crocker; dmarc@ietf.org; Miles Fidelman
Subject: Re: [dmarc-ietf] DMARC's purpose

On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx 
mailto:k...@roeckx.be>> wrote:
> 2.  The spec is clear about how it works and what the implications are.  The
> issue with mailing lists is well-documented.
I don't agree with this.

If you have any specific suggestions for how it can be improved, now would be a 
good time to make them.

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

Re: [dmarc-ietf] DMARC's purpose

[Matt Simerson]

On Apr 14, 2014, at 10:43 AM, Kurt Roeckx  wrote:

> What would also help is:
> - Implementations that actually follow the spec.  So far I have
>  received 0 report mails that follow the specification.

http://search.cpan.org/dist/Mail-DMARC/

and the report format definition:

http://search.cpan.org/dist/Mail-DMARC/lib/Mail/DMARC/Report/Aggregate.pm

If you received a report from me (or another site that uses Mail::DMARC), you'd 
get a report that follows the 2013 draft. To the letter. I haven't read the 
latest draft in enough detail to assure that is still the case.

While writing Mail::DMARC, I noticed a number of anomalies in the reports I was 
receiving. Upon reporting on those issues to the dmarc-users mailing list, all 
of them (except a hotmail issue) got a "oops, we'll fix that," response.  I 
haven't gone back to see if I can remove the "tolerate this malformation in a 
report" shims, but my assumption is that I can remove most of them.

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

Re: [dmarc-ietf] DMARC's purpose

[Kurt Roeckx]

On Mon, Apr 14, 2014 at 12:42:25AM -0700, Murray S. Kucherawy wrote:
> On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx  wrote:
> 
> > > 2.  The spec is clear about how it works and what the implications are.
> >  The
> > > issue with mailing lists is well-documented.
> >
> > I don't agree with this.
> >
> 
> If you have any specific suggestions for how it can be improved, now would
> be a good time to make them.

I thought I made my comments about this in the past, but I can't
actually find them.  Some of them are:
- It does not describe how it (ab)uses existing technology and
  breaks existing things.  It's not clear what the effects of the
  alignment is.
- It does not say anything about how participating mailinglists
  should behave
- It's not clear in how reports should look like for messages that
  don't pass.  It would help that there were examples in it.

What would also help is:
- Implementations that actually follow the spec.  So far I have
  received 0 report mails that follow the specification.


Kurt

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

Re: [dmarc-ietf] DMARC's purpose

[Vlatko Salaj]

On Monday, April 14, 2014 9:59 AM, Murray S. Kucherawy wrote:

>> come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well but
>> in very narrow field.
> Do you have any specific suggestions 

as a matter of fact, yes, i do.

i already mentioned including SRS in check logic. unfortunately, no dmarc
author rly added much to the topic, and i work alone only on my own projects,
not on collaborative things as these.

also, my 2nd suggestion, independent from 1st, if we mark SRS as 1st, would be:
a. dmarc alignment is a big issue. read: huge issue.
b. since alignment is an issue, make it policy optional.
c. by "make it policy optional" i mean: include an option in dmarc dns policy,
so that domain owners could turn dmarc alignment check on/off.

this could be useful for:
domains using high volume ML participation,
domains that use 3rd party services for their email infrastructure,
domains that use forwarders,
bunch of other special cases u can find on internet today and in future.

my 3rd suggestion, which would go nicely together with 2nd, is:
1. current dmarc spec uses OR logic while processing SPF and DKIM; why?

2. make this policy processing logic selectable.
3. by "make it selectable" i mean: include an option in dmarc dns policy,
so that domain owners could turn dmarc processing logic either to OR or AND.


my 2nd and 3rd suggestion, in combo, would deal much better with stuff
that, originally, dmarc spec had OR processing logic meant for, and while
doing that, it would also add so much needed wideness to dmarc rigidity.


and i could even pass dmarc finally. imagine that. while still getting some
benefit from dmarc processing.


is there a weakness in this proposal. probably. is it huge. i don't think so.
u disagree? elaborate, plz.



-- 
Vlatko Salaj aka goodone
http://goodone.tk

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

Re: [dmarc-ietf] DMARC's purpose

[Murray S. Kucherawy]

On Sat, Apr 12, 2014 at 2:54 PM, Vlatko Salaj wrote:

> come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well
> but
> in very narrow field.
>

Do you have any specific suggestions?

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

Re: [dmarc-ietf] DMARC's purpose

[Murray S. Kucherawy]

On Sat, Apr 12, 2014 at 9:23 AM, Miles Fidelman
wrote:

>
> Well, let's see:
> - DMARC.org defines the "DMARC Base Specification" with a link to
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF
> document
> - they published an information Internet draft, that expires in October of
> this year, that starts with "This memo presents a proposal for a scalable
> mechanism by which a mail sending organization can express,."
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
> - by implication, they are representing DMARC as a standards-track IETF
> specification
>
>
That's your inference, not their implication.  None of "base
specification", "informational Internet draft" or "proposal for a scalable
mechanism" automatically mean "standard".  In fact, the document is not on
a path for the standards track.

Publication of a "proposal" as an information Internet draft, is barely the
> first step toward an operational specification standardized by the IETF -
> yet DEMARC proponents are representing it as an IETF standard (or at least
> as going through the process).
>

See above; this is incorrect.


> So, it seems to me that it is entirely legitimate for IETF to officially
> be on the record that:
> 1. DMARC is NOT even close to an IETF standard
>

...nor is it currently seeking that status.


> 2. It has not been subject to any of the technical and operational vetting
> associated with the progression of a specification through the IETF
> standardization process
>

Correct, at least formally in IETF terms, which is why it is on track to be
Informational.  Informally, there has been open community dialog about it
for quite some time now, not limited to this mailing list.


> 3. The means by which Yahoo has deployed DMARC, and the choice of several
> other large ISPs to honor the p=reject policy, is not in keeping with the
> practice of measured testing and incremental deployment of IETF standards,
> as they progress from proposal, to experimental, to optional, to
> recommended, to mandatory
>

DMARC includes mechanisms to be incremental and do live testing and
reporting as key components, and has since its inception since gradual
rollout capabilities were established as a requirement early on.

That one operator may have chosen to do something in a way people found
disruptive is not, to me, a valid cause through which the specification
should be invalidated.  DNSBLs can be just as or even more disruptive (and
have been), yet they are also described in Informational RFCs.  There are
likely many other examples.

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

Re: [dmarc-ietf] DMARC's purpose

[Murray S. Kucherawy]

On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx  wrote:

> > 2.  The spec is clear about how it works and what the implications are.
>  The
> > issue with mailing lists is well-documented.
>
> I don't agree with this.
>

If you have any specific suggestions for how it can be improved, now would
be a good time to make them.

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

Re: [dmarc-ietf] DMARC's purpose

[Vlatko Salaj]

On Sunday, April 13, 2014 1:31 AM, Franck Martin wrote:


>> my email actually fails 98%. but who cares about me, i'm no facebook sending
>> to yahoo, right? or yahoo sending to google... or some other big sending to
>> some other big... or whatever.
> Don't publish a DMARC policy which is detrimental to you...

it's "p=none". how is that detrimental to me? i don't plan changing it to
"reject" anytime soon.

dmarc still fails. and who will warrant me that some big esp doesn't get all
self-righteous and simply ignores my dmarc policy, instead choosing to process
my email according to its dmarc fail status? who says yahoo won't just decide
my email is a spam, that my domain is publishing "none" as any good phisher
would, and then simply process my email using dmarc filters, regardless of my
dmarc policy?

obviously a spec that isn't even a standard can't rly warrant me such a thing,
similarly to how yahoo doesn't care about obvious shortcoming in the current
spec, or even less, its recommendations.

let's all force our beliefs on world like yahoo did, and hope tranquility
will
be the result. pretty childish thinking.


> Also please correct your DMARC record, it is invalid:
> https://dmarcian.com/dmarc-inspector/goodone.tk

my dmarc record is perfectly valid, as per current spec. what's broken is
dmarcian.com check algorithm, which i reported to them two months ago, and
they acknowledged it.
why they didn't fix it yet, isn't my problem, but my
record is following current

spec.


i expected more from ppl on this list... u don't even know the spec, yet u
argue about it. great work all. just wonderful.


the only benefit from all dmarc crap for me is "fo=d:s" reporting policy.
at
least i get reports when spf and/or dkim fail.

dmarc alignment will always fail for me. yet my infrastructure isn't at all
rare, unique or uncommon, but actually pretty used practice.

so, at least i can
disable dmarc processing with "p=none" and that's my
recommendation to
all who believe in wide legitimacy of email natures.

you never know if recipients use forwarding without SRS, or whether their
infrastructure breaks DKIM, or even what type of SPF check they r doing,
cause even current SPF spec is defining evaluation uncertainties.

with "p=reject" policy your important email to some geeky admin on another
side of the planet may simply get lost, just because u have no control on how
ur email gets delivered or validated on their side. one forward here, one
anti-spam added header there, and walla, u r phishing from ur own email
account. congratulations.

no phisher would do it better.


-- 
Vlatko Salaj aka goodone
http://goodone.tk

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

Re: [dmarc-ietf] DMARC's purpose

[Scott Kitterman]

On April 12, 2014 7:31:53 PM EDT, Franck Martin  wrote:
>
>- Original Message -
>> From: "Vlatko Salaj" 
>> To: dmarc@ietf.org
>> Sent: Saturday, April 12, 2014 2:54:17 PM
>> Subject: Re: [dmarc-ietf] DMARC's purpose
>> 
>> On Saturday, April 12, 2014 11:19 PM, Scott Kitterman wrote:
>> 
>> > When I look at the feedback I get on my DMARC reports about 90% of
>the mail
>> > I send fails DMARC despite good SPF and DKIM deployments due to
>mailing
>> > lists,
>> > bug trackers, web site sharing, etc. For me and many others this is
>not
>> > about
>> > a trivial piece of the mail stream.
>> 
>> +1
>> my email actually fails 98%. but who cares about me, i'm no facebook
>sending
>> to yahoo, right? or yahoo sending to google... or some other big
>sending to
>> some other big... or whatever.
>> 
>
>Don't publish a DMARC policy which is detrimental to you...

What DMARC record would I need to make the Google Group I administer work 
correctly with Yahoo subscribers?  I am anxious to avoid detrimental DMARC 
policies. 

Scott K

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

Re: [dmarc-ietf] DMARC's purpose

[Franck Martin]

- Original Message -
> From: "Vlatko Salaj" 
> To: dmarc@ietf.org
> Sent: Saturday, April 12, 2014 2:54:17 PM
> Subject: Re: [dmarc-ietf] DMARC's purpose
> 
> On Saturday, April 12, 2014 11:19 PM, Scott Kitterman wrote:
> 
> > When I look at the feedback I get on my DMARC reports about 90% of the mail
> > I send fails DMARC despite good SPF and DKIM deployments due to mailing
> > lists,
> > bug trackers, web site sharing, etc. For me and many others this is not
> > about
> > a trivial piece of the mail stream.
> 
> +1
> my email actually fails 98%. but who cares about me, i'm no facebook sending
> to yahoo, right? or yahoo sending to google... or some other big sending to
> some other big... or whatever.
> 

Don't publish a DMARC policy which is detrimental to you...

Also please correct your DMARC record, it is invalid: 
https://dmarcian.com/dmarc-inspector/goodone.tk

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

Re: [dmarc-ietf] DMARC's purpose

[Vlatko Salaj]

On Saturday, April 12, 2014 11:19 PM, Scott Kitterman wrote:

> When I look at the feedback I get on my DMARC reports about 90% of the mail
> I send fails DMARC despite good SPF and DKIM deployments due to mailing lists,
> bug trackers, web site sharing, etc. For me and many others this is not about
> a trivial piece of the mail stream.

+1
my email actually fails 98%. but who cares about me, i'm no facebook sending
to yahoo, right? or yahoo sending to google... or some other big sending to
some other big... or whatever.

wrong.


come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well but
in very narrow field.

this is what happens when a good idea gets half done, almost like a true
recipe for developing a quitter personal trait. or eating half baked bread.



-- 
Vlatko Salaj aka goodone
http://goodone.tk

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

Re: [dmarc-ietf] DMARC's purpose

[SM]

Hi Miles,
At 09:23 12-04-2014, Miles Fidelman wrote:

Well, let's see:
- DMARC is an ad-hoc group that assembled with a "common goal was to 
develop an operational specification to be introduced to the IETF 
for standardization"

(http://dmarc.org/about.html)
- DMARC.org defines the "DMARC Base Specification" with a link to 
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF document
- they published an information Internet draft, that expires in 
October of this year, that starts with "This memo presents a 
proposal for a scalable mechanism by which a mail sending 
organization can express,." 
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
- by implication, they are representing DMARC as a standards-track 
IETF specification


According to an article in the IETF Journal:

"The amazing show of support changed the anticipated trajectory of 
the standardization plan. Rather than request the formation of an 
IETF working group (WG) to rework the specification, the authors 
discussed possible options with the IETF Applications Area WG and its 
Area Directors. Through conversation it became clear that there were 
some paths worth considering that would more closely follow the 
accelerated adoption curve associated with the draft DMARC specification.


The end result was to ask an Applications Area Director to sponsor 
the specification as a candidate for the Standards Track, at the same 
time convening a Birds of a Feather (BoF) at IETF 87 in Berlin to 
discuss DMARC extensions and supporting materials. At the BoF, a 
charter for a proposed DMARC WG was presented, which drove a 
discussion about potential work items for the WG. Barry Leiba, one of 
the Application Area Directors, agreed to sponsor the specification 
with the caveat that messages sent to the IETF DMARC discussion list 
clearly said that community experts validated that the specification 
was ready to move to the Standards Track.


Within a month of the BoF in Berlin, a handful of supportive comments 
by industry experts were sent to the discussion list. A few items 
were called out for further work on the DMARC specification, but many 
could be disposed of during the final-call phase of the Standards 
Track. While the DMARC specification could be tuned up, it's clearly 
functional for its intended purpose and the community supports the 
process for standardizing it."


A message was posted to this mailing list this year.  It was stated that:

 "We have chosen to submit the DMARC specification via the Independent
  Submission Editor (ISE). This will have three primary effects: (1) it
  will be published with a permanent reference location; (2) it will be
  classified as Informational rather than as a Proposed Standard; (3) the
  ISE process is a much more direct path to publication."

Publication of a "proposal" as an information Internet draft, is 
barely the first step toward an operational specification 
standardized by the IETF - yet DEMARC proponents are representing it 
as an IETF standard (or at least as going through the process).


I think that the web page mentioned above is out-of-date.  As for the 
memo (I reviewed an old version last year) it represents the views of 
the authors.


Beyond that, let me note that the draft includes this line: "The 
enclosed proposal is not intended to introduce mechanisms that 
provide elevated delivery privilege of authenticated email." -- 
which, of course is exactly what has been done by Yahoo by 
publishing "p=reject" in its DMARC policy, and by those who've 
chosen to honor it.


Noted.

So, it seems to me that it is entirely legitimate for IETF to 
officially be on the record that:

1. DMARC is NOT even close to an IETF standard
2. It has not been subject to any of the technical and operational 
vetting associated with the progression of a specification through 
the IETF standardization process
3. The means by which Yahoo has deployed DMARC, and the choice of 
several other large ISPs to honor the p=reject policy, is not in 
keeping with the practice of measured testing and incremental 
deployment of IETF standards, as they progress from proposal, to 
experimental, to optional, to recommended, to mandatory


For reasons of technical and professional integrity, IETF should be 
distancing itself from this debacle, very loudly and very clearly. 
If nothing else, IETF should be defending its legitimacy as the 
Internet's standards body - in the same way that Xerox and Kleenex 
defend their trademarks.


Beyond that - perhaps a strong position by IETF might have an impact 
on Yahoo's decision making.


The IETF would have to publish a RFC to be officially on record.  A 
person would have to write a draft and get it through the process for 
such a RFC to be published.  The above points looks like issues for 
the i...@ietf.org mailing list as they are about IETF standardization 
and trademarks.


Regards,
-sm

___
dmarc m

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

Dave Crocker wrote:

On 4/12/2014 9:26 AM, Miles Fidelman wrote:


All I can speak for is observing some rather load and vociferous
commentary, and agitation, from my BBN colleagues, many of whom were
active in IETF, during the period where GSA and DoD were trying to foist
OSI down everyone's throats.  The technical and policy papers were
flying fast and furious - though I can't say that any were official IETF
documents or positions.



Many /people/ who participated in the IETF, as were their /employers/.

The /IETF/ itself wasn't.

I believe what I said was "Well - arguably, the IETF (or members 
thereof) were pretty vocal when

the TCP/IP vs. ISO wars were going on. "

MF

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/12/2014 9:26 AM, Miles Fidelman wrote:


All I can speak for is observing some rather load and vociferous
commentary, and agitation, from my BBN colleagues, many of whom were
active in IETF, during the period where GSA and DoD were trying to foist
OSI down everyone's throats.  The technical and policy papers were
flying fast and furious - though I can't say that any were official IETF
documents or positions.



Many /people/ who participated in the IETF, as were their /employers/.

The /IETF/ itself wasn't.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/12/2014 9:23 AM, Miles Fidelman wrote:


1. DMARC is NOT even close to an IETF standard
2. It has not been subject to any of the technical and operational
vetting associated with the progression of a specification through the
IETF standardization process
3. The means by which Yahoo has deployed DMARC, and the choice of
several other large ISPs to honor the p=reject policy, is not in keeping
with the practice of measured testing and incremental deployment of IETF
standards, as they progress from proposal, to experimental, to optional,
to recommended, to mandatory



The IETF doesn't do that sort of thing.  If it did, it would be spending 
all of its time making similar statements about a great many other 
technologies and implementations.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

Dave Crocker wrote:

On 4/12/2014 8:52 AM, Miles Fidelman wrote:

Dave Crocker wrote:

That's governed by operations organizations, not the IETF.


Well, yes and no.


Your lengthy treatise does not appear to contain a specific proposal. 
So while the tutorial information is all well and good, how is it 
relevant to the current situation?




I believe the IETF has never done such a thing.  I'm pretty sure it
shouldn't.


Well - arguably, the IETF (or members thereof) were pretty vocal when
the TCP/IP vs. ISO wars were going on.


It was?  What specifics are you referring to?  I don't recall the IETF 
doing anything but facilitating work on both technologies, both with 
ISODE and for network management, and later when considering choices 
in IPv6.




All I can speak for is observing some rather load and vociferous 
commentary, and agitation, from my BBN colleagues, many of whom were 
active in IETF, during the period where GSA and DoD were trying to foist 
OSI down everyone's throats.  The technical and policy papers were 
flying fast and furious - though I can't say that any were official IETF 
documents or positions.


Miles



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

SM wrote:

Hi Miles,
At 05:29 12-04-2014, Miles Fidelman wrote:
It does strike me that DMARC, which is currently an internet-draft, 
not even an RFC, is causing incredible disruption by its adoption, by 
a few very large players.  Methinks this indicates a serious problem, 
and raises some questions about what measures might be taken when a 
big player breaks the Internet by not playing nice.  It sure seems 
that IETF should play a role in this.


I do not see what IETF participants could do as the internet-draft is 
not being reviewed by the IETF.  The big player is breaking email sent 
to mailing lists.  It is not breaking the internet.  I would not 
expect any company to play nice as it is a business after all.




Well, let's see:
- DMARC is an ad-hoc group that assembled with a "common goal was to 
develop an operational specification to be introduced to the IETF for 
standardization"

(http://dmarc.org/about.html)
- DMARC.org defines the "DMARC Base Specification" with a link to 
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF 
document
- they published an information Internet draft, that expires in October 
of this year, that starts with "This memo presents a proposal for a 
scalable mechanism by which a mail sending organization can 
express,." https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
- by implication, they are representing DMARC as a standards-track IETF 
specification


Publication of a "proposal" as an information Internet draft, is barely 
the first step toward an operational specification standardized by the 
IETF - yet DEMARC proponents are representing it as an IETF standard (or 
at least as going through the process).


Beyond that, let me note that the draft includes this line: "The 
enclosed proposal is not intended to introduce mechanisms that provide 
elevated delivery privilege of authenticated email." -- which, of course 
is exactly what has been done by Yahoo by publishing "p=reject" in its 
DMARC policy, and by those who've chosen to honor it.


So, it seems to me that it is entirely legitimate for IETF to officially 
be on the record that:

1. DMARC is NOT even close to an IETF standard
2. It has not been subject to any of the technical and operational 
vetting associated with the progression of a specification through the 
IETF standardization process
3. The means by which Yahoo has deployed DMARC, and the choice of 
several other large ISPs to honor the p=reject policy, is not in keeping 
with the practice of measured testing and incremental deployment of IETF 
standards, as they progress from proposal, to experimental, to optional, 
to recommended, to mandatory


For reasons of technical and professional integrity, IETF should be 
distancing itself from this debacle, very loudly and very clearly. If 
nothing else, IETF should be defending its legitimacy as the Internet's 
standards body - in the same way that Xerox and Kleenex defend their 
trademarks.


Beyond that - perhaps a strong position by IETF might have an impact on 
Yahoo's decision making.


Miles Fidelman








--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/12/2014 8:52 AM, Miles Fidelman wrote:

Dave Crocker wrote:

That's governed by operations organizations, not the IETF.


Well, yes and no.


Your lengthy treatise does not appear to contain a specific proposal. 
So while the tutorial information is all well and good, how is it 
relevant to the current situation?




I believe the IETF has never done such a thing.  I'm pretty sure it
shouldn't.


Well - arguably, the IETF (or members thereof) were pretty vocal when
the TCP/IP vs. ISO wars were going on.


It was?  What specifics are you referring to?  I don't recall the IETF 
doing anything but facilitating work on both technologies, both with 
ISODE and for network management, and later when considering choices in 
IPv6.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

Dave Crocker wrote:

On 4/12/2014 8:17 AM, Miles Fidelman wrote:

Dave Crocker wrote:

On 4/12/2014 5:29 AM, Miles Fidelman wrote:
1.  DMARC was developed by an ad hoc industry consortium.  It is
already deployed well enough to cover an estminated 60% of the world's
email traffic.  As such, it's status with the IETF is obviously not a
gating factor.  So the "not even an RFC" has some formal import, but
limited practical import.


So what happens to an infrastructure that is operated and governed by
consensus, when a few large players can make major changes to the
infrastructure while ignoring issues that don't directly effect their
interests?


That's an excellent question.  Worthy of discussion.

Perhaps oddly, however, it is almost irrelevant to the work of the 
IETF, which is creation of technical specification.


Your question is about enforcement, not about creation.

That's an operations issue.



3. A specification cannot be responsible for operators that choose to
deploy something in a way that creates problems documented in the spec.


No.  But a standards process can.  (E.g., not just anybody can be domain
registry, or enter records into the root nameservers).


That's governed by operations organizations, not the IETF.


Well, yes and no.

It's fairly typical in the standards world for one organization to set 
standards, and designate a "registration" authority to administer 
aspects of a standard.


In the current discussion about the NTIA/ICANN transition, two examples 
of this have come up, and there are 100s more:
- ISO defines the numbering scheme for bank card and credit card 
numbers, ANSI maintains the "Issuer Identification Database"
- ISBN numbers are similarly standardized by one body, with delegated 
authority for issuing the numbers


(ANSI by the way, is a voluntary, non-profit, originally formed by a 
bunch of engineering societies.  ISO is a consortium of ANSI and other 
national level standards bodies.)


Standards bodies also commonly define certification requirements and 
mechanisms, accredit certification bodies in various ways, and establish 
remedies for false representation of certification status.


In the case of Internet protocols, IETF is the primary standards body, 
and through various MOUs has designated registration authorities for 
various things (mostly IANA).


So yes, IETF has some governance authority (technical, moral, and legal) 
in this matter, if it chooses to exercise it.

At the very least, it strikes me that the IETF should be visibly and
publicly chastising the "ad hoc industry consortium that developed
DMARC" and those who deployed it - as being exceptionally bad actors 
who:

- roundly ignored issues of major impact in developing the standard
- have deployed it in ways that are causing widespread havoc
- are rather pointedly ignoring that havoc (have you seen anybody from
Yahoo responding?)


I believe the IETF has never done such a thing.  I'm pretty sure it 
shouldn't.


Well - arguably, the IETF (or members thereof) were pretty vocal when 
the TCP/IP vs. ISO wars were going on.




The more a technical organization delves into public policy and 
politics, the less it is a technical organization.  Policy and 
politics issues come to dominate.


At the least, they confuse perception of the organization.

Well, IEEE and ACM both have policy arms.  IEEE is both a standards 
maker and very visible on some policy issues - including some that are 
technopolitical.  (Granted that IEEEs standards efforts are relatively 
removed from their policy efforts).



So while there well might be worthy statements and/or actions to be 
taken, when a major actor introduces major disruption, that's not a 
task for the IETF.




Which then begs the question: Who's task is it?

Miles

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[SM]

Hi Miles,
At 05:29 12-04-2014, Miles Fidelman wrote:
It does strike me that DMARC, which is currently an internet-draft, 
not even an RFC, is causing incredible disruption by its adoption, 
by a few very large players.  Methinks this indicates a serious 
problem, and raises some questions about what measures might be 
taken when a big player breaks the Internet by not playing nice.  It 
sure seems that IETF should play a role in this.


I do not see what IETF participants could do as the internet-draft is 
not being reviewed by the IETF.  The big player is breaking email 
sent to mailing lists.  It is not breaking the internet.  I would not 
expect any company to play nice as it is a business after all.


Regards,
-sm 


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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/12/2014 8:17 AM, Miles Fidelman wrote:

Dave Crocker wrote:

On 4/12/2014 5:29 AM, Miles Fidelman wrote:
1.  DMARC was developed by an ad hoc industry consortium.  It is
already deployed well enough to cover an estminated 60% of the world's
email traffic.  As such, it's status with the IETF is obviously not a
gating factor.  So the "not even an RFC" has some formal import, but
limited practical import.


So what happens to an infrastructure that is operated and governed by
consensus, when a few large players can make major changes to the
infrastructure while ignoring issues that don't directly effect their
interests?


That's an excellent question.  Worthy of discussion.

Perhaps oddly, however, it is almost irrelevant to the work of the IETF, 
which is creation of technical specification.


Your question is about enforcement, not about creation.

That's an operations issue.



3. A specification cannot be responsible for operators that choose to
deploy something in a way that creates problems documented in the spec.


No.  But a standards process can.  (E.g., not just anybody can be domain
registry, or enter records into the root nameservers).


That's governed by operations organizations, not the IETF.



At the very least, it strikes me that the IETF should be visibly and
publicly chastising the "ad hoc industry consortium that developed
DMARC" and those who deployed it - as being exceptionally bad actors who:
- roundly ignored issues of major impact in developing the standard
- have deployed it in ways that are causing widespread havoc
- are rather pointedly ignoring that havoc (have you seen anybody from
Yahoo responding?)


I believe the IETF has never done such a thing.  I'm pretty sure it 
shouldn't.


The more a technical organization delves into public policy and 
politics, the less it is a technical organization.  Policy and politics 
issues come to dominate.


At the least, they confuse perception of the organization.

So while there well might be worthy statements and/or actions to be 
taken, when a major actor introduces major disruption, that's not a task 
for the IETF.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

Dave Crocker wrote:

On 4/12/2014 5:29 AM, Miles Fidelman wrote:



It does strike me that DMARC, which is currently an internet-draft, not
even an RFC, is causing incredible disruption by its adoption, by a few
very large players.  Methinks this indicates a serious problem, and
raises some questions about what measures might be taken when a big
player breaks the Internet by not playing nice.  It sure seems that IETF
should play a role in this.



1.  DMARC was developed by an ad hoc industry consortium.  It is 
already deployed well enough to cover an estminated 60% of the world's 
email traffic.  As such, it's status with the IETF is obviously not a 
gating factor.  So the "not even an RFC" has some formal import, but 
limited practical import.


So what happens to an infrastructure that is operated and governed by 
consensus, when a few large players can make major changes to the 
infrastructure while ignoring issues that don't directly effect their 
interests?


2. The spec is clear about how it works and what the implications are. 
 The issue with mailing lists is well-documented.



Well documented, perhaps.  But, see above.

3. A specification cannot be responsible for operators that choose to 
deploy something in a way that creates problems documented in the spec.


No.  But a standards process can.  (E.g., not just anybody can be domain 
registry, or enter records into the root nameservers).


4. You don't say what you feel the IETF should do, nor is it obvious 
to me what role the IETF can reasonably have for this sort of 
deployment issue.


As to the practicalities of what IETF can do - I kind of agree. Which 
may point to a limit of Internet governance by consensus. (Consider the 
comparable case of a radio transmitter going off frequency and causing 
interference -- that will get a very rapid institutional response, 
possibly by people who carry guns, if, for example, you jam a police band.)


As to what the IETF should do - well... at the very least the Internet 
operates on a set of standardized protocols, developed by consensus - 
and there is a formal process by which protocols develop from ideas, to 
experimental standards, to recommended, to mandatory (not many of 
those).  At the very least, there is social pressure to conform to such 
standards.  In some cases there are mechanisms that have more teeth 
(e.g., where registration of protocol numbers is required in a database 
under IANA "jurisdiction") - not just anybody can put records into the 
core nameservers, and those can always be removed (IETF sets the 
policies for a lot of the databases IANA maintains - I guess in theory 
IETF could establish a policy that says "if you don't follow these 
protocols properly, your DNS records get yanked").  I'm not sure I'm 
advocating such measures - but


At the very least, it strikes me that the IETF should be visibly and 
publicly chastising the "ad hoc industry consortium that developed 
DMARC" and those who deployed it - as being exceptionally bad actors who:

- roundly ignored issues of major impact in developing the standard
- have deployed it in ways that are causing widespread havoc
- are rather pointedly ignoring that havoc (have you seen anybody from 
Yahoo responding?)


Miles Fidelman






--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[Kurt Roeckx]

On Sat, Apr 12, 2014 at 07:53:46AM -0700, Dave Crocker wrote:
> 
> 2.  The spec is clear about how it works and what the implications are.  The
> issue with mailing lists is well-documented.

I don't agree with this.


Kurt

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/12/2014 5:29 AM, Miles Fidelman wrote:



It does strike me that DMARC, which is currently an internet-draft, not
even an RFC, is causing incredible disruption by its adoption, by a few
very large players.  Methinks this indicates a serious problem, and
raises some questions about what measures might be taken when a big
player breaks the Internet by not playing nice.  It sure seems that IETF
should play a role in this.



1.  DMARC was developed by an ad hoc industry consortium.  It is already 
deployed well enough to cover an estminated 60% of the world's email 
traffic.  As such, it's status with the IETF is obviously not a gating 
factor.  So the "not even an RFC" has some formal import, but limited 
practical import.


2.  The spec is clear about how it works and what the implications are. 
 The issue with mailing lists is well-documented.


3. A specification cannot be responsible for operators that choose to 
deploy something in a way that creates problems documented in the spec.


4.  You don't say what you feel the IETF should do, nor is it obvious to 
me what role the IETF can reasonably have for this sort of deployment 
issue.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Miles Fidelman]

SM wrote:

Hi Jim,
At 08:47 10-04-2014, Jim Fenton wrote:

More broadly:  I'm not an expert on IETF publication criteria, but I
hope that, especially given this confusion, controls are in place to
protect against the publication of informational RFCs that might be
harmful in some respect.


It has been mentioned on this mailing list that publication of the 
DMARC specification will be sought through a non-IETF stream. There is 
a conflict review in such cases.  BCP 92 describes the details.


It does strike me that DMARC, which is currently an internet-draft, not 
even an RFC, is causing incredible disruption by its adoption, by a few 
very large players.  Methinks this indicates a serious problem, and 
raises some questions about what measures might be taken when a big 
player breaks the Internet by not playing nice.  It sure seems that IETF 
should play a role in this.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [dmarc-ietf] DMARC's purpose

[SM]

Hi Jim,
At 08:47 10-04-2014, Jim Fenton wrote:

More broadly:  I'm not an expert on IETF publication criteria, but I
hope that, especially given this confusion, controls are in place to
protect against the publication of informational RFCs that might be
harmful in some respect.


It has been mentioned on this mailing list that publication of the 
DMARC specification will be sought through a non-IETF stream.  There 
is a conflict review in such cases.  BCP 92 describes the details.


Regards,
-sm 


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

Re: [dmarc-ietf] DMARC's purpose

[Matt Simerson]

On Apr 10, 2014, at 10:44 AM, Murray S. Kucherawy  wrote:

> On Thu, Apr 10, 2014 at 8:47 AM, Jim Fenton  wrote:
> More broadly:  I'm not an expert on IETF publication criteria, but I
> hope that, especially given this confusion, controls are in place to
> protect against the publication of informational RFCs that might be
> harmful in some respect.
> 
> I don't think it's a bad idea to publish things that have potentially 
> negative side effects as long as they're well documented.  If that's flatly 
> disallowed, then a lot of good but incomplete ideas will never see the light 
> of day.

+1

http://en.wikipedia.org/wiki/Tragedy_of_the_commons

Matt

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

Re: [dmarc-ietf] DMARC's purpose

[John Sweet]

I was intentionally vague, since several distinct changes have been
proposed along those lines. That's definitely one of them. The general
objection covers all of them.


On Thu, Apr 10, 2014 at 10:07 AM, Kurt Roeckx  wrote:

> On Thu, Apr 10, 2014 at 06:59:41AM -0700, John Sweet wrote:
> > I see the competing "answers" breaking down differently:
> >
> >  - Mailing list implementation/practice must change to support
> From-header
> > alignment
>
> So that would mean that all mails on a mailling listshould
> rewrite the From so that it's appears to come from someone in the
> domain of the maillinglist?
>
>
> Kurt
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/10/2014 12:44 PM, Murray S. Kucherawy wrote:

I don't think it's a bad idea to publish things that have potentially
negative side effects as long as they're well documented.  If that's
flatly disallowed, then a lot of good but incomplete ideas will never
see the light of day.



Those are what get standardized...

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Murray S. Kucherawy]

On Thu, Apr 10, 2014 at 8:47 AM, Jim Fenton  wrote:

> More broadly:  I'm not an expert on IETF publication criteria, but I
> hope that, especially given this confusion, controls are in place to
> protect against the publication of informational RFCs that might be
> harmful in some respect.
>

I don't think it's a bad idea to publish things that have potentially
negative side effects as long as they're well documented.  If that's flatly
disallowed, then a lot of good but incomplete ideas will never see the
light of day.

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/10/2014 10:47 AM, Jim Fenton wrote:

On 04/10/2014 06:16 AM, Pierre-Alain Dupont wrote:

After reading a few articles like
http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html,
I came to wonder as to why a soon-to-be standardized project came to
on purpose break a huge part of the reality of today's emails.


This highlights one of the issues with the IETF publication process:
many people assume that anything with an RFC number is an IETF standard.
It was my understanding from Murray's message of March 26 that DMARC was
being considered as an informational RFC, which of course is not a standard.


Over the months there has been a variety of paths considered for the 
DMARC base spec.  Someone thinking that it's intended for standards 
status isn't necessarily "misunderstanding"; they might merely not be 
current.




More broadly:  I'm not an expert on IETF publication criteria, but I
hope that, especially given this confusion, controls are in place to
protect against the publication of informational RFCs that might be
harmful in some respect.


1.  The confusion some people have about the meaning of RFC vs. IETF 
'standard' is irrelevant to the current discussion.  Yes, some people 
are confused.  But as often as it gets cited over the years, it has 
never been demonstrated to cause real problems of any significance.


2.  Publication of Informational RFCs submitted through the "Independent 
" stream -- which is independent of the IETF-managed stream -- is not 
based on the sorts of content control you postulate.  Nor should it be. 
 The kinds of control in place are roughly the same as they've been 
forever and, again, while some such documents cause some people 
discomfort, it, too, has not been demonstrated to cause serious problems.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/10/2014 9:55 AM, John Sweet wrote:

I thought that's what the Return-Path: was for.


Ignoring the SPF hack/enhancement to use rfc5321.EHLO rather than 
rfc5321.MailFrom, SPF aligns with MailFrom.


Return-Path is an 822-level copy of MailFrom, created at delivery time.

So, no, it no longer have a delegated address.



I understand that MLs want to field bounces so they can track and
inhibit certain recipients, not to mention shield senders from (possibly
very many) bounces in response to a single post. The vacation
autoresponses alone can get very tedious very quickly. I'm not clear on
how SPF alignment prevents this.



My observation about this imposing a rigidity for the MailFrom command 
was meant as a universal effect, not merely one relevant to list processing.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[Kurt Roeckx]

On Thu, Apr 10, 2014 at 06:59:41AM -0700, John Sweet wrote:
> I see the competing "answers" breaking down differently:
> 
>  - Mailing list implementation/practice must change to support From-header
> alignment

So that would mean that all mails on a mailling listshould
rewrite the From so that it's appears to come from someone in the
domain of the maillinglist?


Kurt

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

Re: [dmarc-ietf] DMARC's purpose

[Vlatko Salaj]

On Thursday, April 10, 2014 5:48 PM, Pierre-Alain Dupont wrote:
> I am really wondering as to what is your aim here.

understanding dmarc's aim is much easier if u study the way it came into being.

in short, dmarc is evolution of practice of reporting on phishing attacks big 
mailbox providers [yahoo, google] intercepted, on behalf of big email senders 
[facebook, paypal]. considering such two-way reporting helped big email 
senders, as well as mailbox providers, fight against phishing, they decided 
it's a good idea to standardise the entire protocol they devised for this 
purpose.

however, while it was great for such a narrow playfield, in which none used 
forwarding, mailing lists, or anything of sort, it's rly bad for internet in 
wide, where all these practices r not only common, but natural, as clearly 
defined by their rfcs.

the trouble is that, beyond fixing obvious problems with current dmarc 
protocol, ppl working on standardising this protocol don't rly imagine changing 
dmarc enough to account for all natures of internet emailing as seen today. 
instead, their tendency is to suggest fixes in those natures instead.

i will agree with anyone who thinks such policy is inherently broken. it is, 
without talking too much, simple common sense to build new things while 
accounting for all old practices evolved thus far in the same domain. 
otherwise, what u r doing is introducing conflict, and when u do that, u need a 
strongly better reason than just domain-based email authentication and 
reporting.

so, while phishing is a problem, dmarc will not solve it the way it's proposed 
today. dmarc will need to change greatly before domain owners start using  
p=reject widely. and its authors need to open up and start accepting new ideas. 
otherwise, all this effort won't mean much to anyone, but engineering teams in 
big email senders and big mailbox providers.

and world isn't so small, and, i hope, will never be.


-- 
Vlatko Salaj aka goodone
http://goodone.tk

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

Re: [dmarc-ietf] DMARC's purpose

[Jim Fenton]

On 04/10/2014 06:16 AM, Pierre-Alain Dupont wrote:
> After reading a few articles like
> http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html,
> I came to wonder as to why a soon-to-be standardized project came to
> on purpose break a huge part of the reality of today's emails.

This highlights one of the issues with the IETF publication process:
many people assume that anything with an RFC number is an IETF standard.
It was my understanding from Murray's message of March 26 that DMARC was
being considered as an informational RFC, which of course is not a standard.

More broadly:  I'm not an expert on IETF publication criteria, but I
hope that, especially given this confusion, controls are in place to
protect against the publication of informational RFCs that might be
harmful in some respect.

-Jim

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

Re: [dmarc-ietf] DMARC's purpose

[John Sweet]

I thought that's what the Return-Path: was for.

I understand that MLs want to field bounces so they can track and inhibit
certain recipients, not to mention shield senders from (possibly very many)
bounces in response to a single post. The vacation autoresponses alone can
get very tedious very quickly. I'm not clear on how SPF alignment prevents
this.

My humblest apologies if you already covered the particulars in an earlier
message, and I missed it.


On Thu, Apr 10, 2014 at 7:04 AM, Dave Crocker  wrote:

> On 4/10/2014 8:59 AM, John Sweet wrote:
>
>> I see the competing "answers" breaking down differently:
>>
>>   - Mailing list implementation/practice must change to support
>> From-header alignment
>>
>
>
> Just to be clear, WRT SPF, that means never being able to specify an
> address for return notifications, other than the author's address.  No
> "delegating" the handling of such operational aspects of a message.
>
>
>
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC's purpose

[Dave Crocker]

On 4/10/2014 8:59 AM, John Sweet wrote:

I see the competing "answers" breaking down differently:

  - Mailing list implementation/practice must change to support
From-header alignment



Just to be clear, WRT SPF, that means never being able to specify an 
address for return notifications, other than the author's address.  No 
"delegating" the handling of such operational aspects of a message.




d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC's purpose

[John Sweet]

I see the competing "answers" breaking down differently:

 - Mailing list implementation/practice must change to support From-header
alignment
 - Never publish a p=reject policy for a domain with human (non-automated)
senders

"Whitelist known-good MLs" seems to me to be an effective way to eliminate
the use of MLs entirely, since the number of lists, and of entities who
must whitelist them, gets rather large rather quickly.

In reaction to "MLs must change," I've seen, "Sure, I'll change -- to block
all memberships/posts from addresses with p=reject policies."

I've never heard DMARC proposed as a spam solution, only as a phishing
solution. In that respect I think it's been very successful.



On Thu, Apr 10, 2014 at 6:16 AM, Pierre-Alain Dupont  wrote:

>  Hi folks,
> After reading a few articles like
> http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html,
> I came to wonder as to why a soon-to-be standardized project came to on
> purpose break a huge part of the reality of today's emails.
>
> From what I can read on this ML, the subject of forwarders/ML has been
> discussed here numerous times, and basically, the answer is somehow either
> of:
>
>- We do not care, forwarding shouldn't exist anyway.
>- Well, this is out of the scope of DMARC.
>- Maybe you could white-list the more prominent ones or implement a
>way to do it automatically.
>
> Neither of those answers is really acceptable. The only credible one is
> the third (that, or this protocol is not meant to be really used and is a
> purely academic work).
>
> Basically, it appears to me as if you are designing a protocol that would
> be, on purpose, only accessible to big firms that can have the manpower to
> do such a white-listing and/or do not really about their captive users.
> Many people appear to believe that it is acceptable to lose 2% legitimate
> emails... Well, it is not.
> Moreover, it will introduce a bias toward ML providers that are widely
> white-listed and others, that can in fact no longer appear as they are
> already blocked. Again, I see a pattern of saying "emailing would be better
> if there were only a few providers".
>
> I am really wondering as to what is your aim here. Reducing spam is a
> great goal, but not by sacrificing so much.
>
> I know there has been discussion as to whether this should be an IETF WG.
> Well, the answer is no. Definitely no. After all, the mission of the IETF
> is to make the Internet work better, and purposely excluding a section of
> the Internet is not a way to do it.
>
> Regards,
> PA.Dupont
>
> ___
> 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

[dmarc-ietf] DMARC's purpose

[Pierre-Alain Dupont]

Hi folks,
After reading a few articles like
http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html,
I came to wonder as to why a soon-to-be standardized project came to on
purpose break a huge part of the reality of today's emails.

>From what I can read on this ML, the subject of forwarders/ML has been
discussed here numerous times, and basically, the answer is somehow
either of:

  * We do not care, forwarding shouldn't exist anyway.
  * Well, this is out of the scope of DMARC.
  * Maybe you could white-list the more prominent ones or implement a
way to do it automatically.

Neither of those answers is really acceptable. The only credible one is
the third (that, or this protocol is not meant to be really used and is
a purely academic work).

Basically, it appears to me as if you are designing a protocol that
would be, on purpose, only accessible to big firms that can have the
manpower to do such a white-listing and/or do not really about their
captive users. Many people appear to believe that it is acceptable to
lose 2% legitimate emails... Well, it is not.
Moreover, it will introduce a bias toward ML providers that are widely
white-listed and others, that can in fact no longer appear as they are
already blocked. Again, I see a pattern of saying "emailing would be
better if there were only a few providers".

I am really wondering as to what is your aim here. Reducing spam is a
great goal, but not by sacrificing so much.

I know there has been discussion as to whether this should be an IETF
WG. Well, the answer is no. Definitely no. After all, the mission of the
IETF is to make the Internet work better, and purposely excluding a
section of the Internet is not a way to do it.

Regards,
PA.Dupont

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