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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Thom O'Connor
Sent: Wed 2/20/2008 7:43 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html