Markus Stumpf wrote:
On Tue, Dec 09, 2003 at 02:46:52PM -0500, Yakov Shafranovich wrote:
Would there be a difference if the message is forwarded through a list,
or is transfered via multiple MTAs?
No. Because MTAs add headers and zillions of maillinglists add nice
(commercial/informational) trailers or remove attachments. Same for
large companies that think adding pseudo legal disclaimers makes any
difference.
All these destroy the structure of the email. These are problems that
e.g. PGP signers noticed long ago.
The same solutions that are used in PGP and S/MIME would be applied
here, at least the message body itself. Details are still fuzzy...
Now you can add headers to the sign. Which one would you add?
Date fields? How many mailservers have broken timezones. How many
mailservers are offline for 4 hours to 7 days? Add a special tag?
So what, I use this tag with my faked headers.
In the USEFOR WG in the IETF, the current draft (section 7.1) addresses
a problem of signing headers in USENET control messages by including a
special header with the digital signature, and signing only a select set
of headers. I think that a similar approach would probably be used here,
but I don't really know for sure. The USEFOR draft can be found at (see
section 7.1):
http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-12.txt
But your underlying objection is correct - headers get changed and added
all the time. The question would be whether that will significantly
affect this scheme and how to deal with it. Signing a select group of
headers AND requiring MTAs that send signed messages to have those
headers present might be one way of it.
And the easiest solution:
a) get a Yahoo! account
b) login and send a email to joe(_at_)example(_dot_)com with the exact message
you want to spam with.
c) login as joe(_at_)example(_dot_)com and save away the messages.
d) now you have a totally legal email signed by Yahoo! itself.
e) $ sendmail -ti [some 10000 addresses] < signed.mail
Now what problem does signing solve? Ok, it solves the problem for a lot
of people, but it makes it *really* easy to "legally" spam with messages
signed by public mail service providers and these are really easy to get ;-))
It is a valid objection - I believe in cryptology this would be called
"a replay attack". One way of dealing with it is somehow authenticating
the actual SMTP transaction, which brings us back to LMAP.
I think that the document that Alan was working on, addressing different
points of the email infrastructure, might be very useful here. Also, it
might perhaps be useful to create some kind of taxonomy of what we need
to authenticate and different ways of doing so.
I think that based on all of the discussion here, it looks like all of
the technical details have either not been fully thought through yet,
and/or are not being publicly shared. So I guess we'll have to wait
until they release the full technical specs for the proposal, hopefully
addressing all of these issues.
Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord
Acton)
-------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg