On Tuesday 07 November 2006 22:07, Powers, Jot wrote: > On 11/7/06 7:08 PM, "Scott Kitterman" <[EMAIL PROTECTED]> 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
