2.1.8 MTA Authorization Records in DNS (marid)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Interim Meeting - MTA Authorization Records in DNS (marid)

Last Modified: 2004-06-18

Marshall T. Rose <mrose+mtr.mxcomp@dbc.mtview.ca.us>
Andrew Newton <andy@hxr.us>
Applications Area Director(s):
Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>
Technical Advisor(s):
Rob Austein <sra@hactrn.net>
Roy Arends <roy.arends@telin.nl>
Mailing Lists:
General Discussion: ietf-mxcomp@imc.org
To Subscribe: ietf-mxcomp-request@imc.org
In Body: Subscribe
Archive: http://www.imc.org/ietf-mxcomp/index.html
Description of Working Group:
It would be useful for those maintaining domains and networks to be able to specify that individual hosts or nodes are authorized to act as MTAs for messages sent from those domains or networks. This working group will develop a DNS-based mechanism for storing and distributing information associated with that authorization.

The primary current use case for this facility is to allow recipient MTAs to confirm that peer MTAs' actions are authorized by specific domains or networks. This will help combat a certain class of domain forgery common in spam. The solution chosen, however, should be generally useful for others which might check this authorization data.

This working group is being chartered after extensive discussion of the issues in the IRTF's Anti-spam Research Group, and it is presumed that all active participants will be familiar with the documents produced there which describe the problem. It is not, however, an extension of that research group; it has no general writ to study spam or to produce specifications on the topic. It will not consider anti-spam abatement measures outside of the area of MTA authorization.

Because individual messages may be associated with multiple domains (among them the domains present in the RFC2822 From, RFC2822 Sender, the SMTP Mail-From, and the SMTP EHLO), the first task of the working group will be to establish which of these identities should be associated with MTA authorization. Once this decision has been reached, it will limit the scope of further activity in this working group, and the chairs will rule out of order discussion related to schemes which use other identities as the basis of authorization.

The groups Technical Advisors will help ensure that the semantics of proposals originating within this group are consonant with DNS standards and syntax, and they will be available for early cross-review to ensure that this work proceeds at an appropriate pace.

Upon chartering of this working group, the IESG intends to request that the IRTF Chair and the Chairs of the IRTF's Anti-Spam Research Group seek publication of the listed input documents as Experimental RFCs, so that they are available on an archival basis. The IESG also intends to request that the RFC editor insert a note into each document informing the reader that the IETF's MARID working group has taken on the task of producing a standard in this area.

