ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Collection of use cases for SSP requirements

2006-11-07 21:12:30
On Tuesday 07 November 2006 22:07, Powers, Jot wrote:
On 11/7/06 7:08 PM, "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com> 
scribbled:

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.

This may be what you meant, but it's my understanding that you have to accept 
the entire message and respond 550 to the final '.'.

There are timing issues associated with doing CPU intensive processing before 
queing the message that would have to be managed.  Is that where you see the 
complexity?

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.

I can understand that.  

I think that reject or deliver (if only to a spam folder) is a reasonable 
approach.  Deleted might not be a bad fallback if rejection doesn't work out 
for some reason for some receivers.

I do know that there are large commercial receivers that are doing tasks more 
CPU Intensive than DKIM verification (e.g. virus scanning) during the SMTP 
session and doing it reliably, so I believe that while reject after DATA does 
have challenges, I think they are manageable.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html