Subject: Re: [ietf-dkim] discardable means discardable

From: John Levine <[email-masked]>
Date: 24 Feb 2008 01:44:49 -0000

> The discarding of email is one of the key causes of some significant
> loss of trust in email as a reliable means of communication.

Since I invented the term "discardable" perhaps I should explain why I
mean discardable when I say discardable.

There is a common meme that discarding mail is always bad.  But
generating and delivering bogus mail is just as bad, because nobody
can find the real mail in a mountain of spam.  Every day I get
feedback loop "spam" reports for what is clearly real mail from a real
person sent to a real recipient.  But the recipient's eyes glazed over
at all the spam in the inbox, and they discard the real mail along
with the spam.  Keep that in mind.

I'm not sure how many people here other than Mike Hammer and me have
direct experience running a heavily phished domain, so here's a report
from the trenches.  I run abuse.net, a tiny little domain that manages
a reporting address database.  On a busy day there might be 100
outbound messages with abuse.net return addresses, but due to some
eastern European spammers with a strange sense of humor, every day I
get 400,000 bounces, out of office, and other blowback.  That's the
reality of a phish target -- the fake mail vastly exceeds the real
mail, by orders of magnitude.  I don't know the absolute numbers for
Paypal and the various banks, but I'm confident that they are in the
same situation at even larger scale, way more fake than real mail.

That's why when I say discardable, I really mean it.  When I upgrade
my MTA to sign all of abuse.net's mail, I will really want you to
throw away unsigned mail.  Not reject, not bounce, not send a DSN,
just THROW IT AWAY.  Even if you carefully do your filtering and
reject at SMTP time, enough of the MTAs that see your reject will turn
it into a bounce that I'll still be inundated with junk bounces for
mail I didn't send.  (Hmmn, large numbers of similar messages I didn't
ask for and don't want.  Don't we have a name for that?)

I have some fairly effective heuristics to identify the bogus bounces,
but they're not 100% accurate, which means that with all the noise, I
lose some of my real bounces as well.  Who benefits from that?

If you aren't in this situation, vastly more fake mail than real mail,
discardable doesn't apply to you.  If you see the occasional bounce
blowback, or even the occasional burst of a few hundred blowbacks,
it still doesn't apply to you.  Really.

I entirely agree that for normal mail, you should reject it if you
don't deliver it so that the real person (or perhaps the real ESP) who
sent it can do something useful with the info.  But this situation is
different -- the bad mail is not from real senders, the forged sender
is already acutely aware that there's a lot of forgery, and any
response will just increase the noise.

People do need guidance on discardable, but the guidance is pretty
simple:

A) If you're not sure whether discardable applies to you, it doesn't.

B) If you're fairly sure that discardable applies to you, it still
probably doesn't.

C) If a heavily phished domain asks you to throw away the apparent
forgeries, do the world a favor and take their advice.

R's,
John

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Damon <[email-masked]>
Date: Sat, 23 Feb 2008 23:19:31 -0500

> forgeries, do the world a favor and take their advice.

John,

 Standing O, loud thunderous applause and four finger whistles from me.
I get the feeling that those of us in the trenches get bulldozed over
sometimes.

Regards,
Damon
Experience: Postmaster of a few tiny domains ;-)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Al Iverson" <[email-masked]>
Date: Sat, 23 Feb 2008 20:43:08 -0800

>  ask for and don't want.  Don't we have a name for that?)

The alternatives aren't really any better, either. Bounce it. Bounce
it where? To the (99% chance of forged) return path?

>From what I am led to believe, the vast majority of DKIM evaluation is
taking place after receipt, meaning the opportunity to reject during
SMTP is not available.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 24 Feb 2008 00:25:02 -0500

> mean discardable when I say discardable.

Oh brother.

What else could it mean that hasn't been applied to the term discardable 
  in the history of mail? both physical and electronically? and more 
specific in the trade, the "Discarding of Junk Mail?"

Unless you wanted to bounce mail in a POST SMTP DKIM process, thats all 
you could do in a POST SMTP system is discard it, throw it away.

