Re: What I've been wondering about the DMARC problem

Hector Santos <hsantos@isdg.net> Tue, 15 April 2014 19:48 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237301A06C4 for <ietf@ietfa.amsl.com>; Tue, 15 Apr 2014 12:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.103
X-Spam-Level:
X-Spam-Status: No, score=-100.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX2J7OGzwepB for <ietf@ietfa.amsl.com>; Tue, 15 Apr 2014 12:48:33 -0700 (PDT)
Received: from mail.santronics.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CD75D1A0186 for <ietf@ietf.org>; Tue, 15 Apr 2014 12:48:32 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4449; t=1397591306; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NUlSgojd0W1bmDjVcNlunH3lZNA=; b=VBoX9NOwhE06y0q9L3Tt 4gXqDnJ4rOVWepwwlqk2LoTxsMSAHS/kD/kjgjKYEUgEKdGTwz5YvQ0qIoZrENzg W0utgC3hXQvjzbL2eRcA0lqMQ0Nio0epLyV+UHn65E+HxtcEONP0KTd2hCNPZrFZ kM3Ibjiv85zrHLnO6rnxWTA=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Tue, 15 Apr 2014 15:48:26 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 699882339.3.2304; Tue, 15 Apr 2014 15:48:25 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4449; t=1397591236; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/ZySL0k 1Lt5s3aYXLdyIdXoVrUeC7vxUOR+mFJU4AKE=; b=1gILSAd9m75TwKTWQ+ic7KT sR8E2PyV7S3jz1AvdJWUUsXCtzmIjli2q+vTcuvb3oZoLVa7DDE/g6BHFMqMM5Ia /s24GJXJrSE2ql3A9jw3juvY5SxRS9t2lRLgn6M/FaIB/SYAD9PKTx1sihKtoBRI jsF4u7SzrTN+NZPa0WcY=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Tue, 15 Apr 2014 15:47:16 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 719412109.9.9460; Tue, 15 Apr 2014 15:47:15 -0400
Message-ID: <534D8D05.3090601@isdg.net>
Date: Tue, 15 Apr 2014 15:48:21 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "MH Michael Hammer (5304)" <MHammer@ag.com>, IETF Discussion <ietf@ietf.org>
Subject: Re: What I've been wondering about the DMARC problem
References: <53499A5E.9020805@meetinghouse.net> <5349A261.9040500@dcrocker.net> <5349AE35.2000908@meetinghouse.net> <5349BCDA.7080701@gmail.com> <01P6L9JZF5SC00004W@mauve.mrochek.com> <CAKW6Ri5f5KZyJeL7RTG2T000Qd+t61KCofNmG2JZv+nKi94Uug@mail.gmail.com> <534C0078.3070808@meetinghouse.net> <CAKW6Ri6OUmxGaBOGR2hoWpDOGWsVQ9tQ2Q9ogkT5wzFhFJLBbQ@mail.gmail.com> <534C2262.1070507@meetinghouse.net> <CAL0qLwb5p_V3i-NGhKJZBeO0qKHm1xiAq1E3nYkBzVUAXkRPpQ@mail.gmail.com> <CAKW6Ri5HWMaGMa_oLKwq5fzSUzJG=jAL1qojY1i6_tibEAxq8w@mail.gmail.com> <CAL0qLwaik1ft+AcACoc+kvKtCRt_gGvM6ov7c2yj_Uwyy3drNw@mail.gmail.com> <CAKW6Ri5_=GyOQijZMM+mqAoaEQzePGysBy9WVjN9yHO1zf3d2w@mail.gmail.com> <534C8F2B.9060903@gmail.com> <534D5516.7060902@dcrocker.net> <534D6EAA.7010100@isdg.net> <CE39F90A45FF0C49A1EA229FC9899B0507D4728F@USCLES544.agna.amgreetings.com>
In-Reply-To: <CE39F90A45FF0C49A1EA229FC9899B0507D4728F@USCLES544.agna.amgreetings.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/nbjfIZud9XokTQj-j9Y-3tpKfPY
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 19:48:39 -0000

On 4/15/2014 2:16 PM, MH Michael Hammer (5304) wrote:
>
> Just curious, what sort of statement would you like to see? How would it help with vendor planning decisions?

