Re: SMTP Transferred-By-Reference

On Nov 12, 2007, at 12:59 PM, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

> On Mon, 12 Nov 2007 10:48:00 PST, Douglas Otis said:
>
> > > 2. At best, this reduces total bytes over the but the requirement  
> > > for a notification message does not reduce the number of network  
> > > 'transactions' -- in fact it increases them by 100% or more.
> > This calculation is wrong.  You are assuming a substantial  
> > percentage of messages will be retrieved, yet the typical levels  
> > of spam would suggest otherwise.
> Note that a fairly large percentage of spam is flagged as such by  
> scanning the *body* of the message - in other words, you don't know  
> if it's spam until you fetch the data *anyhow*.
Content evaluation has required increasingly greater processing  
resources.  Analysing content now deals with structures displaying  
images demanding the resources needed to defeat Captchas.  Content  
screening needs to normalize nearly every popular attachment, such as  
PDF, DOC, WMV, etc.  Difficult cases will not reveal identifiers  
using fingerprinting algorithms either.
The TBR extension used in conjunction with coincident source  
reputation remains far more scalable than content analysis alone.   
The TBR extension offers a valid origination identifier without  
demanding added receiver resources.  Once a message has been fetched,  
the DSN path will have been assured valid as well, also without  
demanding additional receiver resources.  The TBR extension ensures  
no back-scatter while providing very high delivery integrity.   
Without TBR being used, silently dropping DSNs reduces email's  
delivery integrity.
The reputation of a message's true origination can reveal recent  
behaviour not seen only examining message content of often  
questionable validity.  Signature checking or path registration  
processing also represent DDoS vulnerabilities and demand handling  
exceptions.  The TBR extension safely provides a valid origination of  
a message, while also eliminating corner cases created by broken  
paths or signatures.
> What percent of spam are you blocking based *only* on the SMTP MAIL  
> FROM/RCPT TO data?
This question overlooks MAIL FROM is not assured as a basis for a  
decision.  Without the TBR extension, little within the message  
should be assumed valid without additional receiver analysis (which  
may offer dubious results).  In comparison, an invalid TBR is self  
correcting without demanding additional receiver resources.
While email can be rejected based upon RCPT TO being invalid, this  
also enables address harvesting.  The TBR extension can also thwart  
this tactic as well.  As you can see, this question overlooks the  
value of the TBR extension.
> That's the percentage you can avoid fetching the body - and if  
> you're smart you *currently* 4xx/5xx the transaction before you get  
> to DATA in that case, so you're not saving any network bandwidth by  
> not fetching it over a second connection.
Being able to offer temp or perm error status prior to the DATA phase  
is ideal.  The TBR extension avoids the DATA phase while also  
eliminating a need to formally assure delivery.  The TBR mode  
replaces the DATA phase with a solid identifier of a message's  
origination.  Questionable transmitters which do not offer the TBR  
extension will need to accept the resulting delay.  This delay would  
offer an incentive to implement TBR.  Better delivery integrity would  
be another incentive.
-Doug