Subject: Re: Enough DMARC whinging

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 May 2014 09:22:26 -0400

On Wed, Apr 30, 2014 at 11:16 AM, Dave Crocker <[email-masked]> wrote:
> On 4/30/2014 10:03 AM, Andrew G. Malis wrote:
>>
>> Phillip,
>>
>>     Of course the way to make mailing lists work with DMARC would be to
>>     look at the headers and treat messages with mailing list headers
>>     differently. Perhaps the issue isn't in DMARC but how the information
>>     from DMARC is applied.
>>
>>
>>  From my reading of sections 10.2, 5.2, and 15.4 of
>> draft-kucherawy-dmarc-base-04, you can't do that and still claim
>> receiver conformance with that draft (although there's the question of
>> whether one should claim conformance to an informational draft in the
>> first place).
>
>
>
> (Conformance is voluntary.  People choose the specs they want to support, no
> matter the formal status.)
>
>
> To the extent that varying from -base produces better results at reasonable
> cost, then receivers will do it.  The challenge is to offer clear and
> compelling guidance about that variance and gain support for its use.
>
> For example, using the mere presence of List-* header fields as a basis for
> deviating from a domain owner's DMARC policy request would seem an easy
> attack vector by bad actors.
>
> On the other hand, using the presence of the fields, combined perhaps the
> list signing the message (and covering those fields) and with the receiver's
> knowing that the list operator has a good reputation might make quite a bit
> of sense...

Spam filters should know about things as important as mailing list
subscriptions.

It the mailing list has appropriate spam ingress controls, is
authenticated using DKIM and there is evidence that the user has
subscribed then the spam filter can whitelist all the messages from
that list.

And to the other conversations, we are talking about draft- here. And
that isn't the same as standard. In fact one of the requirements for
being granted standard would be to come up with answers to these
issues.

-- 
Website: http://hallambaker.com/

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 May 2014 10:53:41 -0400

--On Thursday, May 01, 2014 09:22 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

>...
> And to the other conversations, we are talking about draft-
> here. And that isn't the same as standard. In fact one of the
> requirements for being granted standard would be to come up
> with answers to these issues.

I recommend a careful reading of RFC 4846 before doing so, but,
with the understanding that there is no consensus process
involved and this list is definitely the wrong place to have, or
even copy, the discussion, if someone had well-thought-out
opinions as to whether that document should be published in the
Independent Stream and/or what completeness conditions should be
imposed on it, the ISE is typically willing to accept
unsolicited reviews.  Similarly, if someone felt like generating
a well-reasoned critique, posting it as an I-D, and asking that
the ISE consider publication, I assume such a request would at
least be considered.

I am definitely not speaking for Nevil or predicting his
reactions, but I would suggest one caution: RFC 4846 and
established practice gives the ISE far more flexibility (and,
indeed, license) to ignore or discard repetition, ranting,
strongly-stated opinions that are not grounded in solid
references or generally-accepted facts, etc., than, e.g., IESG
members have in response to IETF Last Call comments.  So, if
anyone decides to go that route, I'd suggest that they do so
with as high a level of professionalism as they can manage.

best,
    john

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 1 May 2014 11:07:04 -0400

Phillip,

> being granted standard would be to come up with answers to these

I could not agree with you more, EXCEPT in this case major service
providers (Yahoo, AOL, etc.) are already treating it as a standard, have
implemented it, and people are feeling the pain as a result (and not just
their users, since it's the recipients and mail list managers that are most
affected, not the senders).

Cheers,
Andy

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 May 2014 10:18:38 -0500

> Spam filters should know about things as important as mailing list

We have about 20 years of spam filtering experience in the industry.
The quality of modern filters is astonishingly good; it's the only
reason email remains viable for users, in spite of open-Internet spam
traffic being far above 90%.

I believe that little or none of that filtering includes awareness of
mailing list subscriptions.  So while the above is an interesting and
possibly useful line of pursuit, it's not clear how it can be elevated
to the status of 'should'.

Note that historically, mailing list operators have been resistant to
the imposition of technical or operational changes.

> subscribed then the spam filter can whitelist all the messages from

Nope.  Mailing lists can be sources of spam, too.  Even good lists.  So
blanket whitelisting would not be advisable.

However modern filtering engines are complex enough for nuance.  So they
can ratchet up or down just how stringent the criteria are. The above
scenario well might warrant less stringent criteria.

> being granted standard would be to come up with answers to these

