-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Hannah
Schroeter
Sent: dinsdag 7 december 2004 22:15
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Ignoring rejected mail?
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)?
Like I said, there is no real need to shortcut an SRS0 address any
further. But if I would, I'd likely give it a new prefix, like SRS2 or
something:
"SRS2=GVNzlx65=OR=admin(_at_)asarian-host(_dot_)net"
Or MSE0, as you suggested, :)
It would take a trivial patch to Mail::SRS to re-format that back to
standard SRS0, before processing. But I have never seen the need; SRS
addresses are short enough as they are (unless they contain obscene long
domain names).
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.
Right. But without the digest, SES is just SRS. :)
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.
If you mean to calculate a signature, preemptively, based on what you
anticipate the next hop will add, then, though possible, I do not find
that very realistic/probable. Your mails would start bouncing at the whim
of the next hop making a minute change to their blurb! Talk about
co-dependency. :)
David's assertion that mail is generally not altered in transit, is
something I cannot confirm. My own ISP, for instance, adds a
"X-Virus-Scanned" header to all mail, even those which are forwarded.
Others add SpamAssassin headers! And from an ISP point-of-view, that makes
sense, I guess: they want to add something to the headers/body which
indicates some sort of responsible anti spam/virus behavior.
And, as I explained to David, if SES has to be done at each hop which adds
a header/text, then you're better off just doing a quick SRS rewrite.
David's argument has always been that SES 'survives' the travel through
multiple hops, and thus becomes a true end-to-end verification system. I
do not share his optimism. The reason message-signing is not already a
widespread phenomenon, I believe, is partly due to precisely the reason
that you cannot (yet) reliably count on a message being 'unaltered' enough
once it reaches the recipient. See, if I follow David's somewhat
exaggerated scenarios of mail going over several .forward files (instead
of what I believe is usually just a one-step event,) then the more ho(o)ps
your mail jumps through, the less likely also it is to remain
'signature-intact'.
None of these problems are unovercomeable, per se. Like I said, and which
you indicated yourself in your other post, there are ways to do 'clever'
message signing; for one, to just include relevant headers. Doing 'fuzzy'
signing on the message body is a lot trickier, though.
Cheers,
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx