Matthew Parke Bostrom <[EMAIL PROTECTED]> writes: > On Wed, Sep 17, 2003 at 04:35:07PM -0500, Tim Legant wrote: > > > This system is unable to distinguish between mail from a new sender > > and challenges generated by other C/R users who received SPAM with a > > forged envelope sender. > > I would actually use multiple headers so this is not a > problem. > > Let me walk you through an example. > > I send you a message. It has the following header: > > X-TMDA-Message-Id: MSG11111.abcdefg
That's great. I don't use TMDA. I use CR-of-the-month, hereafter CROM. How does CROM know what an X-TMDA-Message-Id is? Is this just an accidentally confusing example? Do you expect the standard to define this header in a non-C/R-specific way, like X-Generic-CR-Message-Id (bad name, but I'm not feeling particularly creative at the moment and it conveys what I mean)? I think it would have to.... > You receive the message. TMDA challenges it because I am not > on your white list. The challenge message contains the following > headers: > > X-TMDA-Message-Id: MSG22222.aeiouy > X-TMDA-Challenge-Id: MSG1111.abcdefg Same problem, I assume the same solution (the standard defines specific header names). Also, no headers are copied to new messages in general mail handling. Passing these cookies back and forth would have to be part of the standard. > My TMDA receives the message from your TMDA. My TMDA sees the > X-TMDA-Challenge-Id. It knows that the message is a challenge. It > knows it does not need to send the message to me. It needs to either > Affirm or Disown the message. My TMDA looks at the anaylizes the > X-TMDA-Challenge-Id to see if it is cryptographically valid. (The > signature on the X-TMDA-Challenge-Id could also include "To" address, > the "Subject" and the "Date", so that spammers would not be able to > reuse a X-TMDA-Message-ID that I would always validate. Or, > alternatively, I colud keep a database of all the X-TMDA-Message-ID I > had generated and match challenges against that database. Whatever - > the exact implementation does not matter, and I can always beef it up > later.) Probably a signature would be best. Maintaining a database seems unnecessarily complex, unless it can solve problems that a well-chosen signature/fingerprint can't. > Okay if my TMDA decide to Affirm the message, it sends you a > message with: > > X-TMDA-Message-Id: MSG33333.bcdfgh > X-TMDA-Affirm-Id: MSG11111.abcdefg > > Your TMDA recieves the message. It sees the X-TMDA-Affirm-Id > and knows it does not neet to challenge the message. If the > X-TMDA-Affirm-Id message matches the id of a pending message, that > message is delivered. If there is no matching id, the affermation > email is deleted. > > Alternatively, my TMDA could disown the message with: > > X-TMDA-Message-Id: MSG44444.zyxwvu > X-TMDA-Disown-Id: MSG11111.abcdegf > > Your TMDA could automatically process this message, as well. > TMDA knows it does not need to challenge this message. Yup, I agree, presuming a standard that specifies header names and to which, at the very least, the major C/R systems adhere. Robin's original question was about someone who gets joe-jobbed and, given the relative rarity of C/R systems in use, most likely that person won't be running one. Neither this idea nor any other I've ever heard solves that problem. If, as you suggested before, C/R becomes more of an ISP-level thing, that may change. > > Without a standard it will be even more difficult/expensive for > > spammers to maintain software that identifies and properly replies > > to many, varied types of challenges. This is also a good thing. > > Without a standard: > > * C/R does not interoperate with mailing lists and automated > mailings. I'm not sure how C/R could interoperate with mailing lists. If the list sender address is whitelisted, how can you distinguish between meaningful list messages and garbage posted by some spammer? Or is that not what you meant? > * Humans have to manually respond every challenge. And human C/R users can take steps to reduce the number of challenges their system generates. TMDA provides some useful tools for that. > * Only savvy users, who understand all the different types of > disposable email addresses can use C/R effectively. The tagged addresses that TMDA can generate are useful but not an integral part of a pure C/R system. There's no doubt that use of them does require a somewhat savvy user, though. > * C/R cannot become a solution that everyone can use. Quite possibly. > If that is what you want C/R to be, then you do not need a > standard. Which, BTW, is a totally acceptable position to take. I don't so much take a position as make a pragmatic observation. I think it's unlikely that C/R systems will become ubiquitous and therefore there is not a strong impetus toward a standard. It would be nice to be wrong. Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
