Subject: [dmarc-ietf] Change the mailing list protocol, not DMARC.

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Jun 2014 08:40:50 -0400

On Sat, May 3, 2014 at 2:08 PM, Hector Santos <[email-masked]> wrote:

> Let me ask, what if a fedex.com employee use this email domain for
> subscribing to the IETF list?

Any subsequent problems are irrelevant unless FedEx, the owner of
fedex.com considers them to be relevant.

That is what folk complaining don't get: you don't have the right to
use your employers email or a public email provider's email any way
you want. The domain name owner makes the rules.

As Craster insists: My domain, my rules.

If you want to make the rules then get your own domain. I think that
is something most IETF participants know how to do.

In the medium term, lets kill the stupidity of mailing lists with a
protocol that works. NNTP was originally designed to replace mailing
lists. It actually works quite well at that. The only problem was the
IT-Dictator mindset that underlies it: newsgroups have to be approved
by the Commune!

The idea that newsgroups work by the mail client PULLING a list of
unread messages and then PULLING those that are to be read is the best
architecture for newsgroups.

I am currently using 8Gb of my primary Gmail account space, 80% of
that is my mailing list mail. Google and Yahoo could both save tens of
millions of dollars worth of hard drives a year with a better
protocol, thats incentive to invest.

The only points that need to change are the mailing list programs need
to offer a very simple network API and the clients need to accept it.
The second is not so difficult to deploy for the 90% of webmail users.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 01:38:56 +0900

I'm not sure what the long list of addressees was about, but I'm not
comfortable with them.  Feel free to repost my message if you wish.

Phillip Hallam-Baker writes:

 > lists.

GNU Mailman is thinking about this for Mailman 3.  Of course we've
long had a mostly functional mail-to-news bidrectional gateway, but
Mailman 3 is considering adding NNTP capability directly to the
bundled archiver, or perhaps a separate facility resembling an
archiver as far as Mailman core is concerned.[1]  I don't think this
has gone anywhere yet, though.

 > It actually works quite well at that. The only problem was the
 > IT-Dictator mindset that underlies it: newsgroups have to be
 > approved by the Commune!

Nonsense.  I don't know what the problem that prevented netnews from
obsoleting mailing lists is, but the alt hierarchy has always been
available, and GMane proves that you can run a whole alternative NNTP
network without trouble and with a reasonable amount of resources.  So
it's not the Cabal's fault (by the way, there is no cabal, in case you
haven't heard).

 > protocol, thats incentive to invest.

I suspect that's part of the reason for *groups.

Regards,

Footnotes: 
[1]  Not in the core, because it doesn't have and shouldn't grow a
message store beyond the in-process queues.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jun 2014 18:47:54 +0200

On 6/7/2014 6:38 PM, Stephen J. Turnbull wrote:
> I don't know what the problem that prevented netnews from
> obsoleting mailing lists is

At base, netnews and mailing lists are entirely different kinds of human
communication services.  The critical construct that highlights the
difference is:  subscriptions.

Really, the participation and scaling characteristic differences between
bulletin boards -- which are essentially broadcast -- versus mailing
lists -- which are multicast, are huge.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 8 Jun 2014 10:38:19 -0000

>difference is:  subscriptions.

Netnews has subscriptions.  On the client side you can say which
newsgroups you want to read, and on the server side you can say
which users are allowed to read which groups.

>lists -- which are multicast, are huge.

Huh?  Usenet is multicast, with each server sending messages to other
servers it knows.  I suppose it's broadcast in the sense that
everything goes everywhere with no overall control.  That led to vast
amounts of spam.  Even worse, as spammers started scraping addresses off
usenet messages (which as far as I can tell they no longer do, but it's
too late now) people used fake addresses, leading to no accountability.

One of the reasons mailing lists are useful is that there are list
managers who can control who gets to post to the list and eject
trolls.  Moderated newsgroups sort of do that, although they have
other issues.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jun 2014 12:49:55 +0200

> which users are allowed to read which groups.

Different concept of subscription.

You are describing local distribution controls.  Since netnews is a
global process with no concept of global access control, it is
fundamentally different than the sort of centralized control embodied in
a mailing list subscription.

The mailing list distribution model is central control, with multicast
to subscribees.

The netnews distribution model is flooding distribution to whoever
participates.  That local distribution controls might happen in addition
is just that:  local policy.

> servers it knows.  

It uses a flooding algorithm, to make sure that a message from any
server gets to all the others.

Mailing lists have no built-in concept of feeding other servers.  It's
an entirely centralized model.

> I suppose it's broadcast in the sense that
> everything goes everywhere with no overall control.

Yeah, that's kinda what broadcast means.

> trolls.  Moderated newsgroups sort of do that, although they have

Exactly.  As I said, fundamental differences.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Jun 2014 08:46:00 -0400

> has gone anywhere yet, though.

NNTP was designed 30 years ago. We should consider moving on. The
modern protocol world is JSON/REST

> it's not the Cabal's fault (by the way, there is no cabal, in case you

Well you don't get the difference between the Web and the Internet then.

We built the web on a model where the individual was empowered. Having
to get a proposal for a newsgroup approved by an amorphous collective
isn't empowering. The lack of clear control does not mean that there
isn't any. It just means that the control is exercised without
accountability.

NNTP was built to save bandwidth, hence the need to manage what data
went where. But we could certainly drop the server-server copy
functions and just declare the mailing lists as site local.

The problem with that approach is that we then have to have accounts
and the single log in problem grows unless we interface to one of the
single log in schemes, all of which have problems.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 09 Jun 2014 02:00:37 +0900

Phillip Hallam-Baker writes:

 > NNTP was designed 30 years ago. We should consider moving on.
 > The modern protocol world is JSON/REST

That's off-topic for this list, IMO, and I don't intend to discuss it
unless the moderator(s) make clear that it is on-topic.

What I believe is on-topic is that several people participating in
development of DMARC-related standards have expressed concern about
the impact on mailing lists.  There's no question that "p=reject" is a
knife at our throats, because much of the value-added of Mailman-style
lists to end users is in the "decoration" added to posts, and I have
yet to see anyone (except Franck Martin) say on the Mailman channels
that From-corruption is completely acceptable.  All mitigations
proposed so far are deeply unpopular with our users (list operators),
as well as with the developers.  Nor is it clear that any standard for
third party authentication will be approved at all, let alone adopted
widely by Author Domains in good time.

The mention of Usenet suggested a completely "out of the box" way to
sidestep DMARC impact by avoiding SMTP entirely, using NNTP as an
alternative transport.  I merely wanted to make it clear that GNU
Mailman is *technically* prepared to think about that kind of thing,
if better mitigations for the SMTP transport aren't developed.
(Development of a new "modern" transport is completely out of the
question for us; we have neither the skills nor the resources.)  Both
the security ramifications of NNTP and the social ramifications of
changing from a push protocol to a pull protocol for transport are
entirely unclear to me, however.

And of course I don't speak for any other MLM development communities.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jun 2014 22:26:12 +0200

> entirely unclear to me, however.

So that certainly could be an interesting discussion, although it's not
nearly as promising as one might think at first blush.

The semantic difference in the models of MLs vs. Usenet, and the
challenge of adapting the latter to the form, as well as adapting all of
the security and support infrastructure, are likely to be daunting.

But it might force a refreshing discussion about the nature of MLs and
what is needed to support them properly.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jun 2014 22:28:01 +0200

On 6/8/2014 2:46 PM, Phillip Hallam-Baker wrote:
> NNTP was built to save bandwidth,

Flooding protocols do not do a very good job of saving bandwidth.

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 Jun 2014 18:39:29 -0400

> the impact on mailing lists.

Stephen, Phillip is spreading synergism.

For example, it wouldn't be off-topic if someone proposed a DMARC 
callout mechanism based on JSON/REST (API) wire.  It will be viewed as 
a technological competitive alternative to using a DNS-based mechanism 
directly.  It might access a different backend database or just as API 
wrapper on top of a DNS API already and serves as a tool for web-based 
client development.

The IETF DNS community do consider to things, especially with the 
growth of DNS TXT-based applications.  There are many network and 
system level design considerations. In this vain, Phillip was 100% 
on-communications-par.

> There's no question that "p=reject" is a
> that From-corruption is completely acceptable.

To express how strong I feel about this....

If there is a charter for a new DMARC WG work, you can bet I will 
request that any form of 5322.From-Corruption concept be considered 
OFF TOPIC and OUT OF SCOPE in the new WG charter except to be aware of 
intentional From-Corruption is to be considered a new security exploit 
and threat to be mitigated. And for the record, I will also appeal any 
IETF work that begins to suggest From-Corruption concepts as a means 
to bypass security protocols. I will appeal it.

If the idea includes getting permission, thats less damaging, but 
still bad. Not as a solution to the problem that comes about by not 
even doing a lookup. See below.

> All mitigations

Thats a different problem and your frustration is well understood. But 
the proposals were not the problem.  Forget 3rd party concepts for the 
moment, you gotta accept the idea that you even want to do a LOOKUP.

Are you ready to do a LOOKUP?

There are two basic ML implementations problems here:

  1) Doing a LOOKUP,
  2) Honoring the Lookup record protocol semantics.

For the ML, it hasn't even gotten to the idea of a lookup and it 
really doesn't have to do it directly, but whatever is receiving our 
mail has to do the lookup.   We can make it work for our MLS and MDA 
because our MLS will create an acceptable list addresses text file. 
So we can add a script at the MDA to check this list and do any 
restriction checks.  Does your setup allow for scripting at the MDA level?

> alternative transport.

No, as an existing Client Portal with an offline mail reader or 
browser with a web-view of mail conferences. The network transport is 
still SMTP.

Again, Synergy!! Our NNTP server allows you to gate a mailing list.

   news://publicnews.winserver.com/ietf-drafts

or the mailing list for SPF:

news://publicnews.winserver.com/spf.-.sender.policy.framework.discussion
   news://publicnews.winserver.com:119/spf.-.sender.policy.framework.help

I don't remember if the above actually allows anonymous news readers.

Synergy. I could, if wanted to to satisfy Frank's MUA change proposal, 
show a NNTP backend generated text change to any of the 5322 display 
headers or even the body.

> question for us; we have neither the skills nor the resources.)

Good point, so its only off-topic for GNU Mailman.  It doesn't make it 
off-topic for others.   I am not suggesting NNTP or JSON/REST as part 
of the solution.  We are still at baby steps here of just doing a 
lookup.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 Jun 2014 19:26:58 -0700

>> the impact on mailing lists.
As this isn't a list associated with a working group, it doesn't have a
formal charter as such other than the idea that we probably should stick to
the one-paragraph description we gave to the IESG to create the list, which
says:

"Discussion related to the development, clarification, and implementation
of the DMARC protocol, and operational uses of it."

Since mailing lists are obviously a major consideration for DMARC, paying
them due attention is certainly valid here as long as it's in the context
of DMARC.  The more abstract conversation about "mailing lists redux"
should probably get its own list, or maybe take place on ietf-822, at least
until there's actual work before the IETF such as a draft.

However, again on the informal point, I don't think there's a need to make
a declaration about something being off-topic until it's clearly become a
distraction from the above.

If there is a charter for a new DMARC WG work, you can bet I will request
> that any form of 5322.From-Corruption concept be considered OFF TOPIC and
> OUT OF SCOPE in the new WG charter except to be aware of intentional
> From-Corruption is to be considered a new security exploit and threat to be
> mitigated. And for the record, I will also appeal any IETF work that begins
> to suggest From-Corruption concepts as a means to bypass security
> protocols. I will appeal it.
>

Setting aside for the moment how premature this threat is given that
there's not even a skeleton charter under proposal right now, I suggest you
read Section 6.5 of RFC2026 to figure out what the official basis would be
for such an appeal.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Jun 2014 00:06:26 -0400

