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 issues. 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 area. 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. |