Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive

From: "Thom O'Connor" <[email-masked]>
Date: Wed, 20 Feb 2008 16:43:57 -0800

Eric Allman wrote:
> I am in no way married to the word DISCARDABLE.  We used it in SSP-02 
> because it matched ASP.
> 
> It has occurred to me that we've spent FAR too much time arguing 
> about exactly what word to use.  I'm deeply tempted to switch to 
> numbers, special characters, or random gibberish strings so that 
> people have to read the actual description.

Hi Eric,

I understand this sentiment, and your point here is notable.

However, it is very important that the terminology in use here is 
accurate and appropriate. The global messaging user-base wants and 
expects guidance on implementation that should be clear and direct. The 
truth of the matter is, the discarding of email should be expressly 
discouraged. No message should ever be discarded - RFC 2821 suggests 
this though does not explicitly disallow or discourage it:

http://www.ietf.org/rfc/rfc2821.txt
> Delivery SMTP systems MAY reject ("bounce") such messages rather than deliver them.

The discarding of email is one of the key causes of some significant 
loss of trust in email as a reliable means of communication. While it 
may be argued that spam may have caused email receiving domains to react 
in this way as a defense mechanism, it is actually the overreaction - 
perhaps due to a lack of guidance - that has allowed providers to think 
that discarding messages is a satisfactory response to the spam or 
malware threat. Perhaps, if our techniques were 100% accurate in 
ensuring that no valid message was ever lost, discarding could be 
appropriate. These techniques will not likely ever reach 100% accuracy.

If we (where "we" is the email industry here that seeks to maintain and 
even expand the usefulness of email itself, rather than seeing our users 
resort to making a phone call or using IM when they need a "sure" method 
of communication) should be clear about this then, one appropriate value 
for the SSP record would be "reject" or something equally directive, 
perhaps "verify". And if we are to really seek to be clear on the 
Signing Practice in use, then perhaps we may even include a "none" value:

none - The domain signs no email.
unknown - The domain may sign none, some, or all email.
all - All mail from the domain is signed with an Author Signature.
reject (or verify) - All mail from the domain is signed with an Author
          Signature.  Furthermore, if a message arrives without a valid
          Author Signature due to modification in transit, submission via
          a path without access to a signing key, or other reason, the
          domain encourages the recipient(s) to reject it if it does not
          verify.

There are certainly valid reasons that a domain may request this higher 
level of requested interpretation - signature-based verification moves 
email towards an (optional) higher level of reliability and identity 
verification with legal and commercial implications.

Douglas Otis wrote:
>> Agreed.  This changes "strict" (the exclusivity) assertion into
>> something that does not express a domain's intentions on
>> exclusivity.  This assertion simply increases the likelihood of
>> having the domain's messages discarded.
>>
>> Using Hector's term "exclusive"-
>>
>> exclusive:
>> All mail from the domain is signed with an intent to avoid
>> agents that may damage or remove signatures.  Furthermore,
>> in lieu of a trusted third-party signature, if a message
>> arrives without a valid Author Signature due to
>> modification in transit, submission via a path without
>> access to a signing key, or other reason, the domain
>> encourages the recipient(s) to reject the message or issue
>> a DSN when the RFC 2821 MAILFROM domains match.

This line of thinking is on target, though we really need to get better 
at using words our users will understand. "exclusive" is ambiguous, and 
I would argue, not an easily understood concept. "Signature did not 
verify" would seem to be an error message that could possibly be 
understood by a normal user in a DSN message.

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

---

From: <[email-masked]>
Date: Wed, 20 Feb 2008 23:17:38 -0500

How very strange I wonder what explains the over 2k bounce messages of undeliverability due to content in my honey trap mail account that has been spoofed in the last 3 days alone. It appears that cheap software, designer shoes and On line degrees don't apply to the RFC's. It seems that organizations around the world don't adhere to the specs. That is why commercial messages need to be delivered to the inbox in some other method from edge to edge than smtp via a community service bureau or other entity. This WOULD allow a 99.999% delivery rate of valid messages while killing 99.999% of spam. Also it would free up considerable bandwith as commercial mail would only need one copy of a message to be delivered to each ISP instead of spraying millions hoping for a high receive rate. 
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Thom O'Connor
Sent: Wed 2/20/2008 7:43 PM
To: [email-masked]
Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive

Hi Eric,

Sincerely, respectfully,
-thom

---

From: SM <[email-masked]>
Date: Sun, 24 Feb 2008 00:06:20 -0800

>this though does not explicitly disallow or discourage it:

Discarding of email should be discouraged except if "there is very 
high confidence that the messages are seriously fraudulent or 
otherwise inappropriate".

Proponents of anti-spam are in favor of this feature as it works for 
them; i.e. they can determine that the message is unwanted.  We have 
the usual set of users who will implement this feature without 
understanding the implications.

>of communication) should be clear about this then, one appropriate value

Agreed.

If the group wants to keep discardable, I suggest a change in Section 3.3:

      "discardable  All mail from the domain is signed with an Author
          Signature.  Furthermore, if a message arrives without a valid
          Author Signature due to modification in transit, submission via
          a path without access to a signing key, or other reason, the
          domain encourages the recipient(s) to discard it instead of
          sending a "bounce".

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 24 Feb 2008 16:32:39 -0000

>          domain encourages the recipient(s) to discard it instead of

No, they should discard it, period.  As I said in my previous message,
enough rejects turn into blowback to be part of the problem.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
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 12:14:53 -0500

>        domain encourages the recipient(s) to discard it instead of

Pray tell,  are you aware this tells the MTA who are processing the 
payload at the SMTP DATA state (not POST SMTP), to issue a 250 positive 
message accept response code with the true purpose of silently 
discarding it?

So its more of a

    PUBLIC REJECT notification
    PRIVATE DISCARDING OF MAIL  (no notification)

operational behavior?

Of course, this would also conflict the current direction of MTA of 
doing more dynamic SMTP level analysis of mail by mandating a DKIM/ASP 
design of delaying the payload analysis to POST SMTP.

-- 
Sincerely

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

---

From: Hector Santos <[email-masked]>
Date: Sun, 24 Feb 2008 12:23:32 -0500

>     PRIVATE DISCARDING OF MAIL  (no notification)

Sorry, I meant:

     PUBLIC ACCEPT notification
     PRIVATE DISCARDING OF MAIL  (no notification)

-- 
Sincerely

Hector Santos, CTO

---

From: SM <[email-masked]>
Date: Sun, 24 Feb 2008 11:46:59 -0800

At 09:14 24-02-2008, Hector Santos wrote:
>payload at the SMTP DATA state (not POST SMTP), to issue a 250 
>positive message accept response code with the true purpose of 
>silently discarding it?

Yes.

>operational behavior?

Yes.

>doing more dynamic SMTP level analysis of mail by mandating a 
>DKIM/ASP design of delaying the payload analysis to POST SMTP.

If you mean DKIM/ASP verification, that can be done during the SMTP session.

Regards,
-sm

---

From: Damon <[email-masked]>
Date: Sun, 24 Feb 2008 15:11:29 -0500

>  >positive message accept response code with the true purpose of

Agreed.
All you are doing at this point is releasing the responsibility for
the delivery of the message from the sending MTA.
What you do with the message after that is your own business. You ARE
accepting the message, dropping it on the floor is a matter of policy,
not RFC's.

Regards,
Damon