Subject: [dmarc-ietf] hints for receivers

From: Tim Draegen <[email-masked]>
Date: Sat, 20 Apr 2013 08:57:07 -0400

I like the spirit J. Gomez's "l={yes,no,dunno}" proposal, but have been struggling 'cause I don't think it would be effective in the wild.

While grinding up a batch of coffee beans, it struck me that "l={yes,no,dunno}" is part of a larger category of "hints for receivers".  As such, would receivers make use of high-level sender-provided descriptors of email category?

For example, "l={yes,no,dunno}" could be realized with a "category={transactional,newsletter,organization/corporate}" type of tag.  In this way, receivers would use the hint "category=transactional", see that the message came over a mailing list (transactional email shouldn't come through a mailing list, right?), and act appropriately.

=- Tim

PS.  The "l={yes,no,dunno}" tag attempts to prescribe whether or not a domain is excepted to arrive through a "list".  From the receiver PoV, is a description of the content of the email more generally useful?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Apr 2013 10:08:17 -0700

This is reminiscent of VBR (RFC5518).  It would be interesting to find out
how much uptake of that there's been.

Either way, I don't see this as something that could go in the base spec.
However, DMARC was made extensible, so if there can be shown a demand for
this among both senders and receivers, which is to say (as you asked) if
there are receivers willing to make use of it, then it could be developed
as an extension.

I imagine, though, that if such receivers existed, we'd have heard from
them by now.  The preferred practice appears to be for receivers to
identify lists using their own methods.

-MSK

On Sat, Apr 20, 2013 at 5:57 AM, Tim Draegen <[email-masked]> wrote:

> I like the spirit J. Gomez's "l={yes,no,dunno}" proposal, but have been
> struggling 'cause I don't think it would be effective in the wild.
>
> While grinding up a batch of coffee beans, it struck me that
> "l={yes,no,dunno}" is part of a larger category of "hints for receivers".
>  As such, would receivers make use of high-level sender-provided
> descriptors of email category?
>
> For example, "l={yes,no,dunno}" could be realized with a
> "category={transactional,newsletter,organization/corporate}" type of tag.
>  In this way, receivers would use the hint "category=transactional", see
> that the message came over a mailing list (transactional email shouldn't
> come through a mailing list, right?), and act appropriately.
>
> =- Tim
>
> PS.  The "l={yes,no,dunno}" tag attempts to prescribe whether or not a
> domain is excepted to arrive through a "list".  From the receiver PoV, is a
> description of the content of the email more generally useful?
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 20 Apr 2013 13:21:42 -0400

Most of the current deployment is at large providers that can do significant 
data analysis to effectively identify lists.  As a small domain, there's no way 
I can do the same.

If there were a protocol method to share this information, either among 
trusted receivers or via 'hints', it could be useful to smaller providers that 
don't have the scale to mine the data themselves.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Apr 2013 10:49:00 -0700

> don't have the scale to mine the data themselves.

Why would you, as a small-scale receiver, believe what an unfamiliar sender
claims about whether its traffic transits lists, ultimately meaning "don't
be so strict with this message"?  That seems a big loophole with little
benefit to me, regardless of your size, given the nature of the problem
space; malicious senders will always use it, and good senders that use it
will be spoofed more easily.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 20 Apr 2013 14:20:03 -0400

> will be spoofed more easily.

I probably wouldn't.  My point wasn't to advance a particular solution, but to 
suggest that the experience base with how large providers with extensive data 
mining capability prefer to do things probably isn't universally applicable.

I solution involving receiver collaboration is more likely to be useful.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2013 20:09:35 -0000

>how much uptake of that there's been.

It's not really like VBR, which is for third party whitelists, with
the type tags being for auditing.  In any event the current usage
of VBR is approximately zero.  I don't know of any publisher of VBR
other than the vestigial Spamhaus whitelist.

My advice for senders who want to publish extra hints for receivers is
this: don't bother.

For a sender we don't know, we're going to ignore the hint since there
is no reason to believe it.  For a sender we do know, we're probably
going to accept your mail anyway and the hint won't help.

There might be some use for sender assertions in mail like the ones in
VBR to help audit and diagnose authentication screwups, but if they're
useful, they'll be useful on their own and not as part of DMARC.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Apr 2013 13:12:10 -0700

> going to accept your mail anyway and the hint won't help.

We need to produce an online placard that quotes the above and is cited 
for all discussions about improving email abuse-related handling...

d/
-- 
  Dave Crocker
  bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2013 20:14:43 -0000

>don't have the scale to mine the data themselves.

That's the kind of thing that VBR is intended for.  A trusted party
publishes a list of certified domains in the DNS.  When you get a
message, you look up the authenticated domain (DKIM valid d= or SPF
mail from pass) in the VBR list, and if it's there, it's certified.

The mechanism is trivial.  The hard parts are collecting the set of
trustworthy sending domains, and arranging for someone credible to
publish it.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 22 Apr 2013 17:05:40 +0200

On Sat 20/Apr/2013 22:09:35 +0200 John Levine wrote:
> 
> I don't know of any publisher of VBR other than the vestigial
> Spamhaus whitelist.

Heck, "vestigial"!?  No further thoughts on it?  Maybe it was just the
sunrise campaign parading a dot-com approach without further
disclosure of the business model, or some other marketing detail...

> My advice for senders who want to publish extra hints for receivers
> is this: don't bother.

That leaves another possibility:  Tell those extra hints privately.

If you recall my smtp-request/dns-reply sketch[1], augmenting the
possibilities of replying could make sense.  Each row in an aggregate
report identifies a message stream characterized by some identities.
A receiver could let the recipients of aggregate reports manually
whitelist the rows that would cause rejection if the relevant policy
was stronger, e.g. using a purposely designed web form.

That semi-automated cooperation can be valuable whether or not a
domain is going to strengthen their policies.  It's feedback on feedback.

[1] http://www.ietf.org/mail-archive/web/dmarc/current/msg00188.html

---

From: "John Levine" <[email-masked]>
Date: 22 Apr 2013 18:00:36 -0000

>That leaves another possibility:  Tell those extra hints privately.

You can make whatever private arrangements you want.  That's not what
standards are about.

R's,
John