ietf-smtp
[Top] [All Lists]

Re: SMTP Transferred-By-Reference

2007-11-12 11:32:43

Dave Crocker <dhc(_at_)dcrocker(_dot_)net> 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 <john(_at_)jlc(_dot_)net>