Standards status matters, but not as an absolute.  The fact that the
text exists as an I-D also does not automatically impart importance or
utility, in terms of industry adopters.

Often it does, of course, but this doesn't seem to be one of those
cases, does it?

Sometimes we forget that the IETF is in the service of adopters, not
vice versa.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 1 May 2014 16:48:52 -0000

>the imposition of technical or operational changes.

I think you're overstating things a little.  I am very unsympathetic
to changes that would require retraining all my users, e.g., putting
the list address on the From: line.  Technical changes that don't mess
up the users are no more of an issue than any other software upgrade
is to a small volunteer site.  In particular, I've never seen anyone
opposed to adding DKIM signatures to help recipient systems recognize
the lists.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 May 2014 13:36:58 -0400

> Often it does, of course, but this doesn't seem to be one of those

When people are making arguments of the form 'X is wrong because the
standard says so' then the fact that it isn't a standard *is* an
absolute.

Even if it was a standard, it wouldn't be scripture and even if it was
scripture it wouldn't necessarily be true. All these policy proposals
end up being nonsense because the people writing them always seem to
think that there is someone out there who can tell people what to do.

The only party who gets to decide what DMARC or any other policy
statement means is the receiver. Everyone else is just offering
evidence or advice. So p=reject does not and cannot mean 'MUST reject
messages that don't conform'.  It can however mean 'there is a very
high probability that these messages are spam'.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 01 May 2014 13:50:26 -0400

> think that there is someone out there who can tell people what to do.

Well said.
> high probability that these messages are spam'.
Or perhaps, more accurately, under some conditions 'there is a very high 
probably that these messages are spam.'

Miles Fidelman

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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 01 May 2014 11:36:45 -0700

> the ISE consider publication, I assume such a request would at

I'd like to understand the relationship of RFC 4846, which is
Informational, with RFC 5792/BCP 92 here. The latter gives IESG 5
options for review of independent submissions for conflicts with the
IETF standards process, such as:

   5. The IESG has concluded that this document extends an IETF protocol
      in a way that requires IETF review and should therefore not be
      published without IETF review and IESG approval.

What is the appropriate forum to express opinions to the IESG to inform
their decision?

> with as high a level of professionalism as they can manage.

I have sent my detailed review of the draft, hopefully meeting those
criteria, to Nevil.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 May 2014 13:43:49 -0500

>       published without IETF review and IESG approval.

Since DMARC does not extend any existing IETF protocol, how is that
reference useful here?

d/

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 May 2014 14:44:01 -0400

> opposed to adding DKIM signatures to help recipient systems recognize

Don't confused silence with agreement.

Nonetheless, there has been new mail security related world needs for 
a long time now, and everyone has to adjust too.  That includes 
Mailing List Server software developers and list operators, especially 
when you want to change it for resigning and totally ignore the 9+ 
years of Author Domain signature protection methodologies.  Thats pure 
ignorance of mail integration needs. You changed the list system by 
adding DKIM.  That comes with baggage you refused to deal with.

All software product developers,  commercial or otherwise, for many 
list operations, not just one list operator which his own deployment 
views, but all of them, has to support and honor DKIM signing policies 
as well.  I personally MUST because its the sound mail engineering 
thing to do, but I'm happy with a SHOULD. However, you have been 
preaching MUST NOT, and this not right.

You can't have it both ways, John.   MLS software also must ADAPT or 
they are just as bad the bad guys using legacy mail software or legacy 
methodologies with the idea that backward compatibility will always 
available to sneak in with.

With DKIM, we raised the bar, the only way to protect the signature is 
with an originating author domain policy method.

The industry has forced the issue John and I happen to believe it was 
the right way to do it to begin to address the massive abuse of aged, 
spam-pulluted domains.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 May 2014 15:19:11 -0400

--On Thursday, May 01, 2014 11:36 -0700 Jim Fenton
<[email-masked]> wrote:

>> I recommend a careful reading of RFC 4846 before doing so,
>> but, with the understanding that there is no consensus process
>> involved and this list is definitely the wrong place to have,
>> or even copy, the discussion, if someone had well-thought-out
>> opinions as to whether that document should be published in
>> the Independent Stream and/or what completeness conditions
>> should be imposed on it, the ISE is typically willing to
>> accept unsolicited reviews.  Similarly, if someone felt like
>> generating a well-reasoned critique, posting it as an I-D,
>> and asking that the ISE consider publication, I assume such a
>> request would at least be considered.
> 
> Informational, with RFC 5792/BCP 92 here. The latter gives
> IESG 5 options for review of independent submissions for
> conflicts with the IETF standards process, such as:
>...

