[Top] [All Lists]

Re: response to David?

2007-11-12 13:01:55

John Leslie wrote:


   Note the "temporary" errors listed in Section 6, e.g.

" 451 4.7.8 TBR HTTP/HTTPS mode requested for immediate acceptance

This can be an explicit graylisting message: though it doesn't say
anything about how long you'll be graylisted for not using TBR, it
is _some_ incentive to use it if you believe your message worthwhile.

I suppose.  That falls into my category of "punishing those who use
standard SMTP."


   The devil is in the details. What is the right level of incentive?

You have to think about the right threat model.  Start from the
assumption that spammers have essentially unlimited bandwidth and CPU
power.  Next assume that they're not constrained by moral, ethical or
even legal considerations.  Once you have a threat model like that,
you'll see that TBR won't help against spam.

   IMHO, deployment would start with organizations concerned enough
about their reputation to desire the archiving features of TBR.

You don't need TBR to do archiving.

Once it gets implemented in open-source MTA packages, there would
be a dribble of receivers advertising it.

I'm not sure any open-source MTA packages will want to pick this up.  In
addition to implementing SMTP, they'll now have to worry about implementing
HTTP.  Sure, there are free libraries like libcurl that you can just throw
in --- assuming their licenses are compatible with yours.

Additionally, it's difficult for the server holding the message body
to know when it's safe to delete it.  Let's say a message is sent
to 100 recipients in 37 different domains.  Should the message body
be deleted only after 100 attempts to download it?  37 attempts?
Some other number?

   In that particular case, any number picked out of thin air is about
as good as any other.

So if we fail to retrieve the URL because it has been deleted... then what?
We generate a DSN?  We silently fail?  Either approach is unpalatable;
we've just introduced a *new* failure mechanism that doesn't exist in
standard SMTP.

I wouldn't call it unreasonable to delete it
after 37, given that the URI _should_ be hard to guess, and one would
like to believe your server will be dependable. But it's more likely
it would be kept on the server for some period of _time_.

So to be safe, the server will have to keep the message around for N days
even upon successfull delivery?  Considering that one of the most annoying
headaches of running a large-scale e-mail system is clogged queues, I really
can't see this prospect having much appeal.

   We did not intend such a feature. Do understand that by the time
the receiving Mail Delivery Agent fetches the URI, the DSN path is
proven, so DSNs _could_ be sent safely for P, Q and R.

Yes, ok, but you don't need TBR to safely establish a DSN path.
If you use a MAIL FROM: rewriting scheme to detect and discard
backscatter, that would be fine -- but you can do that without any
SMTP extensions.


   In any case, I find that in practice most users have completely
lost the headers which would be helpful, and I have to reconstruct
from logs. Doug argues that for scalability we need to strictly
limit our storage responsibility for likely-unwanted email.

That makes no sense.  Existing e-mail systems store headers and entire
body and they seem to be scaling OK.  I don't think any proposal that
breaks SMTP traceability has a chance of passing.


   OTOH, AOL can add a few terabytes of storage much more cheaply
than the diffuse recipients can; and if AOL stores it, there's a
far better assurance that it'll arrive as intended. I would
expect TBR to be seen as a higher-value service -- increasing in
value as deployment increases.

Mmmm, ok.  Anyone from AOL care to comment? :-)

TBR will have essentially no value until/unless a significant
percentage of the Internet deploys it (let's say 1% of all e-mail
recipients.)  So you have a chicken-and-egg problem trying to convince
people.  I don't mean to be cruel or flippant, but this looks like a
candidate for


   Hard to say... At first blussh, that looks more like a SMTP
replacement which never reached critical mass. TBR is a SMTP
extension, which is a much simpler implementation path.

Well, not really.  It's a rather large extension with a reasonably high
cost to implement and uncertain benefits.



<Prev in Thread] Current Thread [Next in Thread>