On 11/7/06 8:59 PM, "Scott Kitterman" <[EMAIL PROTECTED]> scribbled: > 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?
Yes, although it's been a long time since I've managed a site that was mostly incoming email, so I'm probably not up to date on what the large mail providers have to deal with. >> 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. My thoughts are that I know what problems deferrals cause me on the sending side (due to new public IPs that aren't whitelisted), I imagine the problem would be worse on the receiving side if a rejection was guaranteed never to be delivered (ie mail accepted, and *GASP* a forged from header :) ). In that case I would expect a "reject, then delete" policy would be in the best interests of the 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. In my experience, I/O is more of the problem than CPU, but I'd love to hear what the receivers say. -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