On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote:
>     request that any form of 5322.From-Corruption concept be
>     considered OFF TOPIC and OUT OF SCOPE in the new WG charter except
>     to be aware of intentional From-Corruption is to be considered a
>     new security exploit and threat to be mitigated. And for the
>     record, I will also appeal any IETF work that begins to suggest
>     From-Corruption concepts as a means to bypass security protocols.
>     I will appeal it.
>
> there's not even a skeleton charter under proposal right now,

Its better to get this bud nipped now.

>I
> suggest you read Section 6.5 of RFC2026 to figure out what the
> official basis would be for such an appeal.

Murray,

Fundamentally, any From-Corruption (good term to use) concept is bad. 
30 years of mail software/product/hosting development across multiple 
networks tells me so, it ethically burns inside me as wrong and I have 
strong confidence the IETF/IESG wise ones will agree. I hope you agree 
too.

You will need to add security information to your DMARC document as 
this From-Corruption concept would be a security exploit that can 
potentially get by RFC5322 validation checks that can hurt DMARC 
publishers and create bad PR for the DMARC protocol itself.  DMARC 
receivers will need to be warned.

You will need to provide guidelines for mitigating it, not for 
allowing it unless there is an explicit policy defining language 
authorizing it, and even then, that can be cracking open a loophole.

You may want to make it a boundary layer check thing. The exploit will 
need to be described just like it was done for DKIM's Double From 
situation with RFC5322 validation checks done at receivers.

Consider it a "to-do" note for when the anticipated official DMARC WG 
begins.

Thanks

-- 
Hector Santos, CTO
http://www.santronics.com

---

From: Brandon Long <[email-masked]>
Date: Sun, 8 Jun 2014 22:32:14 -0700

I fundamentally disagree with your assertions on this matter and completely
fail to see the how ethics are even involved.

The message is already corrupted, or there wouldn't be a problem to be
solved.

I also fail to see how this is a security issue.  Afaik, dmarc is designed
to prevent potentially false messages from reaching inboxes if they contain
the domain in the from.  Munging the from domain meets that requirement,
and is the suggested mlm mitigation strategy on the dmarc.org website.

We're not ascribing words to random people, nor to list owners.  There are
certainly examples of systems that munge from headers, there are also
systems which assign non specific from headers to folks (FB/G+/Twitter
comments and status messages, forum software post notifications, customer
support portals).

Brandon
On Jun 8, 2014 9:06 PM, "Hector Santos" <[email-masked]> wrote:

> Fundamentally, any From-Corruption (good term to use) concept is bad. 30
> years of mail software/product/hosting development across multiple networks
> tells me so, it ethically burns inside me as wrong and I have strong
> confidence the IETF/IESG wise ones will agree. I hope you agree too.
>
> You will need to add security information to your DMARC document as this
> From-Corruption concept would be a security exploit that can potentially
> get by RFC5322 validation checks that can hurt DMARC publishers and create
> bad PR for the DMARC protocol itself.  DMARC receivers will need to be
> warned.
>
> You will need to provide guidelines for mitigating it, not for allowing it
> unless there is an explicit policy defining language authorizing it, and
> even then, that can be cracking open a loophole.
>
> need to be described just like it was done for DKIM's Double From situation
> with RFC5322 validation checks done at receivers.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Matt Simerson <[email-masked]>
Date: Sun, 8 Jun 2014 23:01:58 -0700

On Jun 8, 2014, at 10:32 PM, Brandon Long <[email-masked]> wrote:

> The message is already corrupted, or there wouldn't be a problem to be solved.

When the message arrives at the list, it's unlikely that it's already corrupted. What has been described is corrupting the From header by the same entity that is about to break the DKIM signature by altering the  the message. This should be called the "break it worse" method.

> I also fail to see how this is a security issue.

Agreed. It's *really* easy to filter and block delivery for non-existent domains.

Matt

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Jun 2014 02:22:56 -0400

>for non-existent domains.

That is exactly what will be required to mitigate and close this new 
security hole.

   if mail.from.tld is ".invalid" then
      reject it, or
      accept and discard, or
      accept and quarantine

Then it won't be a potential security problem any more.  We went 
through this same issue with DKIM and its Multiple From headers 
security hole.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 Jun 2014 23:33:50 -0700

> confidence the IETF/IESG wise ones will agree. I hope you agree too.

I understand that this is your opinion and that you're passionate about
it.  I have no idea where consensus falls, and I don't think I've given it
enough thought to have my own opinion yet.

> bad PR for the DMARC protocol itself.  DMARC receivers will need to be

The base document doesn't advocate changing From as a method of solving
anything.  It only lays out the alignment requirement; compliance is an
exercise for the reader (or for some other document).  As far as I know,
nobody's even suggested adding that to the base document, so I have no idea
why you're threatening an appeal about it, or on what RFC2026 basis you
might do so.

Now, if someone were to write a draft that actually tries to codify this
practice, then I agree, the security implications of doing so would need to
be well documented.  But that has yet to materialize, so I don't see what
all the hubbub is about.

-MSK

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 9 Jun 2014 22:30:42 +0200

On Monday, June 09, 2014 8:01 AM [GMT+1=CET], Matt Simerson wrote:

> When the message arrives at the list, it's unlikely that it's already
> corrupted. What has been described is corrupting the From header by
> the same entity that is about to break the DKIM signature by altering
> the  the message. This should be called the "break it worse" method.

So, when the MLM relaying the message adds a subject tag, that alteration is a welcomed "decoration" - but when it changes the mailbox in the Header-From to itself, it is an unwelcomed "corruption".
 
I can understand the welcomed vs unwelcomed thing, but I do not agree with calling the alteration "decoration" in one place but "corruption" in the other.
 
Loading the language in such a way is asking for a given conclusion even before the debate has started. That's not fair (I'm not predicating that from you, Matt, just talking in general terms).

Regards,
J.Gomez

---

From: Matt Simerson <[email-masked]>
Date: Mon, 9 Jun 2014 13:51:05 -0700

> Loading the language in such a way is asking for a given conclusion even before the debate has started. That's not fair (I'm not predicating that from you, Matt, just talking in general terms).

You'll note that I didn't introduce either the terms decoration or corruption. I described *both* message alterations as breakage. In the context of DKIM, and consequently DMARC, I think that's a perfectly fair description. Breaking DKIM has been a liberty that mailing lists have thus far been able to get away with. 

For a time, DMARC early adopters danced around it the DKIM breakage problem by splitting their message streams into "transactional" vs "personal."  For some, that recently changed and now there are consequences for mailers that break DKIM signatures. I think that's a *very* fair assessment.

Matt

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 12:59:02 +0900

J. Gomez writes:

 > I can understand the welcomed vs unwelcomed thing, but I do not
 > agree with calling the alteration "decoration" in one place but
 > "corruption" in the other.
 >  
 > Loading the language in such a way is asking for a given conclusion
 > even before the debate has started. That's not fair (I'm not
 > predicating that from you, Matt, just talking in general terms).

What Yahoo! did wasn't fair, either.  I'm just responding in kind,
partly because some people define "legitimate" as "conforming to
standard" so "legitimate alteration" vs. "illegitimate alteration"
doesn't convey the same meaning.

Anyway, I intend to continue using "corruption" vs. "decoration"[1]
because I believe that they convey exactly the nuances I want.  Not
merely "unwelcome" vs. "welcome", but a corrupt From: breaks both the
user's model of email and RFC 5322 semantics, while a decorated
subject or footer breaks neither.  (Decoration can break DKIM and PGP,
however.  The practice of decorating list posts long precedes
signature technology, though, so I consider that to be a defect in the
signature protocols, or at least their common implementations.[2]
IMHO YMMV, there.)

Footnotes: 
[1]  I don't claim to be the originator of either terminology, but I'm
definitely using them consciously.

[2]  PGP can be worked around by placing the signed body in a separate
MIME part from the header and/or footer parts, and DKIM could at least
be adapted to decorated subjects using z= and footers using l=,
although this would require MUA support to be at all realistic (and if
John Levine's most pessimistic assessment of typical users' ability to
interpret MUA signals is correct, these workarounds are too dangerous
to be used).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jun 2014 21:50:29 -0700

> interpret MUA signals is correct, these workarounds are too dangerous

The use of z= to get a "secondary" validation of an originator's signature
makes me uneasy.  A failed signature is supposed to fail.  If one wishes to
allow Subject: field alterations, then don't sign it.  (I would rather
abolish the practice of Subject tagging altogether and use the List-*
fields to identify and sort list posts, but I am fully aware it's me vs.
deployed inertia there.)

Back in the DKIM WG days, that was also the consensus position as I
recall.  We also didn't expect MUAs to show which header fields or what
part of the body were covered by a signature; the output of DKIM signature
validation is just pass/fail and a domain name.  Moreover, give a message
with multiple signatures that passed yet covered different stuff, what
could an MUA do that wouldn't be utterly confusing to users?

I think back then someone suggested a modified header canonicalization
method that was the same as "relaxed" except that a single limited-size
token surrounded by square brackets and followed by a couple of whitespaces
at most would be omitted from the hash, which would mean Subject tagging
doesn't invalidate anything.  It was rejected, but I can't remember why off
the top of my head, maybe something to do with the fact that the unmodified
Subject field could also start the same way, so it's ambiguous.  Either
way, to do it now would mean touching every deployed DKIM signer/validator
out there.

Finally, in addition to DKIM-Delegate, I posted another draft that captures
a MIME-sensitive body canonicalization proposal that was suggested some
time ago by Ned Freed.  It may or may not be interesting for this effort.
It's here:

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 15:16:42 +0900

Murray S. Kucherawy writes:
 > makes me uneasy.  A failed signature is supposed to fail.

I'm not proposing additional validation.  As I've said before, I have
no quarrel with the DMARC protocol or its component protocols (at
least I've not found a reason to dislike it yet), although I strongly
dislike Yahoo!'s policy use of "p=reject".

I'm suggesting the information could be used in the MUA UI.  A failed
signature *would* fail.  Consider the following scenario:

(1) User posts, MTA DKIM-signs using DKIM-delegate protocol (main
    signature signs Subject and body, delegate signature does not).
(2) Mailing list decorates Subject, MTA DKIM-signs all the usual
    fields and body, and distributes.
(3) Recipient MTA notes failure of main originator signature but
    accepts according to local policy about DKIM-delegate and valid ML
    signature, ignoring z=.

Isn't that OK?  Now

(4) Recipient MUA has a choice of
    (a) Displaying decorated Subject verbatim.
    (b) Displaying z= Subject verbatim.
    (c) Matching decorated and z= subjects, and discarding mismatched
        portions.
    (d) As (c), but demphasizing mismatched decorations (eg,
        grey-on-grey).
    (e) Something else.

I'm suggesting something along the lines of (b), (c), or (d).  If the
MUA does (a), it just falls into the abuser's trap, of course.  But
that's exactly what would happen now if somebody found a way to suborn
dkim-delegate.

 > recall.  We also didn't expect MUAs to show which header fields or
 > what part of the body were covered by a signature;

Agreed, we cannot expect help from current MUA versions.

 > the output of DKIM signature validation is just pass/fail and a
 > domain name.  Moreover, give a message with multiple signatures
 > that passed yet covered different stuff, what could an MUA do that
 > wouldn't be utterly confusing to users?

Dunno.  I like (4)(d), but I wouldn't be surprised if everybody else
hates it.

But the situation has changed.  What could be more confusing than mail
that falls into a black hole because of "p=reject"?  People are losing
money over this, you know.  Suddenly better MUA handling of security
information may be a competitive advantage or something to puff your
chest over.

 > doesn't invalidate anything.

Yuck.  It would work, I guess, but I've seen mailing lists that remove
existing prefixes (Re:, Fwd:) and I can imagine one that removes
"was:" clauses.  And that doesn't help with the footer, anyway.

 > Finally, in addition to DKIM-Delegate, I posted another draft that
 > captures a MIME-sensitive body canonicalization proposal that was
 > suggested some time ago by Ned Freed.  It may or may not be
 > interesting for this effort.  It's here:
 > 

Day job has caught up with me, I'll have to read that later.  I'm
making a bet with myself on how far it is from current Mailman
behavior. :-)  Thanks for the URL!

