[Top] [All Lists]

RE: possibilities for 2822 (was SPF implementations)

2005-08-18 07:33:01
Seth Goodman writes:
From: Dick St.Peters [mailto:stpeters(_at_)NetHeaven(_dot_)com]
Sent: Wednesday, August 17, 2005 2:53 PM


Speaking as someone with actual DKIM experience, I beg to differ.
DKIM has issues, but computational load is not one of them, not for
any modern mail system doing AV scanning and anti-spam processing.

If you are running SpamAssassin and AV on everything that hits your MX, what
you are saying is true.  That ignores the whole purpose of SPF and other
efficient authentication protocols.  The idea is to reject as much as
possible before DATA.

My logs for yesterday show that more than 86% of actual and attempted
SMTP connections never made it to DATA.

0.3% made it to DATA but were rejected there as fake bounces without
actually receiving any data - response to DATA was a 554.

After a short period of operation, your resolver has most of the keys
you need in its cache.

On a large system, I would take issue with that claim.

I can't speak for what happens on large systems as I've never run one.
What's your large system experience?

  It is inherently prone to
replay, and combined with the high computational load, make it an
irresistible DDoS vehicle as the amplification factor is enormous.

DKIM is *not* prone to replay.  Yes, you could send the exact same
message over and over in mailbomb fashion, but mailbombing is hardly a
replay vulnerability introduced by DKIM.  At most, DKIM causes an
amplification small compared to that from AV-scanning.

I think you misunderstand the attack.

I think I understand it correctly, and it's still unrelated to any
replay vulnerability.  

I stand by my assertion that DKIM causes an amplification small
compared to that from AV-scanning, and I don't consider prohibiting
attachments a suitable alternative to AV-scanning.  (Actually, I
personally wouldn't mind that, but my users wouldn't tolerate it.  I
would soon have no users.)

Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com