David F. Skoll <dfs(_at_)roaringpenguin(_dot_)com> wrote:
John Leslie wrote:
http://datatracker.ietf.org/drafts/draft-otis-smtp-tbr-ext
But what incentives do spammers have to use this extension?
Good question! Quite possibly none...
As long as normal SMTP exists, I doubt that this will do anything to
reduce spam unless we somehow punish senders who do *not* use the
extension.
You may be right...
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.
(Actually, of course, being a temporary error, most users probably
wouldn't even see it: it would be seen by an MTA manager scanning the
logs. If users actually _did_ see it, it might lead to some irate
tech-support calls...)
And that, IMO, is not a good idea.
The devil is in the details. What is the right level of incentive?
IMHO, deployment would start with organizations concerned enough
about their reputation to desire the archiving features of TBR.
Once it gets implemented in open-source MTA packages, there would
be a dribble of receivers advertising it.
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. 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_.
There is no way I can see to give feedback to the server that "Yes,
I take responsibility for delivering this message to recipients
X, Y and Z (but not P, Q and R.)"
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.
Making trace headers optional is asking for trouble. It makes
diagnosing mail problems nightmarish.
I tend to agree with you; Doug does not...
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.
Personally, I'm happy enough to leave it optional, though I'd
be unhappy to see an implementation which didn't allow keeping the
headers.
If a TBR message is not fetched, how long should the server hang
on to it? Suppose you're AOL or Hotmail and in the business of
sending several billion e-mails per day... what implications does
implementing TBR have on your storage requirements?
Considerable impact, IMHO.
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.
As for how long -- that's likely to track how long you keep
trying graylisted emails. I'd keep them at least long enough to
be able to notify users that we've stopped trying.
This looks more-or-less like a reinvention of
http://cr.yp.to/im2000.html
and will probably meet with the same level of enthusiasm.
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.
--
John Leslie <john(_at_)jlc(_dot_)net>