| A.4. Third Party Senders
|
| Another common use case is for a third party to enter into an
| agreement whereby that third party will send bulk or other mail on
| behalf of a designated author domain, using that domain in the
| RFC2822 From: or other headers. Due to the many and varied
| complexities of such agreements, third party signing is not
| addressed in this specification. The authors anticipate that
| as mail systems gain experience with DKIM, it will become
| possible to codify best practices of this and other usages
| of DKIM.
The fallacy in the "common use case" opinion stated above is that it has
limited insight and is based on the idea that a most domains may wish to
be part of a 3rd party Bulk mailer system or will part of a prior 3rd
party agreement or have a inherent TOS with 3rd party signers.
Besides the obvious security fact this introduces a security threat of
email forgery and mis-representation, the reality is such that a
majority of the domains on the internet will not intend to participate
in such 3rd party agreements nor do not wish to have any represented by
3rd party signers in any shape or form, regardless of good or bad
intentions of the 3rd party.
The exclusion of 3rd party restrictions makes it possible for ANY domain
to be abused by 3rd party mis-representation.
Proposed change:
A.4. Third Party Senders
Another common use case is for a third party to enter into an
agreement whereby that third party will send bulk or other mail on
behalf of a designated author domain, using that domain in the
RFC2822 From: or other headers.
However, this common use case has the potential to open a security
hole with 3rd party DKIM signers misrepresentation of domains.
To secure against this potential security threat, if the RFC2822
From: domain contains any the following SSP policies, the receiver
SHOULD honor these policy semantics:
DKIM=DISCARDABLE
DKIM=OPTIONAL
DKIM=DISCARDABLE is a 1st party only signing requirement and
DKIM=OPTIONAL is a 1st party only signing option.
No 3rd party signer is expected for these policies,
therefore, a message containing a 3rd party signature will
be a contradiction of the explicit domain signing practice.
With these policies, the Author
Domain is informing the receiver the message SHOULD be
not be acceptable for user delivery and they do not intend
to take any responsibility for any harm caused by accepting
this unexpected representation of their domain. It MAY be
rejected without prejudice.
In lieu of the above explicit SSP policies, due to the unknown models
available for valid 3rd party arrangements, these unknowns models
SHOULD be passed to future 3rd party signing Evaluators.
--
Sincerely
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