I think the one provided here, although a link via tumblr, appears to 
be the official Yahoo position and sufficient:

http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do


> I'm looking forward to hearing your thoughts and questions and I'm sure others do as well. Is this list the best place for this or is there somewhere else more appropriate?
>

I don't think the IETF-LIST would be the appropriate place. I would 
think Dave and Murray would take lead here, as the current IETF "reps" 
on DMARC.

> Hector, Yahoo implemented the change a week ago Friday,
> not 4 months ago. I'm sure they have received complaints.

This is a January 10, 2014 transaction for one of the yahoo.com 
subscribers to our support list getting a copy of a yahoo.com user 
mail submission:

**************************************************************************
Wildcat! ESMTP Server v7.0.454.4
SMTP log started at Fri, 10 Jan 2014  22:06:21
Connection Time: 20140110 22:06:21  cid: 00000000 tid: 144C
SSL Enabled: YES
Message Queue: d:\spool\santronics\smtp\47446W
Destination: ##############@yahoo.com
Mail Host IP: 98.136.216.26:25 (mta6.am0.yahoodns.net)
Attempt #1 LastAttempt: n/a
22:06:21.471 ** Opening Connection to host: mta6.am0.yahoodns.net ip: 
98.136.216.26:25
22:06:21.668 S: 220 mta1089.mail.gq1.yahoo.com ESMTP ready
22:06:21.669 C: EHLO secure.winserver.com
22:06:21.770 S: 250-mta1089.mail.gq1.yahoo.com
22:06:21.770 S: 250-PIPELINING
22:06:21.770 S: 250-SIZE 41943040
22:06:21.770 S: 250-8BITMIME
22:06:21.770 S: 250 STARTTLS
22:06:21.770 C: MAIL FROM:<listadmin-winserver@winserver.com>
22:06:21.884 S: 250 sender <listadmin-winserver@winserver.com> ok
22:06:21.884 C: RCPT TO:<lonehorseman82@yahoo.com>
22:06:21.987 S: 250 recipient <lonehorseman82@yahoo.com> ok
22:06:21.987 C: DATA
22:06:22.087 S: 354 go ahead
22:06:23.179 S: 554 5.7.9 Message not accepted for policy reasons. 
See http://postmaster.yahoo.com/errors/postmaster-28.html
22:06:23.180 C: QUIT
22:06:23.180 ** Completed. Elapsed Time: 1700 msecs

Its repeated for the other three yahoo.com users during a submission 
and its recorded in the last four months of logs.  Only yesterday did 
a customer post a support message he was now seeing it his Wildcat! 
List Server setup and logs.  There might have been earlier reports but 
I didn't see them.

>> I can see additional DMARC extensions for other advancements, but the
>> main one is about managing 3rd party authorized domain to satisfy the
>> "signing/sent on behalf of" design need that yahoo says is required:

> On one level there already are ways for satisfying the 3rd party authorized domain issue. A domain could use SPF (either by specifying hosts/IPs or using an include in the SPF record) for a 3rd party domain. Another method would be to provide DKIM signing keys to the 3rd party. Yet a 3rd way is to delegate a subdomain so that the 3rd party can manage these things on their own. There are some best practice documents published at maawg.org that might be useful. If what you mean is a mechanism to specify random 3rd parties that an end user wishes to use, then no there is not a mechanism and I don't know of anyone who has put forth what I would consider a workable model.
>

I have to begin reading the DMARC spec to see what are all the 
boundary conditions, but it means basically able to answer mail 
operation policy questions such as:

   o  Does the domain ever distribute mail?
   o  Do you expect the mail to be unsigned?
   o  Do you expect to sign all mail?
   o  Is your domain the exclusive signer?
   o  Are 3rd party signers allowed?
   o  Are 3rd party signers allowed to strip your original signatures?

This is an illustration of the logical flow when SSP defined policies 
were used to answer the above questions.

   http://www.winserver.com/public/ssp/ssp.htm

>>      "Yahoo requires external email service providers, such as
>>       those who manage distribution lists, to cease using unsigned
>>       “sent from” mail, and switch to a more accurate “sent on
>>       behalf of” policy."
>>
>> What is this so called "more accurate" method?
>>
>
> Not sure exactly what he means.

The 5322.From rewrite suggestion?

-- 
HLS