On Thu, 25 Aug 2005, Douglas Otis wrote: > > I am having some difficulty following the scenario being described, so I > will respond to what I think is being said. My apologies if I > misunderstood.
You understood pretty well. > Example.com could wait a number of days for these messages to expire, They can do this with a key rollover, but that will cause collateral damage unless they wait a few days. There isn't any other support for expiry. > Example.com could decide to discontinue the use of the account used to > send the marketing material. > Had the RCPT TO hash idea been used, then example.com could also have an > idea where not to send their next run of mail to help prevent future > occurrences Neither of these will stop Mr Vendetta's spam run. > It could be that example.com has marked each message so they know where > Mr. Vendetta obtained the initial copy, as this has been a problem in > the past. In effect they are using the revocation ID to do this. > Now to protect their reputation, Example.com issues a revocation of the > message being replayed by Mr. Vendetta. This revocation may affect the > delivery of some intended recipients, but the damage being done to their > reputation warrants this strategy. If the revocation ID is per-recipient there will be no collareral damage affecting email to other recipients. > This ignores the opportunistic identifications made possible by the > revocation-identifier. I would say "raises problems with" rather than "ignores" - my point was that the assumptions behind your opportunistic identification heuristic are not solid. > However, example.com will have recommended the bindings of the > mailbox-domain and the signing-domain which excludes the > revocation-identifier, as they completely control the use of their > domain's mail and want their mail accepted without causing any user > prompts for approval. So you'd need a more flavoursome SSP. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ ietf-dkim mailing list http://dkim.org
