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 http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5 [...] > 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. Regards, David.