---

From: Vlatko Salaj <[email-masked]>
Date: Mon, 9 Jun 2014 23:37:20 -0700 (PDT)

On Tuesday, June 10, 2014 6:50 AM, Murray S. Kucherawy <[email-masked]> wrote:

the master-piece of DKIM messiness. unfortunately,
it doesn't solve current ML problem, but introduces
new ML requirements.

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2014 08:46:12 +0200

On 6/10/2014 8:16 AM, Stephen J. Turnbull wrote:
> I'm suggesting the information could be used in the MUA UI. 
...
> I'm suggesting something along the lines of (b), (c), or (d). 

So now I get to demonstrate that I am an equal-opportunity MUA UI
guidance critic:

   The premise of your proposal is that users will notice that there's
extra information, know what to do with it, and do the right thing, with
reasonable consistency.

Each of those conditionals will not actually be satisfied.  User's tend
not to notice such things.  The tend not to understand what they mean.
Even when they understand, they tend to evaluate choices poorly.  They
tend to apply choices inconsistently.

Everything gets much easier if we specify guidance for filtering
engines, before humans come into the picture.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2014 08:49:23 +0200

> it doesn't solve current ML problem, but introduces

On the average, technical discussion is facilitated by technical
substance.   That is, criticism that involves technical details.

On the average technical discussion is not aided very much by summary
judgements of personal opinions about technology.

So rather than offer dismissive, summary comments, please offer
criticisms of technical substance.

d/

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 00:11:51 -0700 (PDT)

On Tuesday, June 10, 2014 8:49 AM, Dave Crocker <[email-masked]> wrote:

> So rather than offer dismissive, summary comments,
> please offer criticisms of technical substance.

i would rather not waste time on elaborate thesis
about YADA [yet another DKIM addon]. someone who has
time will do it and they can add my vote apriori.

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2014 09:16:57 +0200

> time will do it and they can add my vote apriori.

I'm a bit confused.

You think it is ok to waste everyone's time by offering your personal,
summary-dismissal notes, but not substantive criticism?

An example of why postings like you've sent are unhelpful is that it
implicitly invites others to offer summarily-dismissive notes about your
notes.

There's nothing productive about such a path.

d/

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 00:41:36 -0700 (PDT)

On Tuesday, June 10, 2014 9:18 AM, Dave Crocker <[email-masked]> wrote:

>>>> [it] introduces new ML requirements.
> You think it is ok to waste everyone's time by
> offering your personal, summary-dismissal notes,
> but not substantive criticism?

depends how u define substantive criticism.
i DID say: "it introduces new ML requirements".

"introducing new ML requirements" has already been
characterised as not an ML solution. we have a few
of them already, and all much simpler than any YADAs.

> An example of why postings like you've
> sent are unhelpful is that it implicitly
> invites others to offer summarily-dismissive
> notes about your notes.

walk what u preach then and don't do it.
sometimes ignoring is the best approach.
i'm not looking to find ur approval, but
those who stand on the same viewpoint as i do.

> There's nothing productive about such a path.

there's also nothing productive in *personal* thinking
that DKIM is a holy grail of authorization,
and based on that *personal* motivation, sponging endless
YADAs [aka yet another DKIM addons], wasting urs
and our time in process.

yet u do it. so i do it, and we r here, doing this.
nothing new. it's just who we r.

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

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 18:22:25 +0900

Dave Crocker writes:

 > extra information, know what to do with it, and do the right thing,
 > with reasonable consistency.

Yes, yes, yes, and yes.

 > Each of those conditionals will not actually be satisfied.  User's
 > tend not to notice such things.  The tend not to understand what
 > they mean.  Even when they understand, they tend to evaluate
 > choices poorly.  They tend to apply choices inconsistently.

