--On 16 October 2009 10:28:01 -0400 hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
wrote:
ADSP RECORD
+=============================================+
| | UNKNOWN | ALL | DISCARDABLE |
|=============================================|
D | NONE | pass | discard? | discard |
K |-------+-----------+----------+--------------|
I | 1PS | pass | pass | pass |
M |-------+-----------+----------+--------------|
| 3PS | pass | discard? | discard |
+=============================================+
I'd reduce it to this:
ADSP RECORD
+=============================================+
| | UNKNOWN | ALL | DISCARDABLE |
|=============================================|
D | NONE | pass | reject* | discard |
K |-------+-----------+----------+--------------|
I | 1PS | pass | pass | pass |
M |-------+-----------+----------+--------------|
| 3PS | pass | pass** | discard |
+=============================================+
* reject rather than discard, so that the sender has a chance of detecting
their error. Especially true if you have an spf pass, for example, and the
domain has a reasonable reputation score.
** pass, provided the third party signature passes, and you have some
explanation for the breakage - eg, the message has been through the list.
However, in this situation, you must rely on the reputation score for the
third party signing domain, not the original signing domain or the author.
This is a case where I'd (very slightly) prefer to see a broken signature,
than none at all, I think. I might even give credence to an
authentication-results header for the original signature, if that header
were signed, and the list domain had a reasonable reputation.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html