David Nicol wrote:
point by point responses below.
On 6/6/06, George Schlossnagle <george(_at_)omniti(_dot_)com> wrote:
David Nicol wrote:
> Okay, how does this grab you:
Why should a reciever expend the resources to provide templatization of
senders' mail?
receivers coddle B2C senders in order to keep them better behaved. Less
bandwidth is used by templated mass-customized mail than would be by
fully expanded mail. Rate limits can be imposed (and exceptions
sold.) The
receivers offer templatization as a carrot to encourage B2C bulk senders
migrating to the new method.
I don't buy this at all. I don't know of any receivers that I would
classify as 'coddling' large b2c senders. In general receivers don't
need to be offering carrots to large b2c senders, the stick seems to
work fine; there's been mainly stick (or future threat of stick) around
setting up DK/DKIM signing and adoption of that has been working well.
Also, if I were sending such mail, I would be concerned
that it leaves my control in a non-final state - seems a huge liability
issue on both sides of the transaction.
well-defined templatization can be considered a form of compression.
Would
you be concerned about losing control if you knew that your message was
going to pass through gzip and then, later, gunzip? (as an aside I
think there
are compressed MIME types but no ZIP SMTP extension defined at this
time, without doing any research on that point, although I expect TLS
might
offer some compression along with the encryption)
The differences in regards to content creation responsibility, interop,
liability for cretaed content etc. between doing templatization and
doing compression are hopefully obvious.
George
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg