ietf-mailsig
[Top] [All Lists]

Re: Most recent sender.

2005-01-15 18:42:54

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


David Woodhouse writes:
On Sat, 2005-01-15 at 02:59 +0000, John Levine wrote:
Of course.  It'll be years before enough systems do signatures that
you can assume that an invalid or missing signature is more likely to
mean forgery than to mean brokenware.

If it's going to be years before we can use MASS to reject mail, then we
might as well give up on it. We have to do better than that, and I think
we _can_ do better than that.

A missing signature _can_ be assumed to mean forgery, from the moment
the sending domain first advertises that they're signing all mail. That
assumption is only going to be wrong if they cocked up and advertised
_wrongly_ that they're signing all mail when they aren't.

An invalid signature _can_ be assumed to mean forgery in the case of a
signature on a single transit through the mail system -- i.e. a
signature on the RFC2821 sender address like SES, or the bizarre 'most
recent RFC2822 sender' that seems to have been settled upon here. That
assumption is only going to be invalid in the case of an MTA mangling
the message in transit _without_ mailing lists being involved. It's not
going to be common that such mangling happens after the sending site
generates the signature and before the receiving site checks it. The
only failure mode I can really imagine is the case of an intermediate
forwarding site adding virus-checker adverts to the mail. But forwarding
sites tend not to do that in my experience; I think that's negligible.

By now, *most* forwarding sites add antivirus/antispam headers, in my
experience.

Also, what about the case where an MS Sexchange box has mangled the body,
turning text/plain into a MIME structure, as it does in my workplace? Once
it passes into Exchange, the original raw body text is lost and later sig
verification will definitely fail.   (I don't think there's any way we
could possibly avoid that, though.)

If a sig verification system is one hop beyond Exchange, or built
into an Exchange box, does that count as a new "sender"?

You're definitely trying too hard here.  If the signature verifies and
you like the signer, accept the message.  If the signature verifies
and you don't like the signer, discard the message.  If the signature
doesn't verify, treat it the way you would any other unsigned message.

If that's all I can do with it, I won't bother implementing it because
it'll give me no benefit apart from a small reduction in my
SpamAssassin-related CPU load. It doesn't let me discard anything I
wouldn't already have discarded -- since if I _don't_ like the apparent
sender I'd not have accepted the message anyway, regardless of whether
it's signed or not.

except this way, you can be sure it really *is* that sender, and not
some malware impersonating them.  ie: trustworthy whitelists.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFB6caLMJF5cimLx9ARAt6VAJ9AwX7oEXVbn8UE9il4f7ovVsLZdgCgoFUv
TDdmGaIm3UKThMOXZd9rVyI=
=B43V
-----END PGP SIGNATURE-----


<Prev in Thread] Current Thread [Next in Thread>