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>
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
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.
NOTE WELL: This list operates according to