On Aug 16, 2005, at 4:45 PM, <domainkeys-feedbackbase02(_at_)yahoo(_dot_)com>
<domainkeys-feedbackbase02(_at_)yahoo(_dot_)com> wrote:
I am guessing here that the envelope address can be included in
the signature. This allows a binding between the envelope data
and the message data. May be useful in replay detection and
provides clear indication of what is presented in the envelope
vs the data (for forensic and auditing purposes).
This idea has been kicked around a few times. You can essentially
audit the
changes in RCPT TO as the email transits the system and if an
unbroken lineage
goes all the way back to the content - you know you have a bona-fide
non-reinjected message.
There are three issues with this: First the assumption that the
first RCPT TO
is derived from 2822; second, multiple recipient mail - as an SMTP
optimization
goes away; three, BCC: mail would need to include a BCC: header.
When efforts to capture the RCPT TO prove expensive, this is only
expensive for the sender, not the recipient. Shifting burdens onto
the sender is an excellent trade-off. If each message created from
the To or Bcc headers captured the RCPT TO separately and are then
signed separately, this would not expose the Bcc list which would be
stripped. It would require that the signing process be located where
messages are disseminated.
There were already schemes looking to artificially increase burdens
on the email senders as a type of rate limiting. Perhaps the capture
of the RCPT TO could prove to have this other valid reason for
implementing such a burdensome mechanism. Should the RCPT TO not
match the captured RCPT TO, then a revocation check mechanism would
then prove important. This capturing feature would offer a warning
that this message is outside its normal channel. The alternative
that I suggested to detect the normal channel relies upon the HELO
being within the signing domain, where this too could be used in the
same manner, but at less expense for the sender. Perhaps these two
approaches could be an either/or.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org