On Mon, 01 Oct 2007 16:37:45 +0100, Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
This is something that I also took away from the draft. "strict" +
broken/missing
signature is much more suspicious than "all" + broken/missing signature.
My
suggestion would be to tie the "suspicion" to the expectation: eg
suspicious/strict
and suspicious/all.
Yes, I think that is the difference between "all" and "strict".
"All" means what it says. But "strict" means "We don't sent to mailng
lists; our messages are not intended to be forwarded to anyone else; they
are intended just for the recipient in the 'To' header and noone else (BTW
we sign the 'To' header). So if you don't see a valid signature FROM US,
then it is bogus, and you should throw it away".
Vicious, and even paranoid, but that's what they said :-( .
The only real solution to this problem is for B to add an
Authentication-Results header (see the Mail-Vet-Discuss mailing list),
and to incluide that header in its own signature. Maybe that is veering
off topic for this list, but at least there should be a pointer to that
sort of possibility.
This doesn't work in the abstract because Auth-res isn't necessarily
trustable across
domains, and in fact I often don't trust who produced it even if it
could be authenticated.
A member of a mailing list needs to know two things:
a) did the message come via the mailing list?
b) was it sent to the mailing list by the purported "From"?
Ideally, two signatures, both valid, would put the matter beyond doubt.
But members of mailing lists will likely trust the list maintainers, and
so may well choose to accept the indirect validation of the first
signature.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html