Yes, yes, yes, and yes (all modulo "are we letting 'perfect' be the
enemy of 'better'?" -- you have a *really* dim view of the average
users' capabilities!)

 > engines, before humans come into the picture.

But now you are assuming filters that are very close to 100% accurate!
Do you really think we can get there?  I don't, because we already see
Yahoo! Groups arranging that *humans* can see yahoo.com mailboxes in
From: even though DKIM can't!  If that isn't going to provide an
opportunity for phishers and spammers, why are we doing DMARC in the
first place?

Similarly, several posters have already objected that DKIM-delegate is
subject to replay attacks.  I personally think DKIM-delegate is more
likely to get adopted than (say) TPA-labels, and even if both succeed,
DKIM-delegate is likely to be adopted and implemented more quickly
because it's much simpler.

Anyway, I'm assuming we've done the best we can at filtering at the
"missing link" stage.  In the scenarios I'm talking about, the message
has already gotten through the filtering engines.  Maybe it's in
quarantine, and maybe nobody except me even looks in spam folders.
But what if they do?

I conclude that we should consider trying to enlist the MUA devs for
"defense in depth."

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Jun 2014 06:57:32 -0400

> dislike Yahoo!'s policy use of "p=reject".

Are you oppose to any other domain using strong policies or just 
certain ones?  In other words, would you honor the p=reject for other 
domains, just not Yahoo's?

You didn't answer the question in another post regarding if you are 
even ready or support the idea of even doing a DNS lookup to find out 
what a domain's policy is?

>      accepts according to local policy about DKIM-delegate and valid ML

It is more easier, more feasible, more safe, to just reject/discard 
the failed message (due to policy) at the backend and be done with it.

> that's exactly what would happen now if somebody found a way to suborn

Do you realize how many different MUAs exist? and the different forms 
of MUAs?  Why pass the buck to the user when the backend can deal with 
this and its works for all MUAs!!

This is like assuming there is only GNU mailman out there. Even then, 
are you going to make the changes to your VM editor?

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Jun 2014 07:27:10 -0400

...
> enemy of 'better'?" -- you have a *really* dim view of the average

I think Dave's dim view is pretty much accurate, though I can't show
that in any concrete way.  But the more important point is that you're
presupposing that the changes are "better", and my contention is that
we don't know enough about UI design and user experience to say that.
To people like you and me, it's clear that giving more information --
and especially such important information as this! -- is better.  But
that's not really true, and even information that we think is
essential... is actually confusing to non-technical users.

Here I can cite studies; I have one that looked at browser cues such
as the lock symbol, and found that users so misunderstand the lock
symbol that they (1) think a lock symbol on the web page itself is
*better* than one in the browser frame (that's quite backward), (2)
don't know what the lock symbol is telling them *at all*, and have
various cockamamie ideas about what it means, and so on.

We have to be very careful about such changes, and not assume that we
know what's better.

Barry

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Jun 2014 08:49:56 -0400

On 6/10/2014 7:27 AM, Barry Leiba wrote:
> that in any concrete way.

There are a set of "User Expectations" and the backend has a strong 
influence on satisfying the "user expectations."   The three that the 
US EPCA molded in 1986 are:

     - Don't make private mail, public
     - Don't censor the mail,
     - Don't tamper the mail.

This has been relaxed over the years to a, I kid you not, to the "Good 
Samaritan" provision which gives the backend more legal indemnifying 
controls and it make it fit better the existing 150+ year old 
exceptions provided to the newspaper industry which allows the 
newspaper editor to alter the "letter to the editor" for "fit to 
print" reasons.

> But the more important point is that you're

We do. But we are adding so much doubt to it, the promotion is to just 
pass everything to the user or do all the work at the client side. 
Thats is the OLD WAY when thats all the mail routers/receivers did, 
transport, send and receive and did no filtering whatsoever.

So what we are battling with is what work and where is the client or 
server work done?

> and especially such important information as this! -- is better.

Not always. System level considerations are a high consideration. 
Just reject and forget about it. All empirical data tells you that 
this is very feasible, reliable with an extremely low false positive 
rate, and for the exceptions, its going to be a hard pain to shallow. 
  The LSP can no longer exist in a wild wild west world of 
"unrestricted" mail processing.

The LSP needs to adjust.

Note, I am not trying to change the subject away from the MUA UI. But 
this will always be a position that end-users, administrators will 
like to impose that have no control over the system level operations, 
the MSA, MTA, MDAs, etc.  There are MUA considerations for sure, but 
we need to focus on the DMARC policy issues, or lack of them, that is 
causing such a high conflict between operations.  We can't solve it 
with MUA stuff.

  But
> essential... is actually confusing to non-technical users.

+1.

> We have to be very careful about such changes, and not assume that we

and to add to this, how about satisfying visual impaired requirements? 
  Too much?  My first 1980's MUA (Silver Xpress Offline Mail System) 
was the first to support what I called "Speech Friendly Interface" or 
SFI that dealt with the  MAIL-READY navigation for speech.  It 
supported special on-board cards such as "Vocal Eyes" and "Windows 
Eyes" (https://www.gwmicro.com/Catalog/Window-Eyes/)   Visual cues 
needs to be translated to speech signals too.  Today, there are 
current W3C proposed standards/methods (web-base, CSS, etc) to satisfy 
"SFI" requirements.  Quick reference before I have to leave for now....

http://www.w3.org/standards/webdesign/accessibility

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 22:33:16 +0900

Barry Leiba writes:

 > But the more important point is that you're presupposing that the
 > changes are "better",

Yes and no.  Obviously, if it is impossible to improve the MUAs,
there's no point in discussing it.  In that sense, I have to presume
that improvements exist.  That doesn't mean I assume I know what they
are, or that any of the examples I gave are better.

On the Mailman lists today, one postmaster posted that he is observing
a surge in AOL-spoofing phishing this week, with AOL screen names in
the display name and some other address as the actual From: mailbox.
The abusers seem to have access to contact lists, as often the
addressee is acquainted with the AOL screen name.  I don't see how
DMARC can help deal with that -- unless it cooperates with the MUA.

Although writing MUAs is not what this list is about, I think we
*should* think about what information we *can* make available to the
MUA that may be useful in addressing such attacks, ask the MUA authors
what information they could use, and write protocols that make useful
authentication information available to the MUAs conveniently, to
present to the users in appropriate ways as the MUA devs see it.

 > We have to be very careful about such changes,

*We* can't make any changes in the MUAs, and there are few, if any,
MUA devs here to be misled by our mistakes.  Such speculation may be a
waste of our time, but no worse than that.

 > and not assume that we know what's better.

I don't.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 22:55:48 +0900

Hector Santos writes:

 > certain ones?

Domains where users have until now felt free to use their mailboxes as
they see fit (posting to mailing lists, as From: in on-behalf-of
services, etc) should not suddenly impose "p=reject" IMO.

 > even ready or support the idea of even doing a DNS lookup to find
 > out what a domain's policy is?

I have stated several times that I have no quarrel with DMARC as is,
that I think it is a good protocol overall, and that in particular
"p=reject" is useful in "transactional" contexts.  It is a logical
consequence that I support the idea of a lookup to discover policy.

 > the failed message (due to policy) at the backend and be done with it.

In your opinion.  In my experience, many postmasters resist that
policy.

 > of MUAs?

I haven't counted.  How many are there?

 > Why pass the buck to the user when the backend can deal with this
 > and its works for all MUAs!!

Because the backend can't deal with it, except by imposing draconian
policies that I know many sysadmins really want to avoid.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 07:00:41 -0700

> of them already, and all much simpler than any YADAs.

The person on this list that actually represents a mailing list so far
seems to like the idea, and has explained why to some extent.  I think
that's much more valuable feedback.

A proposal like this one might introduce new requirements, sure, but if
they solve a huge problem and people are willing to implement it, then so
what?  They're worth the work in that case.

My understanding of the constraint is that we need to avoid new
requirements that affect common mailing list practices, like footers and
Subject field tagging.  DKIM-Delegate establishes a requirement that
mailing lists sign the modified message in full.  In a lot of cases, list
software does that already; often it's the case that other software even
does that for them, so how much of a burden is this really?

The burden is actually on signers (who need to add DKIM-Delegate fields)
and on verifiers (who need to look for them and know what to do with them),
not on the lists themselves.

Or do you mean something else when you say "new ML requirements"?

> > invites others to offer summarily-dismissive

Speaking personally, I usually ignore the summarily-dismissive notes
because I don't learn anything from them.  The more well-developed
criticisms are the valuable ones.

> YADAs [aka yet another DKIM addons], wasting urs

This is drifting toward the ad hominem again.  Careful, please.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Jun 2014 09:07:15 -0500 (CDT)

----- Original Message -----
> From: "Stephen J. Turnbull" <[email-masked]>
> To: "Barry Leiba" <[email-masked]>
> Cc: "Dave Crocker" <[email-masked]>, [email-masked]
> Sent: Tuesday, June 10, 2014 3:33:16 PM
> Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.
> 
> Barry Leiba writes:
> 
We know that the display name abuse is something that need to be tackled. We should not recommend to put anything that looks like a domain name in the display part, cause eventually we will put a rule to dump emails with such property.

I think also, MTA have become more strict, they know expect one and one only From header, with a Date header, and a few extra... to follow more strictly the RFCs.

DMARC do not talk about invalid messages, because they should not even make it to DMARC evaluation in the first instance.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2014 16:08:56 +0200

> But now you are assuming filters that are very close to 100% accurate!

No.

I am assuming that working with filtering engines is better than trying
to work with 1-3 billion end users.

There is quite a good track record of working with filtering engines.
There is quite a poor track record of working with end users.

> Do you really think we can get there? 

We are already there.  SPF and DKIM and DMARC are examples of working
with the filtering engine.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2014 16:15:23 +0200

>> enemy of 'better'?" -- you have a *really* dim view of the average

Actually I have a pretty typical view, relative to folks who have to
direct experience with human factors, UI/UX, cognitive, memory and
attention models, and the like.  And as I said, I made a point of
testing my summary judgement with a group of real experts, last summer.

My preference is to do design that accepts the realities of the
operational context for the design.

So, for example, a design that makes inappropriate demands on end users
will fail.

Humans are erratic in paying attention.  Humans are typically quite poor
at understanding computer security models.  Humans are inconsistent in
making decisions during real-time interactions.

etc., etc.

To repeat, my comments on this are not in the least controversial
amongst folk who study such things.

d/

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 08:12:43 -0700 (PDT)

> Or do you mean something else when you say "new ML requirements"?

i wasn't talking about DKIM-Delegate, nor is this its thread,
so, while i will get to ur arguments in DKIM-D thread, they miss
the point here.

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

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 11 Jun 2014 00:55:37 +0900

> to work with 1-3 billion end users.

That's a pretty stiff requirement.  I'd be satisfied if a simple
indicator, e.g. based on parsing Authentication-Results, saved 1-3 end
users from a phishing attack.

But since I don't have a plan for dealing with at least a billion end
users, I guess I should go find another venue.  No problem. :-)

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Jun 2014 12:19:13 -0400

On 6/10/2014 10:00 AM, Murray S. Kucherawy wrote:
> On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj
> <[email-masked] <mailto:[email-masked]>> wrote:
>

More valuable than other feedback?

There are also other full time  mail professional folks on this list, 
active, lurkers or otherwise, that are very much involved with not 
only the development and production of Mailing List Software (MLS) but 
include also actually using their own tools for the business and 
support process.  Regardless of size, they all have to work the same 
with the basic protocol "list" mechanics with the minimum functional 
expectations and requirements to get the job done.  While volume helps 
to highlight where the potential weak points may be and this is always 
desirable, they are weak points nonetheless at all levels.

> A proposal like this one might introduce new requirements, sure, but
> if they solve a huge problem and people are willing to implement it,
> then so what?  They're worth the work in that case.

We do need to extract them, talk about them, but there are certain 
ones that simply do not apply -- they are show stoppers, a "waste of 
time," not a "global common" with cooperative competition in mind 
among all parties.  I think we identified a few of these already.

> requirements that affect common mailing list practices, like footers
> and Subject field tagging.

Whatever are the design constraints, the algorithms, the automation, 
it needs to include all the factors and that includes author domain 
policies, as in the case with DMARC with no LSP (list service 
provider) authorization provisions.

The point is that, until they were available (endorsed and 
championed), we won't have the full field testing experience of what 
is possible or not, or how the LSP will adapt.  Right now, they are 
crippled because of the lack of 3rd party signing semantics or 
capabilities. So the LSP are thinking of "radical" methods to bypass 
the security. That is not the solution to this.

We need to have all the parameters available in the mail process 
environment to see the entire framework in action with two-way 
reversible, verification methods.   The DKIM-Delegate suggestion is 
more complex when it comes to code change, more complex than just 
doing a simple DNS lookup and honoring the policies.  When ignored, 
eventually problems occur as it did happen now with higher volume 
impact players enabling the technology.  The problem was always there. 
LSP are just feeling the pains of their early ignorance of the 
technology.

> DKIM-Delegate establishes a requirement
> that mailing lists sign the modified message in full.

Where would the requirement be established?  Is it a policy lookup or 
just the presences of the header signifies a higher level of 
expectations?  This is a change for multiple mail software components 
so it needs to justify why this change is better than just doing a DNS 
lookup and processing the policy.  Of course, without 3rd party 
semantics available, all the LSP can do is fit the 1st party policy 
model by denying subscription/submissions from restrictive domains. 
But certain LSPs do not want to do this even at this simpler level. 
How do you stop this with DKIM-Delegate when the header is missing? 
Is this a short circuit optimizer?

   If DKIM-Delegate is not present then do
      Author Domain Lookup

What changes are the LSP willing to accept?

You know, back in 2005/2006, I remember a good idea conversation when 
Jim Fenton shortly before the ASDP post-XMAS holiday surprise. 
Again, using the rule above, we wanted to reduce the need to do a 
lookup by passing policy information in the signature itself, 
something like this, applied to DMARC today, it may look like:

    DKIM-Signature: d=example.com policy=reject

We concluded that would be an optimizer for the exclusive strong 
reject/quarantine policies since no one would do this if it was 
possible to reject it.   Its possible to do the same thing with 
DKIM-Delegage of passing the policy via this header.  But if its said, 
p=none, and the actual policy was reject, it means a check is needed 
anyway.   So the rule would be now:

   If DKIM-Delegate is not present
      or
      DKIM-Delegate.p is not reject or quarantine
   then do
      Author Domain Lookup?

> In a lot of cases, list software does that already; often it's
> the case that other software even does that for them, so how
>much of a burden is this really?

I am not sure what you mean about this, detecting a list processed 
message?

> The burden is actually on signers (who need to add DKIM-Delegate
> fields) and on verifiers (who need to look for them and know what to
> do with them), not on the lists themselves.

Right, a change is required. So why not just a lookup?  A lookup 
eliminates the need for additional complex mail header processing ideas.

Do you believe DKIM-delegate reduces the need to do a lookup while 
still satisfying all author domain related security requirements?  Can 
bad guys use the DKIM-Delegate to bypass non-list related mail in an 
attempt to show a valid 3rd party signer?  Or is DKIM-Delegate just a 
means to dynamically scale authorized 3rd party signer?

I am just wondering how do you verify it and avoid the fraudulent 
facsimiles of such DKIM-Delegate stamped messages.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 10:31:15 -0700

On Tue, Jun 10, 2014 at 9:19 AM, Hector Santos <[email-masked]> wrote:

> [...]

Feedback that shows insight and detail is useful.  Feedback that says "Your
idea won't work" without details explaining why is mostly useless, and thus
easy to ignore.  It doesn't matter to me who says it, it's quality of the
comment that matters.

> We do need to extract them, talk about them, but there are certain ones
> that simply do not apply -- they are show stoppers, a "waste of time," not
> a "global common" with cooperative competition in mind among all parties.
>  I think we identified a few of these already.

Yes indeed.

> environment to see the entire framework in action with two-way reversible,
> verification methods.   The DKIM-Delegate suggestion is more complex when
> it comes to code change, more complex than just doing a simple DNS lookup
> and honoring the policies.  When ignored, eventually problems occur as it
> did happen now with higher volume impact players enabling the technology.
>  The problem was always there. LSP are just feeling the pains of their
> early ignorance of the technology.
>

I don't agree that DNS is a cheaper solution than a handful of comparisons
of strings you already have locally.

> Where would the requirement be established?  Is it a policy lookup or just
> the presences of the header signifies a higher level of expectations?
>

As it says in the draft, it's presence of the header field that matters.

> This is a change for multiple mail software components so it needs to
> justify why this change is better than just doing a DNS lookup and
> processing the policy.

In fact, one of the specific benefits of DKIM-Delegate over ATPS and
TPA-Labels and any sort of whitelisting scheme is that there is no DNS
lookup.

> I am not sure what you mean about this, detecting a list processed message?

No.  I'm saying MLMs already seem to sign the mail, either by doing it
themselves or because outbound mail is automatically signed anyway.

> eliminates the need for additional complex mail header processing ideas.

It also introduces additional latency and you have to deal with timeouts.
String comparisons are much cheaper.

>
> Do you believe DKIM-delegate reduces the need to do a lookup while still
> satisfying all author domain related security requirements?  Can bad guys
> use the DKIM-Delegate to bypass non-list related mail in an attempt to show
> a valid 3rd party signer?  Or is DKIM-Delegate just a means to dynamically
> scale authorized 3rd party signer?
>

In order:

Yes, that's what the proposal suggests.  It might be right or wrong; that's
what we need to determine somehow.

Yes, that's a risk, and it's acknowledged in the draft already.  The
question is whether that risk is worth the gain.

Yes.

Nobody says the proposal is final as-is.  Useful feedback is welcome.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 10 Jun 2014 17:37:00 +0000

> operational context for the design.

Dave,

Do you have any links to articles on UX design and things like this? I've seen a couple of conference presentations over the years about UX design and security, but I'd be interested in learning more about it. 

-- Terry

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 9 Jun 2014 06:33:46 -0400

> modern protocol world is JSON/REST

Let's not be so quick to dismiss NNTP: it's a more elegant weapon from
a more civilized age. ;)  It has long since proven itself to be very robust
under adverse conditions, which once upon a time might have been defined
as "very slow network transport plagued with serious lag and frequent
disconnects" and might now be defined as "network transport being actively
interfered with for commercial or political reasons".  (And I think it's
worth noting that Usenet traffic can still propagate quite nicely via
sneakernet, a seriously useful feature in certain locales.  Not everyone
is so fortunate and wealthy as to enjoy high-speed IP connectivity free
of tampering, throttling and DPI.)

But that's not really relevant here.  The flooding propagation model of
Usenet is quite different from the model used by mailing lists.  (And if
something like DMARC were used there, it would limit article propagation
from users at example.com to example.com's immediately-adjacent
neighbors only, clearly not a desirable property.)

---rsk

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Jun 2014 08:14:27 -0400

> Its better to get this bud nipped now.

Yes, always best to act before thinking about the problem

Always best to make sure that the group considers only the problem it
is allowed to consider.

How can the IETF be a consensus organization if people are allowed to
block consideration of alternatives?

My understanding of the remit of this group is to consider what to do
about the DMARC situation.

The reason I proposed looking at changing the mailing list scheme is
that the DMARC 'discussion' consists of one group of folk saying 'we
have to stop this' and another pointing out that it has already
happened.

Most Internet users do not care whether mailing lists work or not. So
expecting them to accept tons of spam from criminals trying to cheat
them to preserve the equivalent of vinyl records is not going to
succeed. The Internet does not have a rule that the people who got
here first make the rules. There is a traffic jam in Cambridge/Boston
several times a day as the lifting bridge opens to let some plutocrat
sail his yacht through at rush hour. Several thousand people have to
wait half an hour to get to work for one person to enjoy their hobby.
I think that is a rotten and selfish way to run things.

