Matthew wrote:
1) domain.com uses a self generated private key to sign each
message that originates at one of its MTA. The signature might
On Tue, Oct 07, 2003 at 05:49:12PM -0500, Russell Kroll wrote:
This doesn't solve the problem of sending mail from random arbitrary
points on the Internet, since the mail might not emerge from one of these
trusted machines.
This is true. I sort of consider the "sending mail from
random arbitrary points on the Internet" problem to be the spam
problem.
With the solution I outlined, you would have to relay your
email through one of the trusted machines. How difficult is this?
For the average users, they type in the IP address of their ISP's MTA,
and they are done. They have already done this when they first
configured their email client. Why is this unacceptable?
How about this variant: I write some mail and sign it, then send it.
The recipient looks at the key and sees that it was signed by
0x9DC0E77E. Then it looks up the "verification server" for
exploits.org, connects, and asks if this PGP id is allowed to use
this envelope sender.
I'm a little confused about the role of "exploits.org" in your
example, and how, exactly, your example differs from the situation I
proposed.
Who controls the "verification server"? You? exploits.org?
A third party?
Since I am a valid user of that sender address, it says yes, and the
recipient can use that data in making the decision to accept or reject
the mail.
Still a little confused here... so each sender uses a PGP key?
And they have to register their PGP key with the MTA? Via SMTP? I
believe _many_ casual email users do not want to be bothered with PGP
keys.
Such a system would prevent most forging of user accounts, but it
requires a serious upgrade for the mail clients of most people.
I think this is the answer to your variant. If we could
perform an across the board upgrade of everyone's email clients, the
clients could all support intelligent white listing, transparent
cryptographic signing of messages, convenient highly accurate sorting
of email into spam and ham and many other features that would greatly
limit the pain of spam.
But we cannot expect the majority of email users to switch
clients to make spam go away.
And while your system would prevent the forging of user
accounts, it would not stop a malicious account from sending spam.
That is, the MTA/ISP would authorize emails without ever seeing them.
Since the public keys are cached, the MTA/ISP has no reliable way to
guage how much spam is being sent by each user key.
With my system, where the MTA/ISP is signing an email it is
processing, it can evaluate the email to see if it looks like spam.
This way, ISPs/MTA can deliver better information and more accuartely
be held accountable for abuse.
You'd have to get into the habit of signing all of your mails. I
for one don't go to that extreme, as you can see here. However, if
it meant the difference between getting through and being ignored or
dropped on the floor, I'd start signing my outgoing messages.
I too, have never bother to set up a crypto email system.
I've thought about, but not done it. That's why I'm looking for
systems that can be implemented at the MTA level, without requiring
the end user to do anything to benefit from the system.
Note: this doesn't address replay attacks. Someone could capture an
entire signed mail from me and spew it at other people forever. They
couldn't modify the contents, though. This doesn't seem like a big
problem, since you can spoof me and spew as much as you like right now.
Well... if the signature includes the sender address, the
recipient address, the message ID, a hash of the body and a time
expiration tag, then the spammer could send the same spam to the same
person many times for a limited period of time. But, if the
Message-ID was included in the signature, a trivial filter could block
the message by realizing that it had already delivered exactly that
message, so there was no need to deliver it again.
None of this replaces SPF. It's just another option that could be
used at the same time.
I agree. This is just a method for solving part of the
.forward problem, which is one of SPF's current weaknesses.
-Matthew.
______________________________________________________________________
matthew(_at_)syrah(_dot_)us
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