To REJECT it in SMTP terms, most experts will view that as a 
notification signal as it applied in practice, either dynamically at the 
SMTP level or with a accept/bound action.

Anything short of that is discarding the mail. You were not the first to 
invent the term NOR the idea of "Discardable" mail.

But what I am more curious with is this statement:

 > C) If a heavily phished domain asks you to throw away the
 > apparent forgeries, do the world a favor and take their advice.

ASK?  World a favor?  I seem to recall using that phrase quite often in 
my many PRO SSP discussions.

But it was appearing very clearlu that you, Wietse and others were 
clearly against such "advice" and instructions from the domains.

No, there has to be something else that is nudging the receiver to heed 
the advice from the domain. DAC Perhaps?

Also is there a qualification for asking a receiver to "discard" mail? 
Can only Heavily phished domain ask?  Can it be lightly phished? Is 
there a certain threshold of "phished mail?  Or does DISCARDABLE also 
mean "No sorry. You are not suffering enough to have the right to ask me 
to discard mail." ???

-- 
Sincerely

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 25 Feb 2008 09:43:34 -0500

>Can only Heavily phished domain ask?  Can it be lightly 
>phished? Is there a certain threshold of "phished mail?  Or 
>does DISCARDABLE also mean "No sorry. You are not suffering 
>enough to have the right to ask me to discard mail." ???
>
>

Without intending to put words in John's mouth, I think what he meant is
that there is the risk of some legitimate email being lost if a receiver
respects a discardable assertion. In that respect, sending domains need
to consider carefully the implications of making a discardable
assertion. Something along the lines of "careful what you ask for
because you just might get it".

The other factor is that receiving domains are going to consider
complaints received by their users for undelivered email in their
calculation of whether to respect a discardable assertion. We all know
that there are quite a few domains that have implemented all manner of
things incorrectly, poorly or with a misunderstanding of the
consequences of their actions. Once there is more experience with
SSP/Discardable/etc on the part of senders and receivers, I expect this
to be less of a problem - or should I say "I hope".

Finally, it may be that domains use some sort of decision matrix
uinvolving DKIM and a discardable assertion in the context of other
factors such as a strong SPF assertion. If a particular email fails SPF
AND fails DKIM they may discard it. On the other hand, if it passses SPF
but fails DKIM they may choose not to discard it. 

As a signing sender - even with some feedback from some receivers - I'm
still not in a position to give specific numbers with regard to broken
signatures from forwarding, etc. The numbers appear to be relatively
small but from the receiver domain perspective (with regard to
complaints), how small is small enough? While I'm an advocate of
discardable, I recognize that it isn't for everyone. I've said this all
along. I also recognize though that it is the receiver domain customer
support staff that are likely to hear (first) about undelivered emails. 

The receiver domain is likely to choose to balance the benefit from
listening to discardable assertions and the increase in support calls
that might result from any particular domains discardable assertion. 

Just a few thoughts.

Mike

---

From: SM <[email-masked]>
Date: Mon, 25 Feb 2008 09:03:37 -0800

>because you just might get it".

The receiver might read it as "sender doesn't care whether the mail 
gets delivered".

>to be less of a problem - or should I say "I hope".

John Levine made a case for when discardable is useful.  As he 
doesn't even want rejections, the receiver will also have to decide what to do:

  1. If the key cannot be retrieved in DNS

  2. On failures for DKIM checks (excluding hash verification)

  3. MTA failures

At the moment, these are treated as a temporary failure.  To avoid 
any blockback, the receiver might as well drop all mail from that domain.

>that might result from any particular domains discardable assertion.

Yes.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 Feb 2008 09:52:01 -0800

> The receiver might read it as "sender doesn't care whether the mail  

Agreed.  Steve Atkins also opined this assertion _does not_ offer a  
solution addressed in RFC 5016 requirements draft in section 3.2.  The  
"Signing Complete" assertion recommended was silent on diminished  
handling of DSNs.  Handling transactional messages in a "discard"  
fashion hides possible protocol issue.

