Dave Crocker <[EMAIL PROTECTED]> wrote: > > <http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=62&f=G&l=50&d=PTXT&s1=tumbleweed&p=2&OS=tumbleweed&RS=tumbleweed> > > They enforce this patents and its follow-ons very aggressively.
Thank you for the patent reference. I have only read the abstract so far, but that's enough for me to say I need to have a lawyer give his/her opinion before I can venture an opinion whether it applies. I will discuss this with Doug. > 2. At best, this reduces total bytes over the [SMTP connection?] Actually, our concern was bytes an SMTP server is responsible for buffering: this may not be much of a problem for many folks (yet), but we see it as a scaling issue which will definitely hit us if the spam volume continues to grow. (Besides, SMTP server load is highly variable, and there will be times when another megabit-per-second really hurts.) > but the requirement for a notification message does not reduce the > number of network 'transactions' -- in fact it increases them by > 100% or more. I'm not clear what "requirement" you're referring to. There is no notification message required in this SMTP extension: in fact there is a prohibition of sending DSNs before the reverse path is verified. The notification of acceptance of responsibility for the TBR _is_ fetching the reference: none of the errors mentioned are required to be sent unless the originator is considered worthy. > 3. This presumes that making a real-time decision is a current problem, > when it is not generally held to be a major factor among the anti-abuse > community. Your "community" may not be the same as mine. I take the very existence of graylisting as proof that real-time decisions are often impractical. > 4. It presumes that users can make the right decision. Actually, the TBR extension protocol leaves _no_ decisions to the user (unless you read the part about " " MAY prepend any additional trace headers to a notification sent to " the recipient containing the eXAM-URI itself, along with any other " appropriate information. in Section 3.2 to be asking the user to decide something). > Experience is pretty clear that that's too often not a correct > presumption. Agreed: IMHO very few users can make the right decision about spam more than 99% of the time. Many users miss that mark by more than one order of magnitude. ;^) > In addition, having users be required to make this decision burdens > them far more than is felt to be useful. I agree. That's why we don't ask for it: the MAY cited above is a sop to the users who worry themselves silly about missing _one_ legitimate email in the heap of spam. > (This is a derivation of the transaction cost item, above, except > that it moves the decision-making from a receive-side front-end > filter to the human user. And of course, it them requires them > to wait for the message to show up. (I don't think this applies, but I'm willing to be shown otherwise.) > 5. Doesn't work so well for disconnected users. The extension envisions the fetching being done by a Mail Delivery Agent (which presumably is well connected). But the fetching clearly could be done earlier in the chain... -- John Leslie <[EMAIL PROTECTED]>
