Murray S. Kucherawy wrote:
It could stand some revision, I suspect.
Nevertheless, the overall threat model doesn't require that
DKIM itself, i.e. the protocol being defined, also be the
thing that evaluates origin addresses for validity or value.
It's certainly legitimate to leave that to other modules, just
like SMTP isn't required to do any evaluation work of the
payload it carries. But DKIM is a key component to that
overall system.
Ahhhh, and the SMTP difference is it did not exclude it in either for
any SMTP level values and/or payload:
For the client domain, it is a REQUIRE to be valid but not a reason
for rejection (due to historical hiccups):
For the return path, it is REQUIRE to be valid yet it left the door
open. See RFC5321, section 3.3:
3.3 Mail Transactions
.....
Despite the apparent scope of this requirement, there are
circumstances in which the acceptability of the reverse-path may
not be determined until one or more forward-paths (in RCPT
commands) can be examined. In those cases, the server MAY
reasonably accept the reverse-path (with a 250 reply) and then
report problems after the forward-paths are received and
examined. Normally, failures produce 550 or 553 replies.
For the forwarding path, if you are an open relay or if you have an
old computer(s) and can't scale up or out, you just accept it. But
more modern systems do local recipient validation checks or just for
policy reason
"450 Sorry, user PDQ(_at_)PUBLIC(_dot_)COM, didn't pay his pennies this
month!"
For the Data Payload, the fact you can do a 45x/55x is an explicit
specification that for want ever reason you have, it can be
temporarily or permanently rejected. RFC2821 learned since RFC821 with
an explicit insight for delays in DATA EOD responses in section 6.1
last paragraph
To avoid receiving duplicate messages as the result of timeouts, a
receiver-SMTP MUST seek to minimize the time required to respond to
the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [40] for
a discussion of this problem.
This is all recognizing the market place increasingly doing payload
evaluations to address the highly exploited Accept/Bounce "Responsible
System" requirement.
The problem with RFC4871bis is that its locking in a specific assessor
with only one mandatory feed. It fails to say:
Despite the apparent scope of this requirement, there are
circumstances in which the acceptability of the signature may
not be determined until ODID (RFC5322.From.Domain value)
can be examined. In those cases, the verifier MAY
reasonably accept the signature (with a ADSP=PASS status) and
then pass the SDID to the Trust Assessor Module.
See the difference between the BIS for SMTP vs the BIS for DKIM? 2821
incorporated what was learned other documents since 821. Its hard to
extract 4871bis has learned from any of the current experiences
document nor ready for 2011+ operations accept only for trust.
2821 nor 5321 does not say anything about any one process output being
mandatory as a MUST for a specific any evaluation. But it was all
allowed via reply codes just giving way for state machine hooks, shims
and extensions and augmented technology - SPF for MAIL FROM and DKIM
for the DATA payload.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html