The SSP draft could recommend the use of RFC 3464, with examples  
specific to DKIM signature failures.  Any diminished handling of DSNs  
may also be predicated upon when RFC 2821 MailFrom is not within the  
RFC 2822 From/DKIM domain.  This could assist high profile domains  
deal with DSN messages, without also handling backscatter purportedly  
from other domains.

Would it be possible to include the "Signing Complete" assertion?

What would be the drawback in allowing this type of assertion?

-Doug

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 25 Feb 2008 13:17:51 -0500

>-----Original Message-----
>From: SM [mailto:[email-masked]] 
>Sent: Monday, February 25, 2008 12:04 PM
>To: MH Michael Hammer (5304)
>Cc: [email-masked]
>Subject: Re: [ietf-dkim] discardable means discardable
>
>
>The receiver might read it as "sender doesn't care whether the 
>mail gets delivered".
>

While there might be some domains that take that stance I wouldn't
expect "mainstream domains" to take that stance. I expect financial
institutions to be somewhat early adopters and any ISP/mailbox provider
that decides discardable means don't bother trying to deliver the mail
should be prepared to beef up their Customer Service staff to handle
complaints.

There is a significant difference between sendedr saying "I recognize
that a fraction of a percent of legitimate mail might not get delivered
if my assertion is followed" and "sender doesn't care whether the mail
gets delivered". 

Mike

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Feb 2008 14:05:28 -0500

> should be prepared to beef up their Customer Service staff to handle

And beef up their legal retainers as well.

> if my assertion is followed" and "sender doesn't care whether the mail

+1.

I have less of an issue with the DISCARDABLE policy.

It is the lack of one or having the other policies with no handling 
semantics that will very interesting.  Same EMAIL abuse? Two different 
policies?  I see clear legal claims neglect against high-value domains 
who don't use DISCARDABLE.

In other words, if a receiver sees a damaging goods and continues to 
pass on the damaged goods because ASAP says so, and there is user harm, 
someone is going to be responsible.

This whole thing is ridden with fleas and the on-going administrator 
"myth" that there is no product liability risk with DISCARDING of MAIL, 
especially after issuing a 250 Acceptance.  It smacks against the 1986 
US EPCA provisions for satisfying "User Expectations."   The dynamic 
SMTP level reject satisfy this instant notification.  Accepting and 
discarding runs a HUGE risk.  So people better get this right.

-- 
Sincerely

Hector Santos, CTO

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Feb 2008 10:43:38 -0800

> if my assertion is followed" and "sender doesn't care whether the mail

They're the same statement. If they cared about mail they send being
delivered they wouldn't deploy something which will, by design, cause
some fraction of it to not be delivered (and provide no other benefits).

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 Feb 2008 12:03:01 -0800

On Feb 25, 2008, at 10:43 AM, Steve Atkins wrote:

>> institutions to be somewhat early adopters and any ISP/mailbox  
>> provider that decides discardable means don't bother trying to  
>> deliver the mail should be prepared to beef up their Customer  
>> Service staff to handle complaints.
>>
>> There is a significant difference between sendedr saying "I  
>> recognize that a fraction of a percent of legitimate mail might not  
>> get delivered if my assertion is followed" and "sender doesn't care  
>> whether the mail gets delivered".
>
> delivered they wouldn't deploy something which will, by design,  
> cause some fraction of it to not be delivered (and provide no other  
> benefits).

"No not send DSNs upon signature failure" is not the same as "Expect  
this domain's messages to be "Signing Complete".  A measure of  
delivery integrity includes receipt of Delivery Status Notifications  
upon failure to validate.  Presumably, once DKIM becomes broadly  
implemented, back-scatter will be curbed by reduced success rates of  
spoofed messages.  Rather than achieving consensus for the "discard"  
feature within the requirements phase, the required "Signing Complete"  
assertion has been replaced by a new and completely different  
assertion previously not discussed on this list.  The usefulness of  
the "discard" assertion appears limited and perhaps unneeded once DKIM  
becomes more broadly adopted.

These are not the same assertion.  Make a case where both assertions  
are allowed, or return to the previously agreed "Signing Complete"  
that omits advice on verifier actions.

-Doug