Subject: [Asrg] Has anybody thought about using Kerberos to authenticate E-mail senders

From: Jeff_Silverman <[email-masked]>
Date: Wed, 07 Jan 2004 22:04:56 -0800

People,

	I came to this discussion late, so if this topic has been brought up
and dismissed already, please inform me.

	It occurs to me that one way to deal with the SPAM issue is to force
senders to authenticate themselves.  The sender's MTA would have to
query a kerberos server and get a ticket.  The ticket has to be sent
with the message somehow.  The receiver's MTA then checks with the
kerberos server to verify the ticket.

	Then, the receiver's MTA would handle the message according to policy
set by the receiver.  There are several possibilities:

1) The sender is unknown (this covers backwards compatibility and also
failures in the authenticator)
2) The sender authenticated as a known spammer
3) The sender authenticated as a known trusted party
4) The sender sent a fraudulent message
5) The sender authenticated but is not known to be trustworthy or
untrustworthy.

	I haven't a clue what the details of this scheme might entail.  Is
there some fatal objection I don't see?

Many thanks,

Jeff

-- 
Jeff_Silverman <[email-masked]>

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: GertJan Hagenaars <[email-masked]>
Date: Thu, 8 Jan 2004 01:19:33 -0500

Apparently, Jeff_Silverman wrote:
% People,
% 
% 	I came to this discussion late, so if this topic has been brought up
% and dismissed already, please inform me.
% 
% 	It occurs to me that one way to deal with the SPAM issue is to force
% senders to authenticate themselves.  The sender's MTA would have to
% query a kerberos server and get a ticket.  The ticket has to be sent
% with the message somehow.  The receiver's MTA then checks with the
% kerberos server to verify the ticket.
% 
% 	Then, the receiver's MTA would handle the message according to policy
% set by the receiver.  There are several possibilities:
% 
% 1) The sender is unknown (this covers backwards compatibility and also
% failures in the authenticator)
% 2) The sender authenticated as a known spammer
% 3) The sender authenticated as a known trusted party
% 4) The sender sent a fraudulent message
% 5) The sender authenticated but is not known to be trustworthy or
% untrustworthy.

ad 1.  Necessary, yes.
ad 2.  I don't think you'll every authenticate a sender as a known
spammer by themselves.
ad 3.  The "known trusted party" sounds like the peering agreement that
Microsoft / yahoo / AOL are pursuing.
ad 4.  Someone masquerading as someone else (or trying to get into
systems that do not implement the scheme properly).  Potential spammer,
depending on what they're trying to do.
ad 5.  Lots and lots of smaller companies / ISPs etc.

I think the interesting question becomes: who decides if someone is a
spammer and who decides if someone is trustworthy?  Is this different
from community updated RBLs?

CHeers,
GertJan.

-- 
+++++++++++++ -------- +++++ --- ++ - +0+ + ++ +++ +++++ ++++++++ +++++++++++++
sed '/^[when][coders]/!d         G.J.W. Hagenaars -- gj at hagenaars dot com
    /^...[discover].$/d          Remembering Mike Carty 1968-1994
   /^..[real].[code]$/!d         UltrixIrixAIXHPUXSunOSLinuxBSD, nothing but nix
' /usr/dict/words                I'm Dutch, what's _your_ excuse?