Briefly, 4846 is Informational because there is no mechanism for
the IAB to publish documents in what is now called the IETF
Stream (and BCPs are published only in that stream).  The
document was published in what we now call the IAB Stream
because the RFC Editor function, including the Independent
[Submission] Stream, operate under IAB authority (and have since
before there was an IETF).  

The other important part of the relationship between 4846, 5792,
and the predecessors of the latter, is that the ISE is not
required to follow whatever advise the IESG provides.  I think
we would all hope and assume that the ISE would not reject such
advice lightly, but a very important part of the relationship is
the ability of the ISE to publish documents that are critical,
even strongly so, of IETF Standards Track specifications and
decisions.  For that level of independence to be viable, the
IESG cannot have veto power over publications of documents it
doesn't like, whether that veto power requires cleverness to fit
into one of those five (IESG-created) categories or not.

>...
> What is the appropriate forum to express opinions to the IESG
> to inform their decision?

While neither document requires the IESG to solicit such input,
I would assume that they would be open to whatever comments are
made to them at their usual address.  Some sitting AD might want
to provide more specific advice (or not).

>...
> I have sent my detailed review of the draft, hopefully meeting
> those criteria, to Nevil.

I hope he finds it useful.

best,
   john

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 01 May 2014 16:55:34 -0400

> Since DMARC does not extend any existing IETF protocol, how is that

Sure looks to me like DMARC extends both SMTP and DNS.

Miles Fidelman

---

From: Mark Andrews <[email-masked]>
Date: Fri, 02 May 2014 07:51:06 +1000

> Sure looks to me like DMARC extends both SMTP and DNS.

And DKIM.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Hector Santos <[email-masked]>
Date: Thu, 01 May 2014 19:05:40 -0400

>> Sure looks to me like DMARC extends both SMTP and DNS.

Yup. DMARC undoes the signer domain vs author domain "separation 
question" DKIM says it does in the rfc6376 abstract and repeated in 
the introduction:

    DKIM separates the question of the identity of the Signer
    of the message from the purported author of the message.

We never found out what the "question" was.

-- 
HLS

---

From: Doug Barton <[email-masked]>
Date: Thu, 01 May 2014 21:28:58 -0700

On 05/01/2014 08:07 AM, Andrew G. Malis wrote:
> implemented it  ...

Rough consensus and running code.

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 02 May 2014 00:30:59 -0400

> Rough consensus and running code.

VERY rough

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 02 May 2014 14:12:43 +0200

>> Spam filters should know about things as important as mailing list

+1

> to the status of 'should'.

It is certainly useful to simplify spam filtering.  I think there
would be consensus on 'should'; not on 'must' because of privacy
considerations.

> the imposition of technical or operational changes.

I'm not clear what you mean.  Is there a standard that defines mailing
lists?

Ale

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 02 May 2014 08:51:02 -0400

>> the imposition of technical or operational changes.

Speaking for at least one mailing list operator, who knows a lot more:  
I've ALWAYS implemented quite a bit of controls over our lists - both 
authenticating users before allowing them to join lists, and 
implementing extensive spam filtering at both the MTA and list level.  
The list software we use (Sympa), likewise has multiple spam and virus 
filtering mechanisms, as well as hooks for linking with external 
mechanisms.  I haven't worked with Mailman extensively, but it also has 
spam filtering mechanisms.

Spam is as much, or more of a problem for list operators, as anyone 
else.  What I object to is when someone foists a new mechanism down our 
throats - without any care for breaking things.

Actually, you may have unintentionally phrased this accurately: I (and 
probably other list operators) are "resistant to the IMPOSITION of 
technical or operational changes." Working WITH us, might yield better 
effect.  And there are at least two forms that could have taken:

1. Contribute support (labor/dollars) to write patches to the major 
email list packages, BEFORE turning on restrictive DMARC policies. (We 
are talking about large, well funded corporate entities who have 
invested dollars in developing and implementing DMARC for business 
reasons that presumably have signficant payback).

2. Designing and implementing mechanisms that mitigate the impact on 
mailing lists - for example, whitelists.

3. Actually developing something that plays nice with whitelists - as 
there is now some discussion about (XOAR, whitelists, ....).

