On Wed February 25 2004 14:50, gnulinux@xxxxxxxxxxx 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.