On Wed, Dec 08, 2004 at 02:39:55PM -0500, Meng Weng Wong wrote:
smaller sites can do DB fine.
larger sites would prefer not to keep state.
Can we please discuss my proposed alternative forwarding?
I think it covers some of the objections seen, other objections could
probably also be dealt with (except David's "the world needs to change")
Basic outline, which can be beautified:
At forwarder's site:
1: mail enters the system and is delivered to the user
2: the user uses (for instance) procmail to:
2a) sign the message or encrypt it
2b) resend the message as an attachment
At final recipient's site:
3: verify the origin (is it really a forwarder; the user knows)
4: verify the message (does the user recognize its own signature)
5: loose the wrapper, deliver the message
Incoming mail on forwarder's site, as a bounce:
3: verify the signature and recognize the message as a legitimate bounce
4: unwrap, submit as bounce to the originator's site
- The forwarded message is MAIL FROM the forwarder's site, SPF success.
- Bounces are returned.
- Can be done inside a MUA, independent of MTA technology if desired
- User controlled if desired, site controlled if desired
- The final destination is kept a secret to the originator of the message,
even when the message results in a bounce
- Information is in the message itself, no need for databases, return
path rewriting etc.
Forwarding messages as an attachment can't be a problem, spamassassin
seems to work just fine with it. Automating this should also not be
a problem.
cheers,
Alex