2.1.11 MTA Authorization Records in DNS (marid) Bof

Current Meeting Report

Minutes for: MTA Authorization Records in DNS (marid), IETF 59
Held Thursday, March 4 at 0900-1130
CHAIRS: Patrik Faltstrom <paf@cisco.com>
        Ted Hardie <hardie@qualcomm.com>
Reported by: George Michaelson

Summary:  Those present came to strong consensus that the IETF should 
pursue work in the area.

Patrik Falstrom reviewed the background to the BoF, and laid the problem 
space; much of this was based on the IRTF's ASRG and the LMAP 
discussion there.  During this discussion, Patrik brought forward a model 
that describes the complexity of the modern mail stream.  This model was 
then focused on the MTA-MTA interaction which is the focus of the BoF. He 
then raised 5 questions:  will verification of the SMTP peer help?  if 
deployed, how will spammers react?  will proposals have an impact on SMTP  
relaying?  will forwards force forwarders to be more strict or 
restricted?  what sort of RRs would be useful for this?  Follow up 
questions honed the problem statement to "will verification of the SMTP 
peer help with the fraudulent domain problem" (as other SPAM problems like 
worms and virii are not at issue).  The group took this as the problem 
statement for the BoF to consider after a lively discussion of the 

Individual authors then presented solutions that have been proposed in the 
IRTF's work; not all authors were present, but all of those listed below 
were discussed at least briefly:

   MTAMARK - draft-stumpf-dns-mtamark-01.txt
   DRIP - draft-brand-drip-02.txt
   RMX - draft-danisch-dns-rr-smtp-03.txt
   DMP - draft-fecyk-dmp-01.txt
   SPF - draft-mengwong-spf-00.txt
   FSV - draft-levine-fsv-00.txt

The group noted, however that the presentation sent for 
draft-danisch-dns-rr-smtp-03.txt actually related to a different 
proposal, and that proposal was not in scope for the BoF.  Its proposer was 
not able to attend or participate remotely to discuss that issue.

Dave Crocker then presented a more general set of slides intended 
covering the deployment issues and the general difficulty of work in this 

After the presentations, the group then discussed what identity would be at 
issue for this (broadly, IPs, RFC 2821 EHLO or MAIL From, or the RFC 2822 
headers).  The group did not come to consensus on this topic (and the 
chairs did not call for it).  The group then discussed whether the 
engineering tradeoffs here are worth doing; would the resulting drop in 
email forgery be worth the protocol, engineering, and deployment 
efforts.  Once the focus was on forgery, this question was answered with a 
strong hum, and without dissent.

With the identification of a core group of people willing to put in five 
hours a week or more, the Chairs agreed to develop a charter and ask for a 
working group to be formed.


Designated Mailers Protocol - Drawbacks
Designated Mailers Protocol - Differences
Design Flaw in All LMAP Proposals
Build your own MARID proposal!
LMAP Family Tree
Role of Authentication
Rob Austein Presentation