On 11/7/06 7:08 PM, "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
scribbled:
Just joining, so excuse me if this has been dealt with before.
Thank you for pulling that together. I think that was an excellent writeup.
One point I'd like to pull the thread on is the word drop. Rather that drop,
I think it would be better to say reject. I'm taking the word drop to mean
delete here.
I think that deleting messages that fail an SSP test is not good for the
overall reliability of the e-mail ecosphere as there is no indication to
either the sender or the receiver (at the user level) that a message has not
been delivered. This raises uncertainty. If messages are rejected (SMTP 550
at the end of DATA), then legitimate senders will be notified of the failure
and can take action to rectify the problem without the backscatter risk
associated with accept then bounce.
I think we agree 100%, if we can get the rejection to happen at the end of
data, and not after delivery. After delivery, the results of "joe jobbing"
are simply too onerous.
I think that rejecting messages meets the goal that is stated here without
adding risk or uncertainty.
We agree, if we can get that data phase rejection. The problem that I see
is that most systems aren't setup to do that, and aren't willing to take on
the complexity of "mostly" accecpting before rejecting.
As an admin at a large (non-spam) email site, that is, to put it mildly,
heavily phished, we would rather email that is not DK signed be dropped (ie
silently deleted) than "rejected" if my statements about rejection after
data are true.
-Jot
--
Jot Powers <jpowers(_at_)paypal(_dot_)com>
Skype: jotebay
"Trimming quoted text in email leaves more room for you in heaven."
-Ricardo Signes in irc://irc.perl.org/#perl
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html