> I'm not clear what you mean.  Is there a standard that defines mailing
There are some that approach it - like the SMTP extensions for 
list-related headers.  I personally think mailing list functionality is 
well enough understood that we could improve on this, and incorporate 
some standard authentication mechanisms in the process.

Personally, I think some kind of standard that allows for:
- separate identification and signing/authentication of author, 
originating MTA, list/forwarder would go a long way (I think this would 
require additional headers and/or standardizing the use of existing 
headers a bit more tightly)
- maybe an extra list header or two regarding reply-to (separate author, 
author-errors, list, list-errors)
- a mechanism that allows a list to modify messages that doesn't break 
incoming signatures, say:
--- separate "original-subject" "subject-with-tags""listname" headers
--- a well-specified way to add a header and/or footer to a message 
(e.g., headers to indicate header-line-count, and footer-line-count)
--- provisions for MIME
--- i.e., a recipient can verify the original message and author, verify 
changes that have been made by a listprocessor, run some checks on the 
diffs, then make a decision on what to do with the message
- maybe some best practices for mail client presentation of information 
to end users

Miles Fidelman

---

From: t.p. <[email-masked]>
Date: Fri, 2 May 2014 14:25:10 +0100

----- Original Message -----
From: "Miles Fidelman" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 02, 2014 1:51 PM
> >> On 5/1/2014 8:22 AM, Phillip Hallam-Baker wrote:
<snip>

> - maybe some best practices for mail client presentation of
information

Miles

I do not think that the behaviour of mailing lists is well enough
defined and so the various authentication mechanisms have too much
variation to cope with and so do not.

I get mail from several IETF lists and
 - may or may not get a [tag]
 - may or may not have From: replaced by an IETF address
 - may have From: replaced by a nickname and no IETF address
 - usually get List: headers
and so on and so forth.

What I think is needed is a well-defined and short description of what a
well-behaved mailing list might do, and then DKIM and such, or perhaps
just a best practices thereof, could make mailing lists
authentication-friendly

I do not think it worth trying to do anything that calls for MUA
changes - it will take too many decades to roll out.

I think that DMARC has got this badly wrong, but that we have created
enough pitfalls that they can easily do so.

Tom Petch

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 02 May 2014 09:41:21 -0400

> just a best practices thereof, could make mailing lists
Pretty much all the major mailing list packages perform the same set of 
functions, and provide similar configuration options:
- you may or may not get a tag - but tagging is a well understood 
function - that can be standardized
- there is a From: in all message - mailing list software performs a 
small list of functions that overload the field - that suggests adding a 
standard header or two to move those functions out of the From: field

We could all benefit from taking a list of common mailing list 
functions, and advancing a standard for how to perform those functions - 
that would allow for better interaction with lots of things - most 
notably authentication mechanisms, and perhaps pave the way toward 
improved clients.

Miles Fidelman

---

From: Dave Crocker <[email-masked]>
Date: Sat, 03 May 2014 09:42:01 -0700

>> Sure looks to me like DMARC extends both SMTP and DNS.

No, No, and No.

Don't confuse 'use' with 'extend'.

TCP "uses" IP.  It does not "extend" it.  That's what architectural
layering is about.  Functions above a layer do not extend the lower
layer; they use it.

DMARC /uses/ DKIM (and SPF).  It does not alter (extend) either of them.

As for any claim that DMARC 'extends' SMTP or DNS, it's difficult to
imagine the technical logic behind such an assertion.

d/

ps.  The original note was from Jim Fenton and it was him I was asking
to explain his reference.  He seemed to be making a point and I was
asking him to provide it explicitly.

---

From: "John Levine" <[email-masked]>
Date: 3 May 2014 17:02:50 -0000

>imagine the technical logic behind such an assertion.

The argument that it extends SMTP is not totally ridiculous.  Where
did these SMTP rejections come from, if not DMARC?