Goals and Milestones:
Done  Discuss identities with which MTA authorization used for MTA authorization
Done  Interim Meeting. Focus on required semantics for MTA authorization; syntax discussions
Done  Publish one or more syntax proposals to meet required semantics
Jun 04  Final selection of syntax and document review of selected proposal
Jul 04  Working group last call
Aug 04  Submit working group document on MTA Authorization Record in DNS to PS
Aug 04  Enter FIN_WAIT
  • - draft-ietf-marid-submitter-02.txt
  • - draft-ietf-marid-core-02.txt
  • - draft-ietf-marid-csv-intro-01.txt
  • - draft-ietf-marid-csv-csa-01.txt
  • - draft-ietf-marid-csv-dna-01.txt
  • - draft-ietf-marid-rationale-00.txt
  • - draft-ietf-marid-protocol-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of the MARID Working Group Sessions

    at the 60^th IETF Meeting


    04 August 2004 09:00 ≠ 11:30 US-PDT

    04 August 2004 15:30 ≠ 17:30 US-PDT


    Marshall T. Rose mrose+mtr.mxcomp@dbc.mtview.ca.us <mailto:mrose+mtr.mxcomp@dbc.mtview.ca.us>

    Andrew Newton andy@hxr.us <mailto:andy@hxr.us>


    George Michaelson

    Peter Saint-Andre

    Jabber Logs:


    Consensus Positions:

    - From topic 3, change of the version identifier in the Sender ID record to indicate check of PRA instead of MAIL FROM.

    - From topic 5, PRA to be placed into a draft separate from draft-ietf-marid-core-02.

    - From topic 5, working group last call for draft-ietf-marid-protocol, draft-ietf-marid-submitter, and draft-ietf-marid-core will be held August 23.

    - From topic 5, alternate proposals for PRA will not be discussed until after working group last call.

    - From topic 6, accreditation proposals for Sender ID would be accepted but it had to meet the same timeline (wglc on August 23).

    - From topic 6, working group last call for CSV will being October 11.

    1) Agenda Bashing

    Andy Newton presented the agenda for both sessions and asked for any suggested modifications. None were offered.

    2) draft-ietf-marid-submitter-02

    Harry Katz gave a brief overview of Sender ID and how this draft fits into the three documents, an explanation of how SUBMITTER is to work, some example SMTP transaction using SUBMITTER, and a description of the changes in from ≠02 to ≠01. Harry then accepted questions from the floor.

    Much of the discussion about SUBMITTER centered on the possible policy of receivers to require this extension. Some participants questioned the utility of this extension because they felt spammers would obviously not implement it. Others suggested that once enough "good guys" started using SUBMITTER, spammers would be forced into using in order to get their mail delivered. There was some discussion over signaling the intent of the receiving MTA vs. having the receiving MTA clearly state rejection policy. It was pointed out that many of the participants were getting confused over the mandatory use of SUBMITTER when it differed from MAIL FROM.

    It was suggested that the word "submitter" had the wrong meaning for the purpose of the extension. Harry expressed indifference and welcomed suggestions for change.

    The room also discussed the bandwidth savings potential of SUBMITTER. Some participants claimed that small spam messages were delivered in stateless transactions that fit inside the TCP queue therefore eliminating any bandwidth savings. Others noted that spammers generally are not concerned about bandwidth when using zombies. This argument was countered with the observation that mail infrastructure for many institutions was a complex process and therefore SUBMITTER could be used to reject mail before entering a long pipeline.

    3) draft-ietf-marid-protocol-00

    Mark Lentczner presented this draft and stated there are a number of items that needed to be addressed for the next revision but claimed most were minor in nature. He started with a discussion of the ABNF had a parsing error with CIDR notation.

    Mark explained the current concern with the EXP modifier and that some people have stated that it does not adequately support internationalization. There was short discussion about URIís being the appropriate mechanism to point to internationalized messages. The possibility of a URI being a security concern was mentioned, but Mark explained that the URI would be displayed to the users of the sending domain and therefore this was a trust issue between an ISP and their customers. There was some disagreement regarding the nature of these URIís in phishing attacks. Mark pointed out that URIís in bounces occur today and therefore this would be nothing new.

    The room discussed the version identifier in the TXT record. Mark introduced the subject by explaining that most people today publish "v=SPF1" with the intention that receivers will be checking MAIL FROM and not PRA. Many participants expressed concern over the semantic meaning and suggested the version number would change. Marshall asked if anybody in the room had any serious objections to changing the version identifier; none were given. Andy directed Mark to send suggestions for the new version identifier to the list where this would be discussed.

    A long discussion on DNS issues was then undertaken by the room. Participants discussed the issues of using new DNS record types instead of TXT record types, the usage of prefixes to avoid conflicts, and the utility of wildcards. Many participants expressed concern with codifying the use of TXT records. Mark noted the definition of a new DNS record type and the eventual transition to it. Other participants related their experiences with SRV records and the inability to use them. Many in the room asked that deployment considerations be given equal consideration to architectural considerations and suggested that few were truly happy with the use of TXT records but many understood the importance of the compromise. After much discussion about wildcards, the sense of the room was that they are not as practical as they appear to be.

    4) Intellectual Property Discussion

    Andy introduced the IPR discussion with a slide asking three questions: what parts of Sender ID are covered by IPR claims, are the terms for licensing the IPR acceptable, and are there any trademark issues?

    Harry Katz was then invited to speak. In answering the questions, he stated that Microsoft claims IPR covered in draft-ietf-marid-core-02. He stated the current IPR claim with the IETF will be updated to speak of Sender ID instead of Caller ID. Regarding the licensing, he will gather feedback from the meeting to be given to Microsoft lawyers. And for the trademark, it is the opinion of Microsoft that "Sender ID" is too generic to be a valid trademark. He then solicited questions from the floor.

    During the questioning and discussion, two vendors stated that they were working with Microsoft and it was their intent that IPR for Sender ID be compatible with free software. One participant even stated that his company had found a backdoor to make defensive patents work with the GPL.

    This discussion concluded with a note from the co-chairs about how the working group would resolve this matter. Issues regarding licensing will be resolved at working group last call, but that the date set for working group last call will be final.

    5) draft-ietf-marid-core-02

    Jim Lyons presented on the changes to this draft since last revision. He then accepted questions from the floor.

    The room discussed the PRA algorithmís assumptions regarding the ordering of headers. Some participants pointed out that header ordering was already specified but not in one place.

    Some participants suggested moving the PRA algorithm out of draft-ietf-marid-core-02 and into a separate draft because they believe it is more useful. The co-chairs asked for a hum on this issue and found that there was no objection to splitting them out into two separate drafts.

    Marshall then led a discussion about the timeline for these documents. The room agreed that revisions to the documents would be published August 13 and a two-week working group last call would then start on August 23. The room also discussed the need to have draft-ietf-marid-submitter-02 go to working group last call at the same time, and it was agreed that it would.

    Some participants asked if alternative proposals or previously discussed proposals would be considered if the working group rejects the IPR license for draft-ietf-marid-core-02. It was the decision of the co-chairs that such drafts should be immediately submitted to the drafts repository but that working group discussion should only focus on the current set of drafts until it was known that draft-ietf-marid-core-02 would not go forward.

    6) CSV and Milestones

    Dave Crocker gave a short presentation on the CSV drafts and then answered a few clarifying questions.

    A short discussion was had regarding accreditation. It was asked if an accreditation draft would be accepted for the Sender ID proposals similar in nature to the DNA draft in the CSV proposals. It was the decision of the co-chairs that such a draft would be accepted if it met the same deadlines as the other Sender ID drafts: to be submitted by August 13 and to be working group last called by August 23.

    The room then discussed timelines for the CSV proposal. It was agreed upon that a working group last call for them would begin October 11.


    None received.