So given the fact that DMARC is causing problems for mailing lists we
should not automatically assume that the solution is to change DMARC.

I think that this point is completely on topic for a pre-WG list that
is discussing ways to address a problem. Chances are that the
conclusion is going to be that NO DMARC WG is formed because the
people using DMARC are not interested in the changes that are going to
be proposed.

Mailing lists are not an optimal solution. They have high
administrative burdens, the mail they send is often caught in spam
filters because a mailing list is a bulk sender. These problems were
recognized when NNTP was designed. Though as Dave Crocker points out,
flood filling is hardly an approach we should endorse for the modern
Internet.

But given that we have the attention of Google and Yahoo here we do
have the critical mass that could make a major change in mailing list
technology stick. And it is to their interest to do so.

So I am not just proposing a better solution, I am proposing a
solution that has more chance of being adopted. Though since 'shut
DMARC down because we says to' is not going happen pretty much
anything has a better chance of deployment.

> From-Corruption concept would be a security exploit that can potentially get
> by RFC5322 validation checks that can hurt DMARC publishers and create bad
> PR for the DMARC protocol itself.  DMARC receivers will need to be warned.
>
> You may want to make it a boundary layer check thing. The exploit will need
> to be described just like it was done for DKIM's Double From situation with
> RFC5322 validation checks done at receivers.
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Jun 2014 14:20:18 -0400

> services, etc) should not suddenly impose "p=reject" IMO.

Right and so has the world of no-authentication required port 25, 
local recipient transactions where massive abuse has occurred world 
wide.

The LSP, the bulk mailers, was among the tools used by the "bad guys." 
  Millions of aged domains have been spam polluted, including 
Yahoo.com, etc.  It is everyone's problem. I hope you agree.

It was time for a change, and it started in 2003 with SPF and soon 
with DKIM+ADSP.  Forward into time, ADSP was replaced with DMARC. 
LSP were warned.

> consequence that I support the idea of a lookup to discover policy.

Will you implement it?  You need to implement it as part of the LSP 
integration. Because if you are not, I need to stop writing to you 
trying to convince you. :)

> In your opinion.

It is the expert opinion of million of IETF-MAN-HOURS and SMTP systems 
that have long implemented and deployed 4yz/5yz client/server response 
system and state  machine. That includes my expert opinion.  Its the 
expert opinion of systems that have deployed strong system level 
rejection methods, among them SPF, DNSRBL and now DMARC.   I 
understand you are a LSP.  DMARC effects you differently, but we can't 
throw out the proverbial baby.

> In my experience, many postmasters resist that policy.

Software developers provide the postmasters the option to 
reject/accept mail.  So whether it is many or not, it is pointless. 
The demand is high to deploy system level rejections for older and 
newer policy reasons.

> I haven't counted.  How many are there?

Lots, too long to list.  Its not about my stuff but everyones you have 
to work with. I have number of MUAs of my own for our own system.  For 
tech support, we have different mail access portals:

   web: http://www.winserver.com
   telnet:  telnet://bbs.winserver.com
   nntp: news://publicnews.winserver.com
   smtp/pop3: mail.winserver.com
   GUI: http://www.winserver.com/public/wcnavigator.wct

plus a few internal Sysop Editor/Management/Watchdog tools.

How can I single source your ideas for each of these MUA? The web side 
is a big concentration these days.  So do we just deal with that?  Do 
I forget the rest?  I can apply the single source logic at the backend 
and it applies to all MUAs, the user using his favorite mail portal is 
secured against abuse.

Is this practical business expert "opinion" acceptable?

> Because the backend can't deal with it,

But it does and it works very well. If the backend software can't, 
then who? The user software?

Software is software, why not the software at the backend?   Do you 
wish to make this a USER defined policy where he can teach the backend 
because his frontend software is not capable of doing this?

I'm cool with that, so what are the defaults?   Maybe you can add user 
options like:

   [X] I want to reject mail from unauthorized DMARC sites.

Will you provide it to them or is it too "Draconian" for them to have 
available?

>except by imposing draconian

Well, it pointless to say "many" because what the "many" is really 
suffering from is the lack of options with the DMARC protocol.  It is 
missing LSP provisions and once that happens then you will have your 
tools to adjust gracefully.   But you have to agree the LSP needs to 
do the lookup or its frontend receiver has to do the lookup and be 
aware of the ML part, i.e. acceptable list addresses.

Stephen, I do believe that it is "Bad Policy" to be promoting a 
concept of ignoring new growing policy protocols.  It isn't going to 
help in the long run. DMARC is here. It isn't going to go away.  Sure, 
its my opinion and I like to think I am more right than wrong. :)

-- 
HLS

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 11:28:02 -0700 (PDT)

On Tuesday, June 10, 2014 8:01 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> There is a traffic jam in Cambridge/Boston

> Chances are that the

i just love this, i had to comment.

Phillip goes about a story of a bridge and rich, selfish ppl disallowing
thousands of workers, and then he mentions how rich [read selfish] corporations
don't wanna change DMARC and thus go on affecting thousands of domains...

and he doesn't realize the paralel.

> should not automatically assume that the solution is to change DMARC.

DMARC is causing problems for many things, not just mailing lists.
otherwise we wouldn't be having 3rd party alignment support
proposals. yet we have 3 of them.

and it's just beginning.

> Though since 'shut

well, since we don't have an oracle to ask what will happen to
DMARC, i'll rather leave all options open.

however, i'm sure not gonna subscribe to this bullying, rich
corporation tactic: "we will do what we want, and u can't stop us".

either a protocol is for all the ppl, or abandoned by ppl.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 11:43:31 -0700

On Tue, Jun 10, 2014 at 11:20 AM, Hector Santos <[email-masked]> wrote:

> system and state  machine. That includes my expert opinion.  Its the expert
> opinion of systems that have deployed strong system level rejection
> methods, among them SPF, DNSRBL and now DMARC.   I understand you are a
> LSP.  DMARC effects you differently, but we can't throw out the proverbial
> baby.

That's colorful, but not automatically true.  There's plenty of other
expert opinion (and, to date, consensus) to suggest that it's not a
universal truth.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 11 Jun 2014 04:00:57 +0900

> LSP are just feeling the pains of their early ignorance of the 

That, sir, is false, both as to fact and as to causality.

The LSPs were not "ignorant" of DMARC or its component technologies --
e.g., Mailman already had mitigations (courtesy of Franck Martin) in
v2.1.16 released in Oct. 2013.  Nor was the state of LSP knowledge
relevant to the pain.  Once Yahoo! published "p=reject" pain was
inevitable because the authentication technology makes no allowance
for Mediators.  The choice was among different varieties of pain, but
no amount of preparation would have made the pain avoidable.

Regards

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 12:16:16 -0700 (PDT)

On Tuesday, June 10, 2014 9:01 PM, Stephen J. Turnbull <[email-masked]> wrote:

> The choice was among different varieties of pain, but

that's a completely wrong assumption. they all knew DMARC doesn't
work for any case where 3rd party is involved. document even says so.

however, they decided it's not their problem, and instead
of solving it, they just ignored it, cause no rich corporation
is using 3rd party services anyway.

and thus, early ignorance brought us here where we have DMARC
on non-IETF path, where we r bitching about mailing lists and
where we have 3 different 3rd party proposals.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Jun 2014 15:09:05 -0400

> and he doesn't realize the paralel.

No it is you who don't see the parallel. Google and Yahoo's position
here is analogous to that of the MBTA, they are one entity with a lot
of money but they are acting for the benefit of thousands.

Meanwhile we have a bunch of privileged Internet early adopters who
think that the rest of the world should revolve around them.

The number of people using Yahoo/Google is over a billion. The number
of people being inconvenienced by DMARC more than they spend effort on
complaining about it is likely to be zero.

The issue here is not that the yacht owner is rich, it is that there
is one person able to inconvenience thousands by citing a precedent.

> proposals. yet we have 3 of them.

Yes, its not just SMTP that is going to be extended with as policy
layer. Every Internet protocol will be covered by one.

Back in the day I was the only person saying that NAT was the
deployment mechanism for IPv6, not something to be deliberately
sabotaged because it does not meet some IETF dogma.

I was right then and I am right on this one. DMARC is the right way to
do email. It is over done, deployed. The only question that is left
for the IETF now is whether to fix any damage it might have caused and
if so, how.

> DMARC, i'll rather leave all options open.

When was the last time I was wrong on something like this? It is
possible that Google and Yahoo might retreat but I can't see why they
would.

> corporation tactic: "we will do what we want, and u can't stop us".

You don't understand the Internet then.

All that makes the Internet different is that everyone has that same
exit option. The only sine qua non of the Internet is that networks
communicated via IP. That is a strict rule but it is the only rule.
Everything else is on the table and anyone who wants to do something
different can.

And there is nobody to go to to ask permission.

The Internet is an empowerment technology. Or at least it is since the
Web reworked it. The goal of the Web was to put publication
capabilities in the hands of everyone so it wouldn't just be Rupert
Murdoch who could decide what was news.

We don't have rules, we have conventions and standards. But anyone who
does not like those standards is always free to rip them up and do
something else. This is not a decision making body.

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 12:32:10 -0700 (PDT)

On Tuesday, June 10, 2014 9:09 PM, Phillip Hallam-Baker <[email-masked]> wrote:

unfortunately, Phillip, there's no hope for us
to agree on these things.

everything u say seems so double-faced and cynical,
it's beyond my best hope to comply.

nothing personal ofc.

simply cause i majored both philosophy and computer sciences,
and beside being an IT pro, i'm also a human rights
activist, i just can't participate in this
kind of viewpoint of anything, yet alone internet.

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

---

From: "M. Hammer" <[email-masked]>
Date: Tue, 10 Jun 2014 15:36:29 -0400

> work for any case where 3rd party is involved. document even says so.

As someone who has been involved in this space for quite some time, 
Stephan's perspective is much closer to reality. I'll grant what the 
document says but I'll also point out that the expectation was that 
domains without end users (or tightly controlled end users) were the 
candidates for p=reject. Even proponents such as myself that the 
community is best served by MLMs adapting to email authentication 
practices were somewhat blindsided by the moves of large mailbox 
providers to implement p=reject. My personal expectation was that the 
issue would be forced as more enterprises and vendor dependent 
organizations had access to DMARC through their appliance/application 
vendors.

> is using 3rd party services anyway.
In this you are correct to a certain extent. It may be that the voices 
"representing" MLM developers/operators were not as representative as 
some thought. Personally I find Stephan's observations and comments 
thoughtful even if I do not necessarily agree with everything he writes. 
"Rich" corporations do use 3rd party services such as ESPs quite 
frequently.

> where we have 3 different 3rd party proposals.
Quite a few things brought us here where we have DMARC on a non-IETF 
path - mailing lists are only one item among a number of items. That is 
not to say that we will not find DMARC on an IETF path in the future. As 
the furor and tempest have declined and more thoughtful discussions have 
emerged, I'm personally encouraged that we collectively have an 
opportunity to find good (for some definition of good) approaches to the 
issues at hand, including getting DMARC on an IETF path.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 12:42:05 -0700

> work for any case where 3rd party is involved. document even says so.

I think you're talking about different "they"s here.  I believe Stephen is
talking about mailing list operators and software developers, while you're
talking about large ISPs.

> where we have 3 different 3rd party proposals.

Sorry, but that's not at all correct.  The reason DMARC is not (presently)
in the IETF stream has nothing to do with any of the above points.

-MSK

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 12:56:06 -0700 (PDT)

On Tuesday, June 10, 2014 9:42 PM, Murray S. Kucherawy <[email-masked]> wrote:

> The reason DMARC is not (presently) in the IETF stream has
> nothing to do with any of the above points.

u ppl keep repeating that. however, u never say what IS the reason.
why don't u enlighten us, then?

maybe we'll bitch less if we knew the truth, but considering it
has nothing to with it, i guess not.

