[Top] [All Lists]

Re: SMTP Transferred-By-Reference

2007-11-13 17:06:30

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.