Subject: [ietf-dkim] SMTP/DKIM Handling: Adaptation Incentives

From: hector <[email-masked]>
Date: Sun, 01 Nov 2009 13:42:25 -0500

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