2014-04-07 08:18:59.693287500 delivery 117461: failure: 2607:f8b0:4001:0c03:0000:0000:0000:001b_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.1_Unauthenticated_email_from_yahoo.com_is_not_accepted_due_to_domain's/550-5.7.1_DMARC_policy._Please_contact_administrator_of_yahoo.com_domain_if/550-5.7.1_this_was_a_legitimate_mail._Please_visit/550-5.7.1__http://support.google.com/mail/answer/2451690_to_learn_about_DMARC/550_5.7.1_initiative._k7si18580912icu.45_-_gsmtp/
2014-04-07 08:19:00.680001500 delivery 117452: failure: 2607:f8b0:4001:0c03:0000:0000:0000:001b_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.1_Unauthenticated_email_from_yahoo.com_is_not_accepted_due_to_domain's/550-5.7.1_DMARC_policy._Please_contact_administrator_of_yahoo.com_domain_if/550-5.7.1_this_was_a_legitimate_mail._Please_visit/550-5.7.1__http://support.google.com/mail/answer/2451690_to_learn_about_DMARC/550_5.7.1_initiative._c1si22721698igj.35_-_gsmtp/

R's,
John

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 03 May 2014 13:55:45 -0400

> imagine the technical logic behind such an assertion.

1. DMARC essentially species a change to the behavior of mail 
reception.  It sure looks to me like an extension to the state machine 
model for mail processing, at the SMTP level.  Arguably, the same can be 
said for what forwarders (including mailing list processors) do.

2. As to DNS: There's a long standing argument about the use of TXT 
records for purposes beyond holding "descriptive data."  Last time I 
looked (just now) there has been nothing since RFC1035, which states 
"TXT RRs are used to hold descriptive text" and RF1464, about storing 
arbitrary string attributes, and remains experimental. DKIM, SPF, and 
DMARC both define and use TXT RRs in ways that go beyond their defined 
scope.
> asking him to provide it explicitly.
Yes.  I'm agreeing with Jim, and providing some backup to his point.

Miles Fidelman

---

From: Jim Fenton <[email-masked]>
Date: Sat, 03 May 2014 16:35:55 -0700

> asking him to provide it explicitly. 

I have been trying to avoid additional DMARC whinging on this thread
(and list), but alas...

> Since DMARC does not extend any existing IETF protocol, how is that

I was citing one of the five options IESG has. For brevity I chose not
to cite all five (everyone can find them in RFC 5742, not 5792 which was
a typo).

But since you bring it up, DMARC does alter (extend) SMTP, for example
by its recommendation in Section 10.1 that messages containing a single
RFC5322.From with multiple entities be rejected. It might be argued
that's not a significant limitation, but that's what the IETF review is
all about.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 08:19:50 -0700

> that's not a significant limitation, but that's what the IETF review is

This confuses advice about policies for /use/ of a protocol, versus
/specification/ of the protocol itself.  "Extending" means modifying the
protocol.  Changing the bits over the wire; changing semantics of the
bits.  Bits over the wire is the usual IETF definition of 'protocol'.

The SMTP specification makes no attempt to give comprehensive guidance
about receiver policies for rejecting or accepting mail.  Nor should it.

The DMARC draft does not alter the bits over the wire.

John Levine's example of DMARC defining additional response codes is
somewhat more interesting, though I'd still class it as pretty minor,
since its not changing any major reply values.

d/

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 05 May 2014 14:31:58 -0400

> since its not changing any major reply values.
Let's be clear about something - it's not just "bits over the wire" - 
it's side effects as well, notably state machine changes in the protocol 
engines.

Miles Fidelman

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 May 2014 12:46:27 -0700

> Sure looks to me like DMARC extends both SMTP and DNS.
How?  I'm fairly certain it does neither.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 May 2014 12:51:46 -0700

> How?  I'm fairly certain it does neither.

Sorry, I missed that there were later replies.

The SMTP state machine is not changed by DMARC any more than SPF or others
changed it.  It doesn't add any new states, verbs, parameters, or anything
else.  DMARC sits at least two "layers" above where SMTP operates.  As with
any number of other filtering systems, it can influence SMTP's final DATA
reply, but that's hardly unique or even unusual.

There is no new protocol element introduced by DMARC to DNS either.  There
are no resource record types registered, no new protocol elements added,
etc.  No part of the deployed DNS infrastructure needs to change for DMARC
to work.

As Dave pointed out, it's a layer on top of other widely deployed things.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 May 2014 16:11:00 -0400

On Mon, May 05, 2014 at 12:51:46PM -0700, Murray S. Kucherawy wrote:
> are no resource record types registered

While that is true (and is indeed evidence that there's not a
"protocol extension" here), there are several of us who regard that
particular decision as a bug, not a feature.  It seems a bizarre way
to defend the approach.

I understand the reasoning for the conclusion and I accept it.  It's
still an abuse of the DNS's data model.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Mon, 5 May 2014 21:17:43 +0100

