On 25 Feb 2004 at 12:10, Dave Aronson wrote:
On Wed February 25 2004 11:50, gnulinux(_at_)pacinfo(_dot_)com wrote:
> i am very much wanting dialogue
> around the issue of having the list digitally signed
> by the list processor.
If the folks who actually run the list find themselves a spare moment to
breathe (not likely so soon before or after the meeting in Korea), it
might be fairly easy to implement.
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
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
FYI, i made no assumption that a signed list would not
contain spam. in fact, i would be surprised if it did
On the other claw, using the Sender line for that purpose has been
working just fine for me. (It's forgeable, sure, but I see no sign
that spammers have bothered to do so, and don't think it's likely that
they will in the future.) That's also trivial to set up in any decent
MUA. Same holds for the List-ID, X-Been-There, and other markers used
by most other mailing lists. Most cannot filter so easily (or at all)
on the presence/absence or [in]validity of a digsig. Sure, advanced
tools such as procmail certainly can, but many of us don't even find it
necessary to use such things at ALL yet, and they're awfully difficult
for Joe Luser to set up for his mail from RANDOM-L.
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.
Zero net gain, for at least some (and likely much) additional effort.
again, for me a significant gain, and i perceive that
generating a key pair and configuring automatic
signing of all list traffic will require a minor
amount of effort.