ietf-mailsig
[Top] [All Lists]

Re: Mailing lists and signatures (was: Re: CircleID on DomainKeys)

2004-10-28 05:01:45

On Thu, 2004-10-28 at 03:43 -0700, william(at)elan.net wrote:
My understanding is that IIMs latest proposal includes count on number of 
bytes in the text so the signature probably survive simple additionl of
text at the end. I kindof knew they would be doing it back from last IETF
but I'm not certain its enough to deal with mail lists fully.

Well it's a good start. At least it looks like it _might_ work, which
means there's a whole lot more point in implementing and testing it than
there is in doing so with DomainKeys right now, from my point of view.

Why so? I see lots of mail with both From: and Resent-From: headers, and
why should I not want to verify that the author really did write the
message?
As far as I know very few mail lists actually change "From:" and even 
fewer (is it none?) add Reset-From.

Mailing lists shouldn't and don't add Resent-From:. I'm talking about
mail resubmitted by MUAs. Often a colleague will see something on a
mailing list they suspect I'm not paying much attention to right now,
and they'll just bounce it to me directly so it lands in my inbox
instead of the neglected list folder.

We do have to be aware that some MUAs won't actually display the address
in the From: header either, mind you -- but users of really broken MUAs
are always going to have problems.

Which exactly are the MUAs that don't display From header?

I said the address in the From: header. Some MUAs, in particular
Outlook, display only the display-name without the actual address. If
could send you a mail
        From: eBay Customer Security Team <dwmw2(_at_)infradead(_dot_)org>
... and you mailer may only display the first part, without the actual
email address. 

This is another of the reasons why I think it might be saner just to
check the RFC2821 address, not the RFC2822 address(es). By the time
you've actually got it in your inbox and you personally are being asked
to spend your time on judging whether it's real or not, it's too late.
And there are enough things they can do to hide the RFC2822 address
which 'signed' the mail _anyway_. Your mailer may display the whole
From: address correctly -- but does it display the Sender:? Does it
display the Resent-Sender:?

I don't think the argument for using RFC2822 identities instead of
RFC2821 identities purely because the former are more visible really
holds a lot of water.

If we want to check RFC2822 identities in order to give us a full
end-to-end method of signing mail, which can allow for signatures at
each resubmitting stage, _that_ argument I'll buy. But to do RFC2822
signatures without actually working end-to-end in the real world doesn't
really seem worth it.

Yes, If somebody wants to verify multiple signatures - let them do it,
that is their problem not ours that they want to do extra processing.

Agreed. All we can do is make the information available. What the
recipient chooses to do with that information is their business -- we
can only offer suggestions and sample implementations. _If_ we're using
RFC2822 identities, I definitely don't think we should be limiting
ourselves to one signature on a mail.

-- 
dwmw2


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