however, maybe Hector won't go around making early threats,
which seem to injure many.

the story of my life... i'm always in minority, fighting for
survival.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 13:04:52 -0700

> why don't u enlighten us, then?

Instead of assuming the reason and thus making false accusations, you
could've asked for the details first.

> has nothing to with it, i guess not.

We couldn't come to agreement on the terms for a working group charter at
the time we tried.  The details are available in the archives of this list
if you want to go back and get more detail, but that's the basics of it.

I'm hoping we will try again so that there is a standards track version of
DMARC in the not-too-distant future, because I think just about everyone
believes that's a good idea.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 13:11:42 -0700

> the story of my life... i'm always in minority, fighting for
It is entirely possible to fight for the minority without acting this way.

It's unfortunate that you feel like your lifetime of frustration has to be
taken out on this list.  However, despite both public and private warnings
and a brief period of remission, I find you have decided to continue your
abrasive and non-constructive pattern of participation.

Under the procedure in BCP 94, and in coordination with my Area Directors,
your subscription to [email-masked] has now been placed under moderation
and will remain so until July 10th.  You may still post, but your postings
will be held and will not be approved unless they are both constructive and
on-topic.

You may appeal this decision to Barry Leiba and/or Pete Resnick if you wish.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 11 Jun 2014 05:21:44 +0900

Hector Santos writes:

 > integration.

What LSP integration?  DMARC is an agreement between Author Domains
and destination hosts.  Mediators are not party to it.  It's arguable
that the host MTA should be checking DMARC authentication and
alignment, but that's different from saying the list should.

 > throw out the proverbial baby.

I don't care what *you* do with your proverbial baby.  The point is
that *LSPs* are mostly not in a position to say "Fork off" to Yahoo! 
subscribers.  And subject tags, headers, footers, and removal of
bloated attachments are services that are very popular with users,
although these features break DKIM signatures.  Since we're going to
continue to provide those signature-breaking features, and lists are
not going to ban Yahoo! subscribers, the policies you propose are
simply not going to be used by a significant fraction of lists.

Instead they're going to corrupt "From:" or wrap messages "From:"
"p=reject" domains.  And just as there's not a damn thing you can do
to get Yahoo! to revert their policy to quarantine or none, there's
not a damn thing you can do stop lists from sidestepping DMARC.

 > The demand is high to deploy system level rejections for older and 

Not among Mailman list owners, it isn't.

 > Lots, too long to list.

I didn't need you to tell me that.  I was hoping for useful data.

 > Is this practical business expert "opinion" acceptable?

No.  You assert that you are an expert, you assert various things are
true or necessary, but you clearly lack understanding of the context
of mailing lists that makes MLM developers provide the mitigations we
do.  So your advice is not trustworthy, not for list operators.

 >    [X] I want to reject mail from unauthorized DMARC sites.

I have no idea what you're trying to get at.  What is an "unauthorized
DMARC site"?  Do we need to get permission to use DMARC?

 > Will you provide it to them or is it too "Draconian" for them to
 > have available?

Do you even understand the technology?  Lists are Mediators, they are
not party to DMARC, and they don't need to be to provide that option.
They just let the mail go through, and take care not to let the
bounces bounce subscribers into disablement or unsubscription.

Anyway, an expert like you should know that it's really inefficient to
have the list bounce "unauthorized DMARC sites" when we can have the
MTA do it.  In fact, that's the point you've been trying to make to me
over and over again (you would even like to reject before DATA,
right?)  So why are you talking to me when you should be lobbying the
Postfix, Exim and Sendmail guys?

 > Well, it pointless to say "many"

Why, thank you for caring so much about our problems.

 > because what the "many" is really suffering from is the lack of
 > options with the DMARC protocol.  It is missing LSP provisions and
 > once that happens then you will have your tools to adjust
 > gracefully.

You mean *if* DMARC gets LSP provisions.  DKIM is what, 7 years old or
so?  Obviously 3rd party provisions are hard to implement.  That may
be for political reasons, as you have implied several times.  But I
don't care -- if politics means we won't get 3rd party authentication
for another 7 years, lists will have to use alternative mitigations
until then.  And if it's actually a hard technology problem, it may
take longer than that.

Besides which, as expert as you claim to be, you should be aware that
it may take several years before systems upgrade to the most recent
versions of software.  DMARC is here *now*, yahoo.com has a "p=reject"
policy *now*, and we (the MLM developers) need to get mitigations into
the pipeline *now* for immediate (or asap, anyway) use by our users.
We cannot wait for your vaporware, as graceful as it may be when it at
long last arrives in usable form.

 > But you have to agree the LSP needs to do the lookup or its
 > frontend receiver has to do the lookup and be aware of the ML part,
 > i.e. acceptable list addresses.

Not at all.  DMARC is an agreement (100% private and unsanctioned by
the Internet, at this point in time) between Author Domains and
destination hosts.  Lists and the systems that host them are not
parties.  The list's host may very well check alignment on the way in,
and guess what? it will be satisfied for legitimate list traffic.
That doesn't help getting it delivered though.

Note that the most efficient way to handle this task is going to vary
by MTA, so although we may wish to publish FAQs to help our users
(assuming any actually do wish to adopt the inflexible policy you
advocate), it's clearly not the MLM dev's job to implement anything.

 > concept of ignoring new growing policy protocols.

That's FUD.  Nobody is promoting "ignorance", and I don't appreciate
you implying that I do.

 > It isn't going to help in the long run. DMARC is here. It isn't
 > going to go away.

You're the only one who talks about DMARC going away as if anybody
were seriously hoping it would.  Nobody believes that is going to
happen, nobody believes that Yahoo! is going to change its policy,
either.  I wish you would stop misinterpreting other people's
positions, and I especially wish you would stop *posting* your
misinformation.

 > Sure, its my opinion and I like to think I am more right than
 > wrong. :)

That's beyond obvious. :(

---

From: Matt Simerson <[email-masked]>
Date: Tue, 10 Jun 2014 13:32:34 -0700

> bloated attachments are services that are very popular with users,

If message headers and footers are so popular, how do you explain the continued "please unsubscribe me posts" sent to practically every mailing list?  Message trailers have insured that the answer is *right there* in every single message. Message trailers are part of the message users have been trained to recognize as "noise" and skim right over. That's why I didn't hesitate to remove them when I made my mailing lists DKIM compatible.

Also while it's certainly true that subject prefixes are popular with list operators, I didn't hear a single peep from my list users when I removed them. I doubt anyone noticed. Granted, mine is a small sample group of a few hundred mail server operators, but I would have expected *someone* to notice. 

Matt

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Jun 2014 18:30:41 -0400

On 6/10/2014 4:21 PM, Stephen J. Turnbull wrote:
> and destination hosts.  Mediators are not party to it.

Once you got involved with DKIM, you became a party of it.

> It's arguable that the host MTA should be checking DMARC
> authentication and alignment, but that's different from saying
> the list should.

Someone has to do it.  Thats an implementation issue.  The MTA, the 
LSP, whoever, whatever, the entry point is where it needs to be done. 
  I thought this was understood.

> I didn't need you to tell me that.  I was hoping for useful data.

You really don't need a list of MUAs, do you?  Don't think so.

> do.  So your advice is not trustworthy, not for list operators.

You are being rude again, this is completely off-base.  I'm an 
engineer. In principle, I prefer to follow protocols rather than break 
them, and if they is a bug in the protocol, then I will help in 
addressing it. I believe that is where we are at.

> DMARC site"?

You indicated your preference not to reject at the system level. 
Perhaps user level?

> Do you even understand the technology?

Rude again.

> Lists are Mediators, they are not party to DMARC, and they don't need
> to be to provide that option.

This is why we have a problem.  You think the LSP does not need to do 
any lookups.  This is major hurdle #1 the expected pending IETF DMARC 
WG needs to consider in its charter.

> Postfix, Exim and Sendmail guys?

The problem is not with the SMTP system. Its the LSP.

> Besides which, as expert as you claim to be,

you are being rude again... but go on...

> you should be aware that

Its a tough situation.

That is why I am trying to figure what it is taking so long for the 
IETF to get going with a DMARC WG.  But I was made aware, things are 
in the works. So we wait...

We really do need another emergency "MARID" working group started. You 
can do whatever you think as necessary as a temporary solution, I 
don't recommend it, I won't add it to our wcListServer product, but I 
can understand why you are passionate about it.  But it is not the 
solution by any measure.  I can only hope that is remains to be a 
temporary isolated (to GNU Mailman) kludge.  My thinking is this will 
be the case.

Once we get the IETF endorsement to proceed with known methods that 
have been proposed and already implemented with "running code" then 
the others will follow.  I believe the Yahoo's will support it but we 
still have to remember there will be domains that DO NOT want you to 
intentionally bypass the security.  So you will need to decide what to 
do with them. In principle, the LSP is part of the network and needs 
to support it whether that is done with a MTA-receiver component or 
otherwise.

> destination hosts.

The LSP is a destination host for the user submitting list mail.  The 
LSP is part of the total picture.

> advocate), it's clearly not the MLM dev's job to implement anything.

The MTA-Receiver is where it should be at. But what if the MTA 
receiver does not support DMARC?

   "Installation note for GNU Mailman. Requires DMARC compliant
    SMTP receivers."

Thats fine. Our MLS works the same way.

> That's FUD.  Nobody is promoting "ignorance", and I don't appreciate

You stated in a very militant manner that your LSPs software will 
ignore DMARC.  I don't recommend it but I understand the dilemma. 
Other systems will just not worry about the domains that do have 
strong policies and let those accounts just automated get 
unsubscribed.  This is what happen in our support list.

> were seriously hoping it would.

Being rude again....

> Nobody believes that is going to

And again....

Ok, I know where you stand. I hope you understand where I stand.

-- 
HLS

---

From: Dave Warren <[email-masked]>
Date: Tue, 10 Jun 2014 15:55:21 -0700

> Also while it's certainly true that subject prefixes are popular with list operators, I didn't hear a single peep from my list users when I removed them. I doubt anyone noticed. Granted, mine is a…

I've been surprised how many otherwise-technically-competent people use 
subject tags to filter mailing lists. However, I suspect much/most of 
this could go away if MUAs started displaying List-* information in a 
useful way, and made filtering on those headers easier than the Subject 
header or the To header.

Either way, if message footers and subject tags have to go away and that 
gets us DKIM signatures through mailing lists (which seems to mostly be 
possible now), that seems like a step forward.

On the other hand, it's only a matter of time before some idiot DKIM 
signs the (lack of) List-ID or List-Unsubscribe header while using a 
DMARC reject policy, resulting in the list engine damaging the DKIM 
signature. I'd class this as abusive and ban such posts from any list I 
operate, but no doubt it's only a matter of time before it happens.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Jun 2014 01:10:35 -0400

On 6/10/2014 6:55 PM, Dave Warren wrote:

> I've been surprised how many otherwise-technically-competent people
> use subject tags to filter mailing lists. However, I suspect much/most
> of this could go away if MUAs started displaying List-* information in
> a useful way, and made filtering on those headers easier than the
> Subject header or the To header.

Some MUAs have began to use the List-ID, especially on the reply side 
of things, so now you have a "Reply to List"  button/option on some of 
them.   Opera Mail also uses List-ID to show a "Mailing List" 
collapsible panel/view selection box of your subscriptions.

For Thunderbird (tbird), I had to manually added a message rule to use 
the List-ID but the first time, I had to add the new header to the 
selection of headers list.

> Either way, if message footers and subject tags have to go away and
> that gets us DKIM signatures through mailing lists (which seems to
> mostly be possible now), that seems like a step forward.

I believe for some markets, there may be a legal requirement to add 
footers.  I think mail can survive, especially where its very active, 
bugs will and have been fixed. But there some legacy systems and 
someone has to tweak them.

I believe in the chain of trust concept. It is ok for the LSP do 
resign. I just think it doesn't help the security when unauthorized 
signing is unchecked.

