[ietf-dkim] Collection of use cases for SSP requirements
jpowers at paypal.com
Tue Nov 7 19:07:41 PST 2006
On 11/7/06 7:08 PM, "Scott Kitterman" <ietf-dkim at kitterman.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 Powers <jpowers at paypal.com>
"Trimming quoted text in email leaves more room for you in heaven."
-Ricardo Signes in irc://irc.perl.org/#perl
More information about the ietf-dkim