On 11/7/06 7:08 PM, "Scott Kitterman" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