For TBIRD, I added two DKIM rules in TBIRD to add two color tags:

    Green "DKIM PASS"
    Red   "DKIM FAIL"

This allowed me to explore problem areas.  By now, we pretty much know 
the reasons, the original 1st party signature fails.  My backend 
verified this message from you and it shows:

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=fail policy=unknown author.d=hireahit.com signer.d=ietf.org 
(unauthorized signer);
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=hireahit.com 
header.s=MD-20140321 header.i=hireahit.com;
  adsp=pass policy=unknown author.d=hireahit.com signer.d=hireahit.com 
(originating signer);

First, if you add the ADSP/ATPS recods your hireahit.com zone, it all 
works for the 3rd party ietf.org resigner.

_adsp._domainkey.hireahit.com IN TXT "dkim=unknown; atps=y; asl=ietf.org;"
PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps.hireahit.com IN TXT "v=atps01; 
d=ietf.org;"

This authorizes ietf.org and you will have adsp=pass.  You can use 
this wizard to explore the record and create other authorizations. 
http://www.winserver.com/public/wcadsp

Second, notice the DKIM_BODY_HASH_MISMATCH. This is pretty much a 
signal it was a body integrity error, not the signature itself.  So 
all the 5322 Headers are fine.  This is good information to use in logic.

But if you use ADSP/ATPS, then you also telling the world, that your 
original signature doesn't matter any more after it was resigned by 
the trusted signer.

All we need to do is apply the same idea to DMARC.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 11 Jun 2014 14:15:02 +0900

Matt Simerson writes:

 > If message headers and footers are so popular, how do you explain
 > the continued "please unsubscribe me posts" sent to practically
 > every mailing list?

Bell curve.  Some people are 2-sigma self-centered, and others are
2-sigma clueless.  What else is new?[1]

Note that the kind of people who answer FAQs do like having the footer
so they can say "just click on the link in the footer of any message,
including this one."

 > Also while it's certainly true that subject prefixes are popular
 > with list operators, I didn't hear a single peep from my list users
 > when I removed them.

Sure, there are groups like that, some quite large and varied, as
yours seems to be.  On the other hand, I've participated in a couple
of lists where there was vociferous opposition to removing them from
several users because they had MUA filters based on them.  (Whether
they constituted a significant fraction of the membership is unclear.)

Removal of prohibited content is not so easily addressed, as left to
their own devices users' .doc and .mp4 files can constitute a large
fraction of outgoing bandwidth from list servers that otherwise don't
need much (on a couple of my lists we still get the occasional
oldtimer sending core files for debugging!)

Footnotes: 
[1]  There's also a long-standing bug in Mailman itself, which is that
it requires some effort find the unsubscribe page even if you click on
the link in the footer.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 11 Jun 2014 15:07:06 +0900

Rich Kulawiec writes:

 > But that's not really relevant here.  The flooding propagation
 > model of Usenet is quite different from the model used by mailing
 > lists.

I'm not sure if it's been made clear already or not, but the Gmane
model (copied by the experimental Mailman add-on) is a NNTP network
per site (perhaps multiple lists), ie, a star topology.  I was not
suggesting that mailing lists become Usenet.

I was suggesting that NNTP would be an alternative transport to SMTP,
which might have fewer security issues.  Partly just because it's
obscure, but more fundamentally because *as a point-to-point
transport* it's a pull protocol, and so inherently less attractive to
spammers and phishers.  (That's based on zero careful analysis, so
feel free to give me a clue.  NB To me the point of this idea is that
in the medium term MLs may be able to avoid DMARC by avoiding SMTP,
which would reduce the need for this group to consider mailing lists.
Another protocol which has been proposed as an alternative transport
is IMAP4.)

For redundancy, of course groups of sites might find it useful to
federate in the manner of Usenet.  But that's not the point as far as
I am concerned.

Regards,

---

From: Brandon Long <[email-masked]>
Date: Wed, 11 Jun 2014 14:03:54 -0700

> so they can say "just click on the link in the footer of any message,

In the past (not sure if current), both Y!Groups and GoogleGroups would
send an unsubscribe-confirm message
to any message containing the unsubscribe or similar words in the
subject/first 2 lines of the message.

Another option was to moderate those messages.

In any case, IANAL but some tell me that recent anti-spam laws in the EU
(and maybe CAN-SPAM) can be interpreted to mean that any list which allows
manually added users would require an unsub link in the message.  Probably
not something that is a requirement on the writers of mailman, but
something that major list operators have to deal with.

> oldtimer sending core files for debugging!)

I would think that rejecting the messages with prohibited content would be
more useful than automatically removing it, especially since the resultant
message may be pretty useless without the content... YMMV.

Obviously there are other use cases, for example Y!Groups used to strip
attachments and make them
available online, which resolved quota and bandwidth issues.  They also
used to let moderators edit the content
of the messages during moderation, including removing attachments or
editing the text.. I really didn't like that feature.

Brandon

---

From: Matt Simerson <[email-masked]>
Date: Wed, 11 Jun 2014 14:13:55 -0700

> so they can say "just click on the link in the footer of any message,

That just seems to reinforce the point that the message alterations are far more popular with list *operators* than they are with list *users.*

I can't help but think that all this energy would be better spent focusing on solutions that provides a consistent method for email lists to present their decoration and admin URIs without breaking DKIM. Something that:

	a) Identifies messages as list traffic (aka: List-ID)
	b) Incorporates list info into headers (see below)
	c) Requests MUA authors to identify list messages in a safe and useful fashion**

I fully realize that c) is a can of worms, but I can't help but think that MUA authors are equal to the task. If we provided them with a defined set of Mailing List Actions that were enabled when the MLM software populated the appropriate headers, we could eliminate the vast majority of message alterations.

	List-ID: <dmarc.ietf.org>
	List-Prefix: dmarc-ietf   (MUA: prefix the subject with this string)
	List-Unsubscribe: https://www.ietf.org/mailman/listinfo/dmarc
	List-Unsubscribe: mailto://[email-masked]
	List-Archives: http://www.ietf.org/mail-archive/web/dmarc/current/maillist.html
	List-Preferences: https://www.ietf.org/mailman/listinfo/dmarc

If an implementation of "how to present this in a useful way" was available in JS and PHP, it could likely be incorporated into releases of *most* webmail clients in a matter of months.

Matt

** Mail.app already provides a dropdown list of options when one hovers their mouse over the From and To recipients. It's not hard to imagine a section of that list being List Functions / Manage My Subscription. Similarly, the subject prefix could be decorated with a disclosure triangle that when clicked, presented the list options.

> they constituted a significant fraction of the membership is unclear.)

No doubt. I've been on such lists, where just the discussion of it alone generated vast amounts of controversy.  But if they silently disappeared in the dead of night, approximately 1% of participants would  notice and 0.1% would care.  Granted, that 0.1% would likely squeal very loudly, until you pointed out they can filter using the list headers.*

> oldtimer sending core files for debugging!)

In such cases, don't you think it's appropriate for the list to take ownership of the message, after applying the transformations necessary to make it conform to site policy?

Matt

* Incomplete, but covers a goodly portion of list traffic:

    var mlms = {
        'Mailing-List'       : [
            { mlm: 'ezmlm',       match: 'ezmlm' },
            { mlm: 'yahoogroups', match: 'yahoogroups' },
        ],
        'Sender'             : [
            { mlm: 'majordomo',   start: 'owner-' },
        ],
        'X-Mailman-Version'  : [ { mlm: 'mailman'   }, ],
        'X-Majordomo-Version': [ { mlm: 'majordomo' }, ],
        'X-Google-Loop'      : [ { mlm: 'googlegroups' } ],
    };

---

From: [email-masked] (Martin Rex)
Date: Wed, 11 Jun 2014 19:00:04 +0200 (CEST)

Phillip Hallam-Baker wrote:
> Hector Santos <[email-masked]> wrote:
>> 

Strange concept!

Does your jurisdiction allow your landlord to interfere with
postal/snail mail that is delivered from or to your rented appartment?

And unless your jurisdiction is hopelessly outdated, the same
rules ought to apply to interference with telecommunications.

> IT-Dictator mindset that underlies it: newsgroups have to be approved

Set up your own mail2news gateway.

/usr/lib/aliases  http://www.tldp.org/LDP/nag/node213.html
main2news script  http://www.sirlab.de/linux/descr_m2n.html

-Martin

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Jun 2014 21:12:14 -0400

> engines, before humans come into the picture.

+1
--
Hector Santos
http ://www.santronics.com

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 07:18:54 +0200

On 6/11/2014 12:55 AM, Dave Warren wrote:
> subject tags to filter mailing lists.

I've been surprised at how many otherwise-technically-competent people
believe that techniques that have been reliably useful for decades are
somehow technically incompetent to have been using, given alternatives
that surfaced only more recently and weren't necessary to use.

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 12 Jun 2014 16:40:47 +0900

Matt Simerson writes:

 > That just seems to reinforce the point that the message alterations
 > are far more popular with list *operators* than they are with list
 > *users.*

*shrug* List operators are my constituency.  If you, as a list (site)
operator, choose to do things differently, more power to you.  But my
mission is providing the options that "enough" of my constituents
desire, and I will advocate protocols that enable those options.

 > I can't help but think that all this energy would be better spent
 > focusing on solutions that provides a consistent method for email
 > lists to present their decoration and admin URIs without breaking
 > DKIM.

Me too.  But Dave Crocker et al have squashed (by the weight of their
arguments) discussion of that on this list because *presentation is
UI*, and we don't do UI because we don't/can't do it well, and if we
leave it up to the MUAs they won't do it either, because users aren't
capable of using the information effectively even if it's presented to
them.

I'm not giving up (I'm not so pessimistic about the utility to at
least a significant subset of users), but for the purpose of this list
my options are restricted to third party authorization protocols and
"subversion" (as Hector and Doug would say) when those aren't
available and Author Domain publishes "p=reject".

The rest is tl;dr for mainstream DMARC advocates. :-)

 > Something that:

Nothing new here, people, move along!  Specifically.

 > 	a) Identifies messages as list traffic (aka: List-ID)

List-ID, indeed.  List-Post might also be used.

 > 	b) Incorporates list info into headers (see below)

We already have something pretty much equivalent, but much more
general: the DKIM z= tag.  Murray's concerns about "secondary
validation" are inapplicable, as this would be advisory to the MUA's
presentation algorithms, not part of a security mechanism for
authorizing the message.

 > 	c) Requests MUA authors to identify list messages in a safe

Again, this is not general.  It is already done as far as "useful"
goes (even moderately-skilled users can sort list mail into a separate
folder or tag it), not obviously possible if "safe" means "identifying
legitimate posts" (RFCs 2369 and 2919 can be easily perverted to use
by the Black Hats).  As several posters have pointed out, it probably
can't be done at all, when you're talking about the kind of greedy and
unwary user who falls for "I picked you out of a hat to make you rich"
schemes.

 > I fully realize that c) is a can of worms, but I can't help but
 > think that MUA authors are equal to the task. If we provided them
 > with a defined set of Mailing List Actions that were enabled when
 > the MLM software populated the appropriate headers, we could
 > eliminate the vast majority of message alterations.

Maybe.  We could try, but the whole history of the Web shows that
upstream wants to control appearance in the browser.  I think an
analogous desire is present in list operators, though the details are
different and the degree of control desired is not so absolute.

 > > Removal of prohibited content is not so easily addressed,
 > 
 > In such cases, don't you think it's appropriate for the list to
 > take ownership of the message, after applying the transformations
 > necessary to make it conform to site policy?

No, I don't.  In general, the agent that caused the content to be
posted is still the original From:.  That's what *she* will think,
that's what *readers* will think, and I think it is wrong (and know it
is confusing) to present that content as "From:" anybody else.  In
particular, the most common transformation removes text/html parts
from multipart/alternative bodies, and I can see no justification for
claiming authorship in that case.

