Hello!
On Wed, Dec 01, 2004 at 06:43:25PM +0000, Mark wrote:
[...]
I wanted to refer to the redundancy of your specific usage of SRS
for non-forwarding (i.e. the hostname in the SRS part equals the
"forwarder" hostname after the @).
Yes, I understand this. :) But that 'redundancy' offers me something a
regular address does not: the ability to detect fake DSN's.
SES does that too.
Compare e.g. the SES format of "unique signatures":
S=XXXXXXX=admin(_at_)asarian-host(_dot_)net
That looks a lot like the short-cut SRS0 address I just came up with. :)
"SRS0=GVNzlx65=OR=admin(_at_)asarian-host(_dot_)net"
Interesting, this would even go through the SRS0 -> SRS1 step of at
least the perl Mail::SRS, as well as the reversal of that.
However, how would you distinguish this from normal SRS0 addresses (with
a hostname moved to the local part)? Counting the '=' signs? What would
you do with local-parts containing '=' themselves (which would then
guise for the original domain-to-local-part separator in the SRS0
format)? E.g. if you allow plussed users, and they put something with =
after the plus...
And...
(According to Working SES Format Definition 06, which is not current,
but I don't expect really *substantial* changes pertaining to this
argument. ok, it'd be =VXXXXXXX=local-part(_at_)domain, with X being some
time dependant "signature" and V an identifier for the exact validation
method used; not having a marker that it's SES is still under discussion
on the SES list as far as I see.)
I am glad you brought all this up, actually. Because, the way I see it,
SRS and SES can be used quite similarly. SES just adds a digest.
... Your shortcut is just similar to a SES "unique signature" (i.e. w/o
digest, but with timestamp and hash encoded), just disguising as SRS0.
So you could also call it "MSE0=GVNzlx65=OR=admin(_at_)asarian-host(_dot_)net"
(MSE = Mark's Signed Envelope), and make things a bit easier for your
parser for SRS0. ;-)
As irony would have it, though, the SES added "digest of the message,
which fully prevents an attacker from being able to re-use and existing
reverse-path with a new message," introduces a type of 'redistribution'
issue, not unlike the 'forwarding' problem the SES proponents so vocally
decry.
Right, but only in the digest variant of SES.
Namely, where mailing lists/
Mailing lists generate their own envelope sender (not even in a SRS
manner, but one that is intended to direct bounces to the list
administrator or the list software). So either the mail doesn't have SES
from that point on, or a new SES which includes the mailing list blurbs.
ISP's add their own little message
banner/Anti-Virus blurb. The trick for SES will be to keep things
sufficiently 'fuzzy', yet strict enough for the digest to be of any
relevance.
Yeah, that's right. Ok, the Anti-Virus blurb stuff is often nonsensical
anyway (it's not distinguishable from the case that a virus writes a
fake of that blurb by itself). And as SES is supposed to be created by
the submitter's MTA (not the MUA!), it could already take the ISP banner
or "this is virus free" blurb into account.
BTW, wasn't there a "without digest" signature in SES too?
Yeah, as said "unique signature" if they haven't renamed that
in-between.
Kind regards,
Hannah.