From danie.dejager@striata.com Tue Sep 16 04:28:04 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2BC1A065A for ; Tue, 16 Sep 2014 04:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 QrBEs2epU67n for ; Tue, 16 Sep 2014 04:28:03 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D241A02CF for ; Tue, 16 Sep 2014 04:28:02 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hy4so4714529vcb.23 for ; Tue, 16 Sep 2014 04:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=za.striata.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=xmnqHER1GttUSK1Ay1KriOmP/AzTSjjumVSORizAGoA=; b=UFkqPeCkr/hzMEzVdsgy+rSFC60rjlNFuLIXe0w1SkeLWuYKcG7TUCCtCo/3aTNS/P gyfoN+xb2/W3Rd4NwmD2k9t5godeBgoffVXIoxdHIEhDLXnfMSHHXxNCoEijPsI3U6D3 E6McfmPsR9cxkabULmG8kYyv1os3hZs7fu4OA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=xmnqHER1GttUSK1Ay1KriOmP/AzTSjjumVSORizAGoA=; b=AiKB5zOHTU6YJXPb0O12fN3TI0MbPX35OknGqiCZwCqsZHJk5qwr7UFtY0M3dQsPjJ Ahc7JZMv9Wym2kT6NKNybCx5EAFpi4B8RszY1hEoWbwO9bga9f2Udrl43BFS+bm2jMZs mTEGV0L6/yfxNEsb5qYbZ3YHqnm/MiEeL6/lFJZTM5Kt195lbB9ttiOZlidz8LSJXXc4 jEpCyFn7FSevL3OxLq/mDmyem0+hu443Gnme+9yKer9o9jMzL64YxRXyIKGqYJBG/RFv i3W9ynmuvzrGkhJzxH+cLsAMwK/MdxwIcTl+2sZnjtOuVUkPB+xZQsE/IzPNpg+WME5K xrdA== X-Gm-Message-State: ALoCoQkStqq8TNsaJWYc1rI2sbwiUqQd5XUXLQaoe2sqn2TqKdlNpifjNVs2tvy/oMLSGt+2lJx+ X-Received: by 10.221.23.66 with SMTP id qz2mr29559241vcb.46.1410866882196; Tue, 16 Sep 2014 04:28:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.198 with HTTP; Tue, 16 Sep 2014 04:27:42 -0700 (PDT) From: Danie de Jager Date: Tue, 16 Sep 2014 13:27:42 +0200 Message-ID: To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=001a1133375c56d5e305032d0b17 Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/NTfzdzy-qHFNy6tPE8RAobYsjEA Subject: [spfbis] Clarity on location of SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 11:29:19 -0000 --001a1133375c56d5e305032d0b17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi, I need =E2=80=8Bclarity with the =E2=80=8B possible=E2=80=8B location of the SPF record. As example. If I have a domain abc.123.example.com with a MX record of mail1.abc.123.example.com and mail2.abc.123.example.com there must be a SPF record for: mail1.abc.123.example.com to allow only its own A record mail2.abc.123.example.com to allow only its own A record and abc.123.example.com to allow the 2 MX records. or should =E2=80=8Ball =E2=80=8B the records be entered at example.com? (which performs a completely different function using other mail servers and will have it's own set of SPF rules) The RFC uses: - the domain portion of the "MAIL FROM" or "HELO" identity. Does always equal only to a fully qualified domain name? =E2=80=8BI'm investigating SPF records of some institutions that I believe = are wrong. =E2=80=8BAll their SPF records are included only in their top domain= . Regards, Danie de Jager --001a1133375c56d5e305032d0b17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi,

I need
=E2=80=8Bclarity
=C2=A0with the
=E2=80=8B possible=E2=80=8B
location of = the SPF record.

As example. If I have a domain abc.123.example.com with a MX recor= d of mail1.abc.123.example.com= and mail2.abc.123.example= .com there must be a SPF record for:=C2=A0
mail1.abc.123.example.com to allow only its = own A record
mail2.a= bc.123.example.com to allow only its own A record=C2=A0
and
abc.123.example.com to = allow the 2 MX records.

or should
=E2=80=8Ball =E2=80=8B
the records be entered at= example.com? (which performs a complete= ly different function using other mail servers and will have it's own s= et of SPF rules)

The RFC uses:
=C2=A0 = =C2=A0<domain> - the domain portion of the "MAIL FROM" or &= quot;HELO" identity.

Does <domain> alwa= ys equal only to a fully qualified domain name?

=E2=80=8BI'm investigating SPF records of some ins= titutions that I believe are wrong. =E2=80=8BAll their SPF records are incl= uded only in their top domain.=C2=A0

Regards= ,
Danie de Jager
--001a1133375c56d5e305032d0b17-- From nobody Tue Sep 16 05:36:54 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDD51A030C for ; Tue, 16 Sep 2014 05:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 2g7k5yAv1GSB for ; Tue, 16 Sep 2014 05:36:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4281A0664 for ; Tue, 16 Sep 2014 05:36:51 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8GCalsG016583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Sep 2014 05:36:50 -0700 Message-ID: <54182EDD.7030508@dcrocker.net> Date: Tue, 16 Sep 2014 05:36:45 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Danie de Jager , spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 16 Sep 2014 05:36:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/sVBJd4U7hUWFhYQk10XMx69aHyI Subject: Re: [spfbis] Clarity on location of SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 12:36:53 -0000 On 9/16/2014 4:27 AM, Danie de Jager wrote: > I need ​clarity with the ​ possible​ location of the SPF record.> > As example. If I have a domain abc.123.example.com > with a MX record of MX records are for hosts to /receive/ mail. SPF is for registering hosts that /send/. You need a record for any domain name that shows up in an rfc5321.MailFrom command. (I'm being simplistic, but this will suffice.) Under that domain, you need an SPF record that lists the IP addresses of every machine that will be an SMTP client, sending mail using that domain name in the Mail From. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 16 05:50:39 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74D1A06E7 for ; Tue, 16 Sep 2014 05:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 jeaLHPv2Af1U for ; Tue, 16 Sep 2014 05:50:35 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBB41A06E6 for ; Tue, 16 Sep 2014 05:50:35 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id BFE27956031; Tue, 16 Sep 2014 08:50:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410871833; bh=Xv+zivPzRsmJNByqtAOPfyp5XIxI7FjZj/uLBoCkoWs=; h=In-Reply-To:References:Subject:From:Date:To:From; b=RokOH1CXuCqbArTe8g76Z/PQUzrP88yLVxhseAHCwSta8UVX06H8zmt+iXu6BICF0 NJhWWx+o8VHCiINflcsLRHZGUQ/MFjSmmUU+1WA64sKi30w8LMRWFY0+DH03odTalb EhZAm+m5SjIvDhyangrcz3qLHkZkD2g4KhVar9As= Received: from [10.191.253.177] (41.sub-70-192-201.myvzw.com [70.192.201.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4AC4ED04672; Tue, 16 Sep 2014 08:50:33 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <54182EDD.7030508@dcrocker.net> References: <54182EDD.7030508@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 16 Sep 2014 08:50:29 -0400 To: spfbis@ietf.org Message-ID: <81eb5aa8-b6fc-471f-b25f-eb8e3cbd572f@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/DKG8-N0bL0w9NRq7ir-WkcWoMeo Subject: Re: [spfbis] Clarity on location of SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 12:50:37 -0000 On September 16, 2014 8:36:45 AM EDT, Dave Crocker wrote: >On 9/16/2014 4:27 AM, Danie de Jager wrote: >> I need ​clarity with the ​ possible​ location of the SPF record.> >> As example. If I have a domain abc.123.example.com >> with a MX record of > > >MX records are for hosts to /receive/ mail. > >SPF is for registering hosts that /send/. > >You need a record for any domain name that shows up in an >rfc5321.MailFrom command. (I'm being simplistic, but this will >suffice.) > >Under that domain, you need an SPF record that lists the IP addresses >of >every machine that will be an SMTP client, sending mail using that >domain name in the Mail From. Additionally, you should publish records for any domain that show up in an rfc5321.ehelo command. This is, however, rather less commonly done. The fact that SPF checking can be done for multiple identities does add complexity and is probably a source of the confusion. Scott K From nobody Tue Sep 16 05:54:22 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E481A06DE for ; Tue, 16 Sep 2014 05:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 KqVhndQfMShE for ; Tue, 16 Sep 2014 05:54:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6841A0455 for ; Tue, 16 Sep 2014 05:54:19 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8GCsGVi016823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Sep 2014 05:54:19 -0700 Message-ID: <541832F6.7030005@dcrocker.net> Date: Tue, 16 Sep 2014 05:54:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Scott Kitterman , spfbis@ietf.org References: <54182EDD.7030508@dcrocker.net> <81eb5aa8-b6fc-471f-b25f-eb8e3cbd572f@email.android.com> In-Reply-To: <81eb5aa8-b6fc-471f-b25f-eb8e3cbd572f@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 16 Sep 2014 05:54:19 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/6HWoqilvc_8QlII_ldga6h8qgT8 Subject: Re: [spfbis] Clarity on location of SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 12:54:20 -0000 On 9/16/2014 5:50 AM, Scott Kitterman wrote: > Additionally, you should publish records for any domain that show up in an rfc5321.ehelo command. This is, however, rather less commonly done. yeah. and that's why i made my summary 'simplistic'... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 16 06:03:50 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A659C1A06EC for ; Tue, 16 Sep 2014 06:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.652, T_DKIM_INVALID=0.01] 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 OFYl06iQkCVz for ; Tue, 16 Sep 2014 06:03:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E86021A06EF for ; Tue, 16 Sep 2014 06:03:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.22]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s8GD3PRr002292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2014 06:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1410872619; x=1410959019; bh=naCd9JdT8BW+sC7205lpIEHyNhcXdKepPJ1nNReG/as=; h=Date:To:From:Subject:In-Reply-To:References; b=QjCZ/M77I9K3MSA0IufqS5vO/+JcK+xqOdGVCf5Js1JPpuS3kAKTwpaVyMPG+5x0I WSEyUqrrWkOBYTIdbVGuDuRi11K2692bZMwwiRukLgIJ9TCpCfWsupv1oaFa9H3MKD x3za3cKlPzTdEWRBSKO7Vas4f01H489l8M+fKfos= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1410872619; x=1410959019; i=@elandsys.com; bh=naCd9JdT8BW+sC7205lpIEHyNhcXdKepPJ1nNReG/as=; h=Date:To:From:Subject:In-Reply-To:References; b=UYWLr5pg7jzI/H8EJxfnmDc1YS+3l0gKlkRkKIimWEcQKoGXWS37qh4pqaUnjbHVe juiJkkIEJ+fuxMuUQN6bvZMmn0/utWl7DQgTM4xftaSi3NalLa5uKW23TSsnioIQ5v qj2eTDNPI+Jh02IpK4MHLT+8mYDuKEIAuMqeTX1c= Message-Id: <6.2.5.6.2.20140916055126.064a8e88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 16 Sep 2014 06:01:55 -0700 To: Danie de Jager , spfbis@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/kG0VpIt0VyXAmUvXW8ck39drZ0Q Subject: Re: [spfbis] Clarity on location of SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 13:03:43 -0000 Hi Danie, At 04:27 16-09-2014, Danie de Jager wrote: >The RFC uses: > - the domain portion of the "MAIL FROM" or "HELO" identity. > >Does always equal only to a fully qualified domain name? is what you get in the "MAIL FROM" or "HELO". It may not be a fully qualified domain name as it is input data. >I'm investigating SPF records of some institutions that I believe >are wrong. All their SPF records are included only in their top domain. That would be what these institutions are using in the "MAIL FROM" when they send mail. They would like the receiver to accept that message if it came from a host which they authorized. Regards, S. Moonesamy From nobody Tue Sep 16 12:00:09 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3925D1A6FFB for ; Tue, 16 Sep 2014 12:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 iZNW6SZMG3I1 for ; Tue, 16 Sep 2014 12:00:03 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DE61A6F58 for ; Tue, 16 Sep 2014 12:00:02 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id la4so313334vcb.8 for ; Tue, 16 Sep 2014 12:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=za.striata.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=THTw+me20dIKPsmrA2fRhPQ5rKcFgSNqBtJHwgu6qcc=; b=Xf+DnIkoWBlxca9FRlk+Ft4dAsmfz6gjIxpEJVVcqfQyE1kUP2Ak0czPyHhFTaSUZ2 CZmIyyQxS7a3bJQdlmecjXEsTNkBWSl70k+A8heN2MoDHSHq7Lg4cuqY/ptDnRKZLzIY UjQx++lkbP1vvafcJJALx4IROQ1P89cTNia/M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=THTw+me20dIKPsmrA2fRhPQ5rKcFgSNqBtJHwgu6qcc=; b=QhYGa9o0yiCBj36g9VsZeZfgulQTLKluLoh0fgzhppy3IUas2UecnM+3f7NAbPkfVM s7R1y3TBq11UmcPm886MkaeVqpiM5CaR4hY2yCoufeHQVDD0K01HlumAlPJHltHPDg0L k4d1xl8t8qAWj6blI34fRpfOCHL6si9mKvGeuV3YFi8IW1B+KveH31DI63N1dAsRrwo/ Hl4KzovJ30R1e9Kv3TbTYvD/zRiQbItlIiE+R4Wmg/GwNm3RTAY0n6QlrmUT1nR7ql/5 KtoRx+irUnZG53QX7sgJ0sDI3TQnGK7uW4ytOKrdEpP4p5+7eH3rVxEywDjaMMbR1RPe isLQ== X-Gm-Message-State: ALoCoQnb9r/QajWUwzHPFnRsM7cDDBWfdoD4exBokYOWNioa7qcFLTM5DHOWeB+7GU8OCMHIgfKt X-Received: by 10.52.51.203 with SMTP id m11mr2702401vdo.72.1410894001686; Tue, 16 Sep 2014 12:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.198 with HTTP; Tue, 16 Sep 2014 11:59:40 -0700 (PDT) In-Reply-To: References: From: Danie de Jager Date: Tue, 16 Sep 2014 20:59:40 +0200 Message-ID: To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=001a11369114c968a50503335b01 Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/4-jX_BeP2jH962ZFUFR5pBY0SQ0 Subject: Re: [spfbis] Clarity on location of SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:00:06 -0000 --001a11369114c968a50503335b01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe what confused me is that I'm still thinking of the previous RFC4408. 3.1 . Publishing Domain owners wishing to be SPF compliant must publish SPF records for the hosts that are used in the "MAIL FROM" and "HELO" identities. The SPF records are placed in the DNS tree at the host name it pertains to, not a subdomain under it, such as is done with SRV records. This is the same whether the TXT or SPF RR type (see Section 3.1.1 ) is use= d. The example above in Section 3 might be published via these lines in a domain zone file: example.com. TXT "v=3Dspf1 +mx a:colo.example.com/28 -all" smtp-out.example.com. TXT "v=3Dspf1 a -all" *Danie de Jager* *Striata Operational Support - Team Leader* *Office:* +27 11 5309600 *Str= iata on:* Twitter | LinkedIn | Facebook | www.striata.com On 16 September 2014 13:27, Danie de Jager wrote: > =E2=80=8BHi, > > I need > =E2=80=8Bclarity > with the > =E2=80=8B possible=E2=80=8B > location of the SPF record. > > As example. If I have a domain abc.123.example.com with a MX record of > mail1.abc.123.example.com and mail2.abc.123.example.com there must be a > SPF record for: > mail1.abc.123.example.com to allow only its own A record > mail2.abc.123.example.com to allow only its own A record > and > abc.123.example.com to allow the 2 MX records. > > or should > =E2=80=8Ball =E2=80=8B > the records be entered at example.com? (which performs a completely > different function using other mail servers and will have it's own set of > SPF rules) > > The RFC uses: > - the domain portion of the "MAIL FROM" or "HELO" identity. > > Does always equal only to a fully qualified domain name? > > =E2=80=8BI'm investigating SPF records of some institutions that I believ= e are > wrong. =E2=80=8BAll their SPF records are included only in their top doma= in. > > Regards, > Danie de Jager > --001a11369114c968a50503335b01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe what confused me is that = I'm still thinking of the previous RFC4408.=C2=A0
3.1.  Publishing


   Domain owners wishing to be SPF compliant must publish SPF records
   for the hosts that are used in the "MAIL FROM" and "HELO&=
quot; identities.
   The SPF records are placed in the DNS tree at the host name it
   pertains to, not a subdomain under it, such as is done with SRV
   records.  This is the same whether the TXT or SPF RR type (see
   Section 3.1=
.1) is used.

   The example above in Section 3 might be published via these lines in
   a domain zone file:

      example.com.          TXT "v=
=3Dspf1 +mx a:colo.example.com/28 -all"
      smtp-out.example.com. TXT=
 "v=3Dspf1 a -all"
Danie=C2=A0de Jager
Striata Operational Support - Tea= m Leader
Office:=C2=A0+27 11 5309600
S= triata on:=C2=A0Twitter=C2=A0|=C2=A0LinkedIn=C2=A0|=C2=A0Facebook=C2=A0|=C2= =A0www.striata.com


On 16 September 2014 13:27, Danie de Jager <= span dir=3D"ltr"><danie.dejager@za.striata.com> wrote:
=E2=80=8BHi,

I need
=E2=80=8Bclarity
= =C2=A0with the
=E2=80=8B possible=E2= =80=8B
location of the SPF record.

As exampl= e. If I have a domain abc.123.example.com with a MX record of mail1.abc.123.example.com and mail2.abc.123.exa= mple.com there must be a SPF record for:=C2=A0
mail2.abc.123.example.com to allow onl= y its own A record=C2=A0
and
abc.123.example.com to allow the 2 MX re= cords.

or should
=E2=80=8Ball =E2=80=8B
the records be entered at example.com? (which performs a complet= ely different function using other mail servers and will have it's own = set of SPF rules)

The RFC uses:
=C2=A0 = =C2=A0<domain> - the domain portion of the "MAIL FROM" or &= quot;HELO" identity.

Does <domain> alwa= ys equal only to a fully qualified domain name?

=E2=80=8BI'm investigating SPF records of some ins= titutions that I believe are wrong. =E2=80=8BAll their SPF records are incl= uded only in their top domain.=C2=A0

Regards= ,
Danie de Jager

--001a11369114c968a50503335b01-- From nobody Tue Sep 16 12:35:24 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4D31A701A for ; Tue, 16 Sep 2014 12:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 UEVXl-05zvR7 for ; Tue, 16 Sep 2014 12:35:21 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727081A6FEF for ; Tue, 16 Sep 2014 12:35:21 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so370045vcb.10 for ; Tue, 16 Sep 2014 12:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=za.striata.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Is279H3KcjjZrFYw4q+NSSA++2b1+2zxBFMMOJzYSqk=; b=IeGDnIl8ljtjgcovn4VUBeOr5o8H1qFmmY9rpfssBkTBKAP6tKY3Ey4mQ6o+BrZmSH 9RPdGcIV0Zz1qMNtV01lwPI6sCJyG35rUdcI0NRczgxU2oonfeNd9HP/8z4GHlo4CHQS +loXvkTXFj/U5/IbLLtIT1O98fR5WWVO4QFK0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=Is279H3KcjjZrFYw4q+NSSA++2b1+2zxBFMMOJzYSqk=; b=WD8aDFBjvl5kAy6Mo1/yGgXn9DcNYgq7PyhDJwMtR8eRYYSRXSChzRa5uVB2ilZ907 6u9CuZRnDhPn41gJtd8Teuo8Q8KXZdfkMi/p8VL1YNOURbfJSVbdguggmp9pehWPC7DQ GwjxU21r6+Y+AvHOwSerzSHwO+QJSBS4O+9GgV+U9NAV/NO6fO3F3vQh8Bc9ta9qQPyy JcgILyge8bw6W0ONnwXrfmYG0G/Kz/buJ3xEnKcaHuHPyLYf7GL8LHDkGk2qRt/xVPNs QRr4TjrkP0sUQKMF++Fv/u/ykD7qjna08Oba3uY7S16UeVYpvp8oXmv6bGM+xKIVJS3H 4kzw== X-Gm-Message-State: ALoCoQnkcevL5e/A9Q044Hz7DdeY/SBExaRZuln+uHEvpejSt+J/nL2TmsPUILgL9i36D6sd0z8j X-Received: by 10.220.50.80 with SMTP id y16mr18105214vcf.50.1410896120375; Tue, 16 Sep 2014 12:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.198 with HTTP; Tue, 16 Sep 2014 12:35:00 -0700 (PDT) In-Reply-To: References: From: Danie de Jager Date: Tue, 16 Sep 2014 21:35:00 +0200 Message-ID: To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=047d7b34331e1209d2050333da0f Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/AQu7c3IuGFuNS_gu_RUhChNy2f4 Subject: Re: [spfbis] Clarity on location of SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:35:23 -0000 --047d7b34331e1209d2050333da0f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was reading an article on the forum called "too many includes". My investigation was triggered by a client who has too many includes which to me seems that they are adding their SPF records in the wrong place. (The investigation turned into a debate with no concrete answers and I took it on myself to revert back to the source.) http://www.ietf.org/mail-archive/web/spfbis/current/msg04233.html >From there Scott Kitterman states: "Super huge providers like Hotmail are able to (mostly) able publish compliant records. If they can do it, I have a hard time believing it's a problem that needs more than education to solve." Maybe this is one of the reasons SPF records get too many includes, they're all combined and added to the wrong DNS entry on the top level. I'm sure in most configurations having a SPF record in your top domain ( example.com) will be fine but as soon as multiple ESPs (esp1.example.com and esp2.eample.com) are involved for that said domain confusion can creep in. *Danie de Jager* *Striata Operational Support - Team Leader* *Office:* +27 11 5309600 *Str= iata on:* Twitter | LinkedIn | Facebook | www.striata.com On 16 September 2014 20:59, Danie de Jager wrote: > I believe what confused me is that I'm still thinking of the previous > RFC4408. > > 3.1 . Publishing > > Domain owners wishing to be SPF compliant must publish SPF records > for the hosts that are used in the "MAIL FROM" and "HELO" identities. > The SPF records are placed in the DNS tree at the host name it > pertains to, not a subdomain under it, such as is done with SRV > records. This is the same whether the TXT or SPF RR type (see > Section 3.1.1 ) is u= sed. > > The example above in Section 3 might be published via these lines in > a domain zone file: > > example.com. TXT "v=3Dspf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=3Dspf1 a -all" > > > *Danie de Jager* > *Striata Operational Support - Team Leader* *Office:* +27 11 5309600 *S= triata > on:* Twitter | LinkedIn > | Facebook > | www.striata.com > > > On 16 September 2014 13:27, Danie de Jager > wrote: > >> =E2=80=8BHi, >> >> I need >> =E2=80=8Bclarity >> with the >> =E2=80=8B possible=E2=80=8B >> location of the SPF record. >> >> As example. If I have a domain abc.123.example.com with a MX record of >> mail1.abc.123.example.com and mail2.abc.123.example.com there must be a >> SPF record for: >> mail1.abc.123.example.com to allow only its own A record >> mail2.abc.123.example.com to allow only its own A record >> and >> abc.123.example.com to allow the 2 MX records. >> >> or should >> =E2=80=8Ball =E2=80=8B >> the records be entered at example.com? (which performs a completely >> different function using other mail servers and will have it's own set o= f >> SPF rules) >> >> The RFC uses: >> - the domain portion of the "MAIL FROM" or "HELO" identity. >> >> Does always equal only to a fully qualified domain name? >> >> =E2=80=8BI'm investigating SPF records of some institutions that I belie= ve are >> wrong. =E2=80=8BAll their SPF records are included only in their top dom= ain. >> >> Regards, >> Danie de Jager >> > > --047d7b34331e1209d2050333da0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was reading an article on the for= um called "too many includes". My investigation was triggered by = a client who has too many includes which to me seems that they are adding t= heir SPF records in the wrong place. (The investigation turned into a debat= e with no concrete answers and I took it on myself to revert back to the so= urce.)
http://www.ietf.org/mail-archive/web/= spfbis/current/msg04233.html
From there = Scott=C2=A0Kitterman=C2=A0states:
"Super huge providers like Hotmail ar= e able to (mostly) able publish compliant records. =C2=A0If they can do it,= I have a hard time believing it's a problem that needs more than educa= tion to solve."

Maybe this is one of the reasons SPF records get too man= y includes, they're all combined and added to the wrong DNS entry on th= e top level.

I'm sure in most configurations having a SPF record in your = top domain (example.com) will be fine bu= t as soon as multiple ESPs (esp1.exampl= e.com and esp2.eample.com) are i= nvolved for that said domain confusion can creep in.

Danie=C2=A0de Jager
Striata Operational Support - Tea= m Leader
Office:=C2=A0+27 11 5309600
S= triata on:=C2=A0Twitter=C2=A0|=C2=A0LinkedIn=C2=A0|=C2=A0Facebook=C2=A0|=C2= =A0www.striata.com


On 16 September 2014 20:59, Danie de Jager <= span dir=3D"ltr"><danie.dejager@za.striata.com> wrote:
I believe w= hat confused me is that I'm still thinking of the previous RFC4408.=C2= =A0
3.1.  Publishing


   Domain owners wishing to be SPF compliant must publish SPF records
   for the hosts that are used in the "MAIL FROM" and "HELO&=
quot; identities.
   The SPF records are placed in the DNS tree at the host name it
   pertains to, not a subdomain under it, such as is done with SRV
   records.  This is the same whether the TXT or SPF RR type (see
   Section 3.1.1) is used.

   The example above in Section 3 might be published via these lines in
   a domain zone file:

      example.com.    =
      TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"
      smtp-out.ex=
ample.com. TXT "v=3Dspf1 a -all"

Danie=C2=A0de Jager
Striata Operational Support - Tea= m Leader
Office:=C2=A0+27 11 5309600
S= triata on:=C2=A0Twitter=C2=A0|=C2=A0LinkedIn=C2=A0|=C2=A0Facebook=C2=A0|=C2= =A0www.striata.com


On 16 September 2014 13:27, Danie de Jager <= span dir=3D"ltr"><danie.dejager@za.striata.com> wrote:
=E2=80=8BHi,

I need
=E2=80=8Bclarity
= =C2=A0with the
=E2=80=8B possible=E2= =80=8B
location of the SPF record.

As exampl= e. If I have a domain abc.123.example.com with a MX record of mail1.abc.123.example.com and mail2.abc.123.exa= mple.com there must be a SPF record for:=C2=A0
mail2.abc.123.example.com to allow onl= y its own A record=C2=A0
and
abc.123.example.com to allow the 2 MX re= cords.

or should
=E2=80=8Ball =E2=80=8B
the records be entered at example.com? (which performs a complet= ely different function using other mail servers and will have it's own = set of SPF rules)

The RFC uses:
=C2=A0 = =C2=A0<domain> - the domain portion of the "MAIL FROM" or &= quot;HELO" identity.

Does <domain> alwa= ys equal only to a fully qualified domain name?

=E2=80=8BI'm investigating SPF records of some ins= titutions that I believe are wrong. =E2=80=8BAll their SPF records are incl= uded only in their top domain.=C2=A0

Regards= ,
Danie de Jager


--047d7b34331e1209d2050333da0f--