If you do, I would recommend presenting your intention accurately by
encapsulating the transformed message in a rfc822/message MIME part,
prefixed by a part containing text explaining the transformations
applied to the message.  You would not then "take ownership" of From:
in the encapsulated message, would you?

---

From: Franck Martin <[email-masked]>
Date: Thu, 12 Jun 2014 07:06:45 -0500 (CDT)

----- Original Message -----
> From: "Matt Simerson" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, June 11, 2014 11:13:55 PM
> That just seems to reinforce the point that the message alterations are far
> more popular with list *operators* than they are with list *users.*
> 
> I can't help but think that all this energy would be better spent focusing on
> solutions that provides a consistent method for email lists to present their
> decoration and admin URIs without breaking DKIM. Something that:
> 

I found that to build the override list for mailing list, I could log DMARC rejected emails that contained a List-Id or List-Post header. Once reviewing the logs (once a week, or once a month), you can make an easy decision if you want to add the found IPs into your override list.

you can see the code at: https://github.com/linkedin/dmarc-msys/blob/master/dmarc.lua#L820

---

From: Terry Zink <[email-masked]>
Date: Thu, 12 Jun 2014 16:36:55 +0000

> Franck Martin wrote:
> 
> I found that to build the override list for mailing list, I could log DMARC rejected 
> emails that contained a List-Id or List-Post header. Once reviewing the logs 
> (once a week, or once a month), you can make an easy decision if you want to 
> add the found IPs into your override list.

That was my thinking, too. 

I like the idea of DKIM-Delegate but if I had to choose between doing Franck's whitelist [1] suggestion above, or DKIM-Delegate, I'd probably do the whitelist because it's less code to implement and maintain; as someone who fights spam we're already in the business of checking logs looking for patterns and doing overrides and so this would simply be one more pattern to look for.

-- Terry

[1] whitelist = override the DMARC p=reject/quarantine action, not skip all filtering

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jun 2014 08:47:27 -0400

> postal/snail mail that is delivered from or to your rented appartment?

Absent specific government action to protect the tenant, the landlord can
abuse them in almost any way they choose. Which is why we have voluminous
legislative protections for tenants. There is an entire field of law
concerning that.

The reason that is necessary is that the alternative to renting is very
expensive and requires a large amount of capital. But if houses were $6
then it would be perfectly reasonable for society to tell tenants that they
are on their own because they should become freeholders.

> main2news script  http://www.sirlab.de/linux/descr_m2n.html

My point is that mail is an old protocol and people who expect that it can
be kept going unaltered in its original form serving all the purposes that
it was never designed for but have emerged over time are going to be upset
no matter what.

Spam is an attack. The people who send spam are hardened criminals who have
murdered at least two people in the past five years. It is futile to expect
that the mail system can continue to operate without changes.

The major ISPs can and will and SHOULD consider the interests of the
majority of their customers as they move forward. If they don't, open email
systems based on SMTP will go the same way as USENET and die because people
don't want to put up with them any more.

The possibility that SAP might force you to subscribe to IETF lists through
a different address does not worry me in the slightest. That is not one of
the uses of email that I consider any sort of priority. I am quite happy
making you change your mail config.

But looking further ahead, it is becoming clear that maintaining mailing
list capabilities is going to become increasingly difficult in the face of
escalating anti-spam controls. Which is why I suggest that rather than the
IETF community reacting to DMARC by refusing to consider any change that
inconveniences members of its club, IETF instead designs a protocol that
addresses the actual needs.

In the SMTP/IMAP model the message is pushed to the sender outbound MTA,
pushed to the receiver outbound MTA and pulled by the client from the
outbound MTA.

The SMTP/IMAP model is thus PUSH/PUSH/PULL

The model of NNTP and Dropbox and many of the blogging comments apps is
PUSH/PULL/PULL. That is a message pattern that we can and should support in
IETF protocols. Because when someone is sending 10Gb of data, the PUSH/PUSH
model is not viable. Better to leave that data siting on the outbound
server rather than have it clog up hundreds of inbound servers and sit
unread.

US6192407 has a priority date of Oct 24, 1996, now would be a good time to
work on such a protocol.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 12 Jun 2014 15:03:13 -0400

Phillip Hallam-Baker wrote:
>
>
>
> On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > Hector Santos <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> Let me ask, what if a fedex.com <http://fedex.com> employee use
>     this email domain for
>     > fedex.com <http://fedex.com> considers them to be relevant.
>     >
> Absent specific government action to protect the tenant, the landlord 
> can abuse them in almost any way they choose. Which is why we have 
> voluminous legislative protections for tenants. There is an entire 
> field of law concerning that.
>
>
Though, in the case of mail, it's Federal law that prevents "mail 
tampering" and other unauthorized interference with US mail.  I'm not 
100% sure, but I expect that an employer might not be legally allowed to 
interfere with a letter addressed to you, at your workplace.

When it comes to email - there are (or at least used to be) the Email 
Privacy Act - which forbid employers from reading your mail, in the 
absence of a clearly stated policy that reserved the right to do so.

Miles Fidelman

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

---

From: Terry Zink <[email-masked]>
Date: Thu, 12 Jun 2014 18:45:37 +0000

> Phillip Hallam-Baker <[email-masked]> writes:
>

True. But Craster gets killed by getting stabbed in the neck.

-- Terry

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 12 Jun 2014 19:22:25 +0000

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Terry Zink
> Sent: Thursday, June 12, 2014 12:37 PM
> To: Franck Martin; Matt Simerson
> Cc: [email-masked]
> > I found that to build the override list for mailing list, I could log
> > DMARC rejected emails that contained a List-Id or List-Post header.
> > Once reviewing the logs (once a week, or once a month), you can make
> > an easy decision if you want to add the found IPs into your override list.
> 
> I like the idea of DKIM-Delegate but if I had to choose between doing
> Franck's whitelist [1] suggestion above, or DKIM-Delegate, I'd probably do
> the whitelist because it's less code to implement and maintain; as someone
> who fights spam we're already in the business of checking logs looking for
> patterns and doing overrides and so this would simply be one more pattern
> to look for.
> 
> -- Terry
> 

And this fits squarely within the DMARC local policy space.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 08:57:08 +0900

Terry Zink writes:
 > > Franck Martin wrote:
 > > 
 > > I found that to build the override list for mailing list, I could
 > > log DMARC rejected emails that contained a List-Id or List-Post
 > > header. Once reviewing the logs (once a week, or once a month),
 > > you can make an easy decision if you want to add the found IPs
 > > into your override list.
 > 

Sure, but as soon as the spammers adapt and start spoofing lists, you
need to check the list's signature anyway.

And I don't think customers who sign up for a list will be happy with
losing mail for a month.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 09:11:48 +0900

Phillip Hallam-Baker writes:

 > My point is that mail is an old protocol and people who expect that
 > it can be kept going unaltered in its original form serving all the
 > purposes that it was never designed for but have emerged over time
 > are going to be upset no matter what.

True, as far as it goes.  However, there is need for a push protocol
that allows you to receive contacts from authors you don't know yet,
in other words, a medium that is designed to be flexible enough to
accomodate new modes of communication.

It's not obvious to me that this need can be satisfied while at the
same time denying spam.  If it is indeed impossible, I don't see why
that purpose can't continue to be served by email, while most mail
(which is correspondence among acquaintances) gets redirected into
authenticated channels.

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 13 Jun 2014 07:55:25 -0400

> (which is correspondence among acquaintances) gets redirected into
Just a quick reminder here:  Postal mail is still going strong, after 
100s of years.

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Jun 2014 08:46:27 -0400

> And I don't think customers who sign up for a list will be happy with

RECOMMENDATION:

In principle, the LSP SHOULD do be denying any new subscriptions from 
restrictive domains.

If the LSP decides to have exceptions and ignore the restrictive 
security policies, it MUST warn the user with a confirmation or 
welcome notification message. It SHOULD also regulate subscription 
attempts during the online initial subscription process, i.e, describe 
what will happen, have a TOS, some "red" highlighters, etc.  In all 
cases, it MUST warn the users of any tampering will be taking place 
with the authorship which may have a "scratch your head" negative 
effect on readers of any 5322.From tampered mail.  It should consider 
documentation verbiage that explains the reason:

      "This is not normal practice, and readers SHOULD NEVER
       expect authorships to be display with any invalid
       indicators. However, __{explain your reasons here for
       the drastic exception}__."

-- 
HLS

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jun 2014 08:18:03 -0400

>>  Just a quick reminder here:  Postal mail is still going strong, after
Only because we haven't got email security properly sorted.

I can't remember the last time I received a real letter. All I get is junk
mail and bills. And the bills arrive because we haven't got the standards
for doing it electronically established yet.

Within a decade postal mail and the telephone will have become as
functionally obsolete as fax. It will take a lot longer for them to
disappear, the telegram only stopped last year, about a hundred years after
it was utterly obsolete.

The postal service will continue of course until Bezos works out how to get
his drones to work.

Technology does change over time. There is a very clear demand for an open
Dropbox like solution. There is a clear need for a protocol that allows
email like subscriptions to blog comments without the mailbox clog that
results.

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 13 Jun 2014 14:06:18 -0400

Phillip Hallam-Baker wrote:
>
>
>
> On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Just a quick reminder here:  Postal mail is still going strong,
>     after 100s of years.
>
>
> I can't remember the last time I received a real letter. All I get is 
> junk mail and bills. And the bills arrive because we haven't got the 
> standards for doing it electronically established yet.

Bills are "real" - they're transactional.  So are checks.  Some of us 
actually do things like send proposals, signed contracts, and so forth.  
And, of course, packages.  And the higher the value, the more likely 
that they'll be sent via physical mail.  It ain't going away anytime soon.

Miles Fidelman

---

From: Brandon Long <[email-masked]>
Date: Fri, 13 Jun 2014 12:13:14 -0700

On Fri, Jun 13, 2014 at 11:06 AM, Miles Fidelman <[email-masked]

>> On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman <
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>  And, of course, packages.  And the higher the value, the more likely that
> they'll be sent via physical mail.  It ain't going away anytime soon.

If I had spam filtering on postal mail that was as good as I've got on
email, regular postal mail would already be gone.

That isn't to say that high value postal mail at FedEx/UPS/etc prices would
be gone, just that current first class mail and daily deliveries would be.

In the US, the USPS is already on rough ground (which isn't entirely due to
failing rates of mail, granted), so "going strong" would not be what I'd
use.  Holding out for another 100 years in some form... maybe.

Brandon

---

From: Joe Abley <[email-masked]>
Date: Fri, 13 Jun 2014 20:02:14 -0400

On 13 Jun 2014, at 7:55, Miles Fidelman <[email-masked]> wrote:

> Just a quick reminder here:  Postal mail is still going strong, after 100s of years.

I don't know what it's like where you live, but here the only thing that is keeping the post office afloat is being paid by advertisers to deliver unsolicited junk.

"Canada Post has hiked postal rates for regular mail and plans to cut up to 8,000 jobs as it phases out urban mail delivery over the next five years -- all in a bid to reverse the tide of red ink at the money-losing Crown corporation."

"The Crown Corporation predicted this year that Canada Post and its subsidiaries would lose $274 million before tax in 2014."

"Still going strong" is not a phrase that resonates with me.

Joe

---

From: Matt Simerson <[email-masked]>
Date: Fri, 13 Jun 2014 21:43:24 -0700

> "Still going strong" is not a phrase that resonates with me.

Canada Post lost $274 million EBITA?  Let us Yanks show you how it's done:

http://about.usps.com/news/national-releases/2014/pr14_031.htm

	WASHINGTON — The U.S. Postal Service ended the second quarter of its 2014 fiscal year (Jan. 1, 2014 – March 31, 2014) with a net loss of $1.9 billion. This marks the 20th of the last 22 quarters it has sustained a loss.

	• First-Class Mail Volume Declines by 4.1 percent
	• Approximately $64 Billion in Liabilities Exceed Assets by $42 Billion

/end tongue in cheek

Matt