Dave CROCKER wrote:
Of course it would be possible to devise an extension to do this - it would
actually be a pretty simple thing to define - but I'm quite skeptical as to
it's potential for deployment. Remember, for this to work the clients have to
change, but the benefits accrus to the server.
If senders would like to share in the benefit of consuming less bandwidth,
and
possibly having more immediate feedback on their traffic, they might count as
having a positive incentive.
From my perspective....
Authorization (ESMTP AUTP, IP Relay Allow, POP B4 SMTP) trumps all
smtp level secondary checks. Let them through.
So its mostly about the unsolicited anonymous sender where we have
been trying to "raise the bar" on the public SMTP channel (port 25) in
the hope to reducing, filtering or restricting bad guys.
So what are my incentives?
I am working on the basis that most MSA in the market will work on the
basis that authorized senders are less restricted.
As a sender, if the transactions calls for authentication or the IP is
allowed via some prearranged association (Smart hosting for example),
then I have less incentive to choose a different SMTP mail send logic:
if (!Session.Authorized && (Server.Support.Chunking)) {
// TRUE means Send Header Block First
return transmit_message_bdat(TRUE);
}
return transmit_message();
If the transaction is an authorized submission relay to an
unauthorized remote host, then the question is if the alternative mail
send logic will help in this acceptance process?
If the payload is large (what is large?), I might have an incentive to
look at the alternate mail send logic if its helps in continuing with
the large portion of payload.
if (!Session.Authorized && (Server.Support.Chunking)) {
if (Message.Size >= 100*1024) { // 100K ????
// TRUE means Send Header Block First
return transmit_message_bdat(TRUE);
}
return transmit_message();
If the industry evolves to giving such new send patterns "brownie"
points for acceptability, then that might help provide clients with
adaption incentives.
But as always, what are the incentives receiver to adapt to support
chunking?
If receivers are still stuck with the legacy clients, there is no
incentive for receivers to adapt to chunking.
So the only thing which continues to crop up is the industry need to
have SMTP based adaptation incentives, possible including concepts
with time based migration semantics.
IOW, give legacy systems a reason to adapt or change and then
receivers will have a reason to adapt as well. If we don't provide
adaptation incentives, then the legacy issue will always remain.
Of course, migration adaption incentives are long term prospects.
On January 1, 2013, All Email Messages are EXPECTED to have
DKIM signed messages. New ESMTP servers MAY begin to restrict
legacy transactions on public SMTP port 25.
AOL.COM and others are forcing PTR records adaption with senders. The
bitching and moaning happens, people say its not technically legal to
do this, but yet, they forced the issue.
If the IETF can establish a WORKING GROUP to discuss how the industry
can promote migration and adaption to new secured, better
client/server negotiated sessions, then I think it will help with
many things in the telecommunications world.
-
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html