Hector Santos wrote:
Dave CROCKER wrote:
It would also violate the DKIM specification.
Not if its a DKIM POLICY based reason. I presumed he meant RFC 5617
DKIM=DISCARDABLE|ALL where From: and DKIM-Signature: or lack there of,
headers is all that is needed.
Much like similar anti-spam (in a broad sense) specs, RFC 5617 does
not mandate a behavior. It just says
ADSP does not provide any benefit -- nor, indeed, have any effect
at all -- unless an external system acts upon the verdict, either
by treating the message differently during the delivery process or
by showing some indicator to the end recipient. Such a system is
out of scope for this specification.
Indeed, SMTP is referenced among the *Informative References* for
ADSP. It is left to the implementor's common sense to derive that
temporary errors deserve a 4xx response, and that "dkim=discardable"
calls for silently dropping --rather than rejecting-- a message.
From a normative POV, this attitude leads to a lack of
specification that may progressively thwart the design,
implementation, or even installation of new mail systems. IMHO, we
need an SMTP extension that explicitly binds anti-spam checks with
the appropriate SMTP behavior.
Failed DKIM validation is to be treated as if no signature is present.
which violates RFC 5617 DKIM=DISCARDABLE policy which would justify a
SMTP level rejection or POST SMTP message acception silent discard.
Actually doesn't. Broken signatures tantamount missing ones, which
avoids the problem of checking whether a message had actually been
remailed. Alas, "dkim=rejectable" is not provided for: this is
consistent with the current trend of undermining SMTP's reliability.