On Fri, Feb 13, 2004 at 11:46:56AM -0500, Meng Weng Wong wrote:
It would be interesting to consider how
VERP and TMDA and TitanKey also approach this problem.
http://cr.yp.to/proto/verp.txt
I think VERP is just a generic name for rewriting the envelope sender for
each message. DJB's document describes using this to identify which member
of a mailing list a bounce belongs to, or which individual message out of a
set was bounced. He doesn't consider envelope forgery.
http://tmda.net/faq.cgi?req=all#1.12
TMDA has several mechanisms for protection of an address:
- the address can be 'dated', so it's no longer usable after a certain
time (very similar to SRS: timestamp and crypto checksum is applied)
- the address can be stamped so that it's only usable by a particular sender
- the address can be stamped with a keyword (not sure what that does;
perhaps an address variant for different groups of people you
correspond with?)
b(_dot_)candler-dated-1032297526(_dot_)da8e7f(_at_)pobox(_dot_)com # TMDA:
timestamp and chksum
I did look at TMDA once, but it was pretty complicated.
SRS seems to be better designed so that the local part doesn't need to be
escaped if it includes '-' or '+'. It also has the ability to relaying
bounces via a different machine which is quite nice and of course essential
for SPF:
srs0+da8e7f+12345+pobox(_dot_)com+b(_dot_)candler(_at_)myisp(_dot_)com
A useful application of this is that an ISP could have a separate box
dedicated to processing and validating incoming bounces (say
"(_dot_)(_dot_)(_dot_)(_at_)bounces(_dot_)myisp(_dot_)com"). In that case, all
their other receiving MTAs could
then be configured to discard bounces unless they were received via
bounces.myisp.com - which could be a simpler policy to apply than validating
the crypto checksums at each place.
http://www.titankey.com/productInfo/whatIsKM.html
This one's new to me. Looks like a basic whitelist plus challenge-response.
Cheers,
Brian.