----- Original Message -----
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, February 28, 2004 12:40 AM
Subject: [spf-discuss] Signed Envelope Sender: SRS on steroids
On Fri, Feb 27, 2004 at 11:14:38PM +0000, David Woodhouse wrote:
|
| I'm currently experimenting, as I believe I already mentioned, with
| SRS on my _own_ outgoing mail, coupled with rejecting bounces
| to my 'raw' | email address.
I am now doing the same. David talked me into it. :)
The first results, over a few days, are already astounding. Especially the
amount of dynamic IP connections has dropped significantly (I have some nice
MRTG graphs to wit). I do not fully understand why this is occuring. My
guess is the difference in response code; instead of "551 5.1.1" (Unknown
user), I now spit out "550 5.7.5".
5.7.5 = Cryptographic failure: A transport system otherwise authorized to
validate or decrypt a message in transport was unable to do so
because necessary information such as key was not available or
such information was invalid.
I'm calling this SES, for Signed Envelope Sender.
I am not sure whether the 5.7.5 extended error code really applies to SES
too. There is, of course, no RFC yet that deals with SES. :) So, the 5.7.5
code is just my choice.
N.B. To avoid being listed as RFC ignorant, I will exempt postmaster@ and
abuse@ from SES checks.
Perhaps it were a good idea to briefly discuss the response code matter a
bit. For instance, I propose the same 5.7.5 code in response to an invalid
SES signature; and "550 5.7.6" to errors like "SRS only supported in DSN!"
5.7.6 = Cryptographic algorithm not supported. A transport system
otherwise authorized to validate or decrypt a message was
unable to do so because the necessary algorithm was not
supported.
If you, or anyone else, has some feedback, I would sure appreciate it.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx