David F. Skoll <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
