----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, April 20, 2006 7:46 PM
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
An apparent server fault of the signer should not have a special case
where the receive stops deferring. I agree with Mike, the
transmitter should report a delivery failure, where the faulty
equipment is then repaired once reported. It would seem rather bad
to effectively ignore such failures, especially when the alternative
may be to place the message into the junk folder.
Keep in mind that a DSN (AKA Bounce) is only activated in an Accept/Reject
mode of operation.
With a SMTP level rejection, no DSN is required simply because its not even
technically possible.
It is the Sender's job to send a DSN it its original author or technically
speaking, the return path (2821.Mail From:) once the sender sees a permanent
negative response code (55x).
The main reason this is the preferred way to reject transactions is that it
eliminates the SORBIG generation eViral Bounce Attack which uses a dual
distribution offensive concept:
Offensive #1 - Throw junk at that Wall and see what sticks
Address #1 (RCPT TO:)
Offensive #2 - Hope it finds receivers that do not check
address #1 at the SMTP level, and has a
accept/reject mode of operation and
throws the junk at someone else.
Address #2 (MAIL FROM:)
Older, larger operations with an accept all first concept runs into these
issues. Many run in this mode for scalability reasons. Many are still
running with a UUCP/SLIP mind set too. :-) I still see support reports on
"how do I stop all these bounces!?" and all it took to eliminate a good
portion of them was to turn on SMTP level Validation! "Oh, I didn't even
now that option was available."
Well, most, if not all, software do today, offer SMTP level validation
features. Whether it is the best way for one site to operate, that's a
different question.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html