ietf-dkim
[Top] [All Lists]

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

2006-11-08 08:06:03
On 11/7/06 8:59 PM, "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com> 
scribbled:
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?

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             <jpowers(_at_)paypal(_dot_)com>
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