Mailing lists have to resend it as their own outgoing message anyway. It is
not really necessary to preserve all the signatures through the re-mailing
process.
I disagree. The signatures are important to validate the email, we're
not expecting mail list to get rid of S/MIME or PGP signature are we?
In fact if they did, a lot of people would complain that their email
is not properly seen by the recepient can not be validated.
Also in reality, mail list is just one type of forwarder that forwards
email to multiple recepients and adds additional identification information
regarding its processing stage. We need to either support forwarders (all
types of them) or we end up with signature that can only deal with email
going directly from sender to recepient which is not reality of real world
email system.
So when considering if we want to support mail lists, it comes back to
if we want to support on-hop only signature validation system or if
want to build true end-end signature system. If we want to built one-hop
only cryptographic system, then I suggest we don't bother with signatures
and just focus or communication channel and require TLS and provide means
of validating certificates between different servers. If we want to build
true end-end system, then signature added by any one servers in email path
should survive the transmission and it be possible to validate it by any
other server in the email path.
The mailing list could validate the signature on the incoming
message, add a header or even body line indicating that fact and sign it on
the way out.
Mail lists are going to validate signature as well as any other mail server
at some future point. But lets for a moment consider situation in the adoption
process where not everyone supports new signature system. Lets say I'm early
adoptor and my mail server added signature to my email. When I email
somebody signature is there and destination server can validate it.
Lets say that there are servers in between that don't support signature
system but if email is not changed (only forwarded with no changes in the
body) then the destination can still verify the message. This is a clear
benefit to early adaptors that it is not necessary for ENTIRE email system
to be upgraded. It also allows to not only rely on signature as a whitelist
but go futher as envisoned we are expecting to reject email with bad signature.
Additionally we're expecting in some future point early adaptors whose servers
are always adding the signature would public that as part of the policy record.
In that case, the recepient is expected to reject the message if it does not
contain a valid signature from the sender.
The problem is that this does not work with email lists. If instead of a
forwarder we have a mail list, then email is going to be changed in such
a way that signature verification would fail. So early adaptor can not
really publish that all his servers are adding signatures. Nor can early
adaptor expect that emails that are frudelently using his name are going
to be rejected, so all phishing and forging would still continue.
I don't really see the need for the end user to be able to
absolutely validate the identities on mailing list posts at the MUA. That
sounds like a list function. Lists do it now by the submitting address
(broken ones use the return-path), so they can switch to validating
signatures instead.
I disagree. I also would point out that mail lists are expected to carry
cyrptographic signature forward and so both S/MIME and PGP signatures
survive mail list posts and if they did not many people would object.
The idea that all MUA's would have to change to deal with displaying
multiple signed parts in different colors, as well as noting parts whose
signature doesn't validate does not bode well for adoption.
I agree with you that it does not sound good. I see it more as an advanced
function for somebody who really wants to examine the email message.
But MUAs can still choose to display signature and verified sender whose
data compromises majority of the email and this is usefull in identifying
possible forgeries and reuse of email signature. I however think that such
scenarios can be stopped by cryptographic mechanisms that relay on other
data to verify if its original transmission and that good filter at MDA
will identify forgery attempts.
I suggest we don't have to allow additions at all, in any of the MIME parts.
I agree. MIME part should stay as is, if somebody wants to add new data,
it should be done as new MIME part.
The irritating virus scan adverts in the message body are usually put on at
the originating or destination ends, so the signatures can be created after
the addition and validated before any subsequent addition.
Also agree here. I don't think virus scanners are a problem is signature
verification is done on proper level (MSA after Virus scan or MDA before it).
Any forwarder that puts anything in the message body rather than the
headers deserves to have his messages rejected.
As I indicated, mail lists are type of forwarders where message is forwarded
to more then one recepient. There are very legitimate reasons whey forwarders
may want to or need to change headers.
That will break virtually any signature scheme,
It will not break "MTA Signatures" system as verification will still work
if there were changes in email headers or if there was additional text
added at the end as part of body (or in the beginning if it was part of
text body and all mime parts are separately signed).
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/