> reply, but that's hardly unique or even unusual.
It aims to change the behaviour of Internet Mail as deployed.

Whether you want to claim that this is formally extending SMTP, per-se, or
not is really something of a moot point - there is certainly an
intentional, large, effect on the deployed protocol. Arguing whether this
fits the letter of some particular definition smacks of lawyering to my
mind.

Dave.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 14:53:08 -0700

On 5/5/2014 1:17 PM, Dave Cridland wrote:
> Whether you want to claim that this is formally extending SMTP, per-se,
> or not is really something of a moot point - there is certainly an
> intentional, large, effect on the deployed protocol. Arguing whether
> this fits the letter of some particular definition smacks of lawyering
> to my mind.

If a large market player declared that all mail to and from them were
required to be written in a specific language, would that we a matter
for the IETF to deal with?  I think not.  (For all I know, some ISP out
there already behaves that way.)

Actions like that are at the level of "politics of use" rather than
"technology of use".  While each of us might have opinions for any such
policy, it's not the IETF's job or competence to get enmeshed in such
politics.

However if a large market player took that action and then wrote a
document explaining it and wanted that document published as an
independent stream RFC, I'd think the greater service to the community
would be to publish it.  That way the document becomes part of an
important Internet archive.

d/

ps.  And there's nothing to prevent others with opposing views from
publishing their own document, explaining the implications and evils of
the actions by the large market player...

---

From: Dave Cridland <[email-masked]>
Date: Mon, 5 May 2014 23:32:47 +0100

> there already behaves that way.)
I think not too. Or either. Or neither. Whichever, that's an impressive
straw man, but largely unrelated to several market players working together
on a change in behaviour.

Dave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 May 2014 22:59:45 -0700

> It aims to change the behaviour of Internet Mail as deployed.

So did sendmail rewrite rules, SPF, spamassassin, or anything else you can
recall that established new acceptance requirements of some kind.  This is
hardly a new concept.

> fits the letter of some particular definition smacks of lawyering to my

I never said that it has no impact, or even a small impact.  (I would also
point out that amid all this angry mudslinging, it's been pointed out
several times that DMARC has been in use by some operators for more than a
year, and for them it works fine and has had no visible negative impact.)

What I am saying is that it does not achieve its impact using the mechanism
claimed up-thread, namely some kind of extension to SMTP or DNS.

Speaking derisively about precision of expression in a standards community
seems pretty strange to me.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 May 2014 23:01:54 -0700

> particular decision as a bug, not a feature.  It seems a bizarre way

I wasn't defending the approach, actually.  I was merely responding to an
incorrect claim about how it was done so far.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 07 May 2014 10:01:21 -0700

Hi Dave,
>policy, it's not the IETF's job or competence to get enmeshed in such

A large market player decided that all mail to them should comply 
with a technical specification.  That specification has not been 
published or recommended by the IETF.  According to (unverified) 
estimates the companies with the most email users are Gmail, 
outlook.com and Yahoo Mail.

One of the early comments on the various threads about the technical 
specification was whether the IAB can do anything about the technical 
specification.  There were comments about whether the IETF can do 
anything about the technical specification.  Should the IETF do 
anything if a large market player decides that all mail sent to it 
should comply with a technical specification?  There are different 
opinions about that.  People without influence [1] usually turn to 
the (relevant) government or an organization which they consider as 
influential when a large market player does something they dislike.

Regards,
S. Moonesamy

1. People with influence talk to the king. :-)

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 7 May 2014 23:20:59 +0100

Those players can be considered as large community servers as the
mail services are free, so that market is indirect market. IETF is also
community server, but can it alone solve that problem compared to those
players. The power is with who serves the larger community or with who
owns the best service/practice.

AB

On Wednesday, May 7, 2014, S Moonesamy wrote:

> A large market player decided that all mail to them should comply with a
> technical specification.  That specification has not been published or
> recommended by the IETF.  According to (unverified) estimates the companies
> with the most email users are Gmail, outlook.com and Yahoo Mail.
>
> specification.  There were comments about whether the IETF can do anything
> about the technical specification.  Should the IETF do anything if a large
> market player decides that all mail sent to it should comply with a
> technical specification?  There are different opinions about that.  People
> without influence [1] usually turn to the (relevant) government or an
> organization which they consider as influential when a large market player
> does something they dislike.
>
> Regards,
> S. Moonesamy
>