On Wed February 25 2004 14:50, gnulinux(_at_)pacinfo(_dot_)com wrote:
On 25 Feb 2004 at 12:10, Dave Aronson wrote:
However, what does it gain us? Authentication that the message in
question, was indeed sent via the IETF list. What does THAT gain
us? The ability to separate it out from the spam. (Note also the
assumption that anything sent to, or at least received from, the
IETF list is NOT spam. That may hold for this list, but certainly
not for all.)
my intention is to move in the direction of accepting
only signed email. this will allow me to route
anything that doesn't include a whitelisted signature
to /dev/null. that's what having the list signed will
gain me.
That's what it gains *you individually*, because of *your* specific
plans. But that's not what the IETF is about. What does it gain J.
Random Luser, or even any notable fraction of the users or
organizations on the net? Nothing. What does it even gain the extant
subscribers of this precise list? Again, nothing.
FYI, i made no assumption that a signed list would not
contain spam. in fact, i would be surprised if it did
not.
Then the whole deal gains you next to nothing as a spam filter either.
The whole deal gains you *only* the benefit of being one step further
towards your goal of having your current legitimate contacts send you
email with whitelisted digsigs. Of course, any NEW contacts will be a
whole 'nother story.
if signature validation is positioned at the mail
server level then the tools you mentioned above can
still be used. signature validation at the mail
server level can add a header line to indicate
signature validation status. additionally, if
signature validation is located at the mail server
level you might also choose to route all unwhitelisted
mail to /dev/null so you don't have to download it.
I still don't think it's going to be worthwhile, but at least this
sounds technically feasible, though I doubt many ISPs would be willing
spend the extra cycles to check sigs for you. Go to the appropriate
Working Group, discuss the concept, find out if any related work has
yet been done, and come up with a draft telling us exactly what this
header should say, how anything else would have to modified to deal
with it, the security implications (don't forget about forgeability of
the header lines), etc. You may even get it accepted as an RFC, 'cuz
with that approach, it sounds like there MAY be some benefits to SOME
of the people whose email servers do such a thing, especially if
someone runs a server where all the accounts expect to receive only
properly signed emails. But even so, don't expect everyone, let alone
the IETF, to start signing their outbound email.
To get you started, here's what pops into my pointy little head:
The final MTA will be responsible for signature checking. All other
MTAs in the chain will not create nor, if somehow present, alter the
header line. The final MTA will insert
"X-Signature-Verification-Status: $VERSION $FINGERPRINT $STATUS".
$VERSION is a non-negative integer denoting the version number of the
header line. This is version 0. Later versions may only add to
previous versions; removing items is prohibited, so as to maintain
backward compatibility. $FINGERPRINT is the fingerprint of the key
used. $STATUS is "Success", "Failure", "Unsigned", or "Forged
$OLDSTATUS". $OLDSTATUS is again any of the above, recursively. A
"Forged" status indicates that the message arrived with an
X-Signature-Verification-Status line already in it, with a $STATUS of
$OLDSTATUS. I cannot think of any reason why this would be legitimate;
if you can, feel free to use a different indicator, but methinks it
should still be indicated. This scheme might be doable by simply
passing the email through an add-on, rather than modding the MTA
itself. The MUA, when receiving or sorting mail, could filter on that
header line the same way as any other. This includes whitelisting (or
blacklisting!) various key fingerprints.
--
Dave Aronson, Senior Software Engineer, Secure Software Inc.
Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org
(Opinions above NOT those of securesw.com unless so stated!)
WE'RE HIRING developers, auditors, and VP of Prof. Services.