Mailing List Archive: SPF: Help

SPF and Google Groups (sending on behalf of)

Index | Next | Previous | View Threaded

jkirkwood at kclinfo

Jul 18, 2008, 8:17 AM

Post #1 of 10 (1150 views)
Permalink

SPF and Google Groups (sending on behalf of)

Dear all at SPF-help,

Conundrum:

user[at]un.org posts a message to the email list server
geneva-web-group[at]googlegroups.
Google Groups then sends a group email, marked From: user[at]un.org, but sent
using a Google mailserver.
The SPF record at un.org does not designate Google as a permitted sender.
My ISP blocks the email (dotster.com / mail3.dotsterhost.com - quite strict
on RFC and SPF imperfections, for example will <fail> on an invalid SPF
record).

Received-SPF: pass (googlegroups.com designates 209.85.146.244 as a trusted
SMTP server)
Received-SPF: fail (un.org does not designate 209.85.146.244 as a permitted
sender)

Any ideas? (Full headers of sent mail below - with sender's name changed -
email retrieved from a Death2Spam mail relay server).

Best regards,
John Kirkwood

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Date: Fri, 18 Jul 2008 02:49:21 -0700 (PDT)
From: User <user[at]un.org>
To: Geneva Web Group <geneva-web-group[at]googlegroups.com>
Subject: Web development job - paid this time...
Return-Path: <grbounce-
kig5qauaaaaznpbi2wszj0atqg4i62pa=jkirkwood=kclinfo.com[at]googlegroups.com>

Received-SPF: pass (googlegroups.com designates 209.85.146.244 as a trusted
SMTP server)
Received-SPF: fail (un.org does not designate 209.85.146.244 as a permitted
sender)

Received: from wa-out-0708.google.com (wa-out-0708.google.com
[209.85.146.244]) by death2spam.net (Death2Spam SMTP Sentinel Server v3.3.5)
for <jkirkwood[at]kclinfo.com>; Fri, 18 Jul 2008 04:50:18 -0500
Received: by wa-out-0708.google.com with SMTP id m33so826399waf.24 for
<jkirkwood[at]kclinfo.com>; Fri, 18 Jul 2008 02:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com;
s=beta; h=domainkey-signature:received:received:x-sender:x-
apparently-to:mime-version:content-type:content-transfer- encoding:received:
date
:x-ip:user-agent:x-http-useragent:message- id:subject:from:to
:x-google-approved:reply-to:sender:precedence:x- google-loop
:mailing-list:list-id:list-post:list-help:list- unsubscribe :x-beenthere;
bh=V+/a623tWuF2XIPEIRA0978cv+ROdjcp8NZzWIW/1EY=;
b=ETWkuEqj0k3b49WJo+ORSucqBSGyUWUV2DKGmX6Tt5D2B/3NxbiKyxO5 Xzh/NMA/vb
UNG0Nnm5hq5aN3UNLwAALg8GmHEwgLRB2hcc63vGdTMzVnOCWpVIaXXw6Y os9SWjPX0v
/RzcMIfBWQyKAzJjRA8Qfvmg+21Z79oa+uNhE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta;
h=x-sender:x-apparently-to:mime-version:content-type
:content-transfer-encoding:date:x-ip:user-agent:x- http-useragent
:message-id:subject:from:to:x-google- approved:reply-to:sender
:precedence:x-google-loop:mailing-list:list- id:list-post:list-help
:list-unsubscribe:x-beenthere;
b=WiR3CqLpCp5ksBz6LiqhxPE+CUtNf9cMSdAPqhgNFfI6SCml5NKLcr1K 5SGFrCzBmW
obJLtCB6ZfFWtVLbBIToXitobdBIQTFZvplOiQuK/9OXGnvjpTB4258QoS 89Lx6pn6vL
Ih6aEv0yBz2Poo3ZfSXnCNiXbywmFC38TeTCA=
Received: by 10.140.202.12 with SMTP id z12mr52147rvf.21. 1216374587656;
Fri, 18 Jul 2008 02:49:47 -0700 (PDT)
Received: by 10.106.239.31 with SMTP id m31gr799prh.0; Fri, 18 Jul 2008
02:49:36 -0700 (PDT)
X-Sender: user[at]un.org
X-Apparently-To: geneva-web-group[at]googlegroups.com
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Received: by 10.151.110.9 with SMTP id n9mr1530ybm.11.1216374561308; Fri,
18 Jul 2008 02:49:21 -0700 (PDT)
X-IP: 217.169.133.249
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .
NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.
30),gzip(gfe),gzip(gfe)
Message-ID: <cbaf6991-546a-4304-9dc9-dff97b042b5d[at]d19g2000prm.
googlegroups.com>
X-Google-Approved: user[at]un.org via email at 2008-07-18 09:49:36
Reply-To: geneva-web-group[at]googlegroups.com
Sender: geneva-web-group[at]googlegroups.com
Precedence: bulk
X-Google-Loop: groups
Mailing-List: list geneva-web-group[at]googlegroups.com; contact
geneva-web-group+owner[at]googlegroups.com
List-Id: <geneva-web-group.googlegroups.com>
List-Post: <mailto:geneva-web-group[at]googlegroups.com>
List-Help: <mailto:geneva-web-group+help[at]googlegroups.com>
List-Unsubscribe:
<http://googlegroups.com/group/geneva-web-group/subscribe>,
<mailto:geneva-web-group+unsubscribe[at]googlegroups. com>
X-BeenThere: geneva-web-group[at]googlegroups.com
X-Spam-SMTP-Helo: wa-out-0708.google.com
X-Spam-SMTP-From: grbounce-
kig5qauaaaaznpbi2wszj0atqg4i62pa=jkirkwood=kclinfo.com[at]googlegroups.com
X-Spam-SMTP-Rcpt: jkirkwood[at]kclinfo.com
X-Virus-Scanned: D2S-AV Samurai at death2spam.net; probability=0.3106
[15ms]
X-Spam-Classification: good
X-Spam-Probability: 0.3099 (blacklist=0.3468 envelope=0.3504
contents=0.2740)
X-Spam-Scanned: Death2Spam v3.3.5 at death2spam.net [1057ms]
X-Spam-File: heatherbr[at]kclinfo.com/good/d6438cf8

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

steve at teamITS

Jul 18, 2008, 8:40 AM

Post #2 of 10 (1093 views)
Permalink

RE: SPF and Google Groups (sending on behalf of) [In reply to]

John Kirkwood wrote on 7/18/2008 10:17:35 AM:

> user[at]un.org posts a message to the email list server
> geneva-web-group[at]googlegroups. Google Groups then sends a group email,
> marked From: user[at]un.org, but sent using a Google mailserver. The SPF
> record at un.org does not designate Google as a permitted sender. My
ISP
> blocks the email (dotster.com / mail3.dotsterhost.com - quite strict
on
> RFC and SPF imperfections, for example will <fail> on an invalid SPF
> record).
>
> Received-SPF: pass (googlegroups.com designates 209.85.146.244 as a
> trusted
> SMTP server)
> Received-SPF: fail (un.org does not designate 209.85.146.244 as a
permitted
> sender)
>
> Any ideas? (Full headers of sent mail below - with sender's name
changed -
> email retrieved from a Death2Spam mail relay server).

My first thought is to ask why the recipient is apparently
testing the From header? SPF doesn't protect that. Sender ID tries to
protect that. Looks to me like Google has it right and the ISP is
wrong.

http://www.openspf.org/FAQ/Envelope_from_scope

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> Date: Fri, 18 Jul 2008 02:49:21 -0700 (PDT)
> From: User <user[at]un.org>
> To: Geneva Web Group <geneva-web-group[at]googlegroups.com>
> Subject: Web development job - paid this time...
> Return-Path: <grbounce-
> kig5qauaaaaznpbi2wszj0atqg4i62pa=jkirkwood=kclinfo.com[at]googlegroups.co
>
> Received-SPF: pass (googlegroups.com designates 209.85.146.244 as a
> trusted
> SMTP server)
> Received-SPF: fail (un.org does not designate 209.85.146.244 as a
permitted
> sender)

-----
SPF FAQ: http://www.openspf.org/FAQ
Common mistakes: http://www.openspf.org/FAQ/Common_mistakes

- Steve Yates
- ITS, Inc.
- A leading authority is someone lucky who guessed right.

~ Taglines by Taglinator - www.srtware.com ~

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail

Jul 18, 2008, 9:14 AM

Post #3 of 10 (1097 views)
Permalink

Re: SPF and Google Groups (sending on behalf of) [In reply to]

John Kirkwood wrote:

> Google Groups then sends a group email, marked
> From: user[at]un.org, but sent using a Google mailserver.

Based on your header shown below this is an 2822-From,
the ordinary From header field. SPF does not operate
on the mail header, it uses the mail envelope.

IOW there's no problem, in theory... Back to reality:

> The SPF record at un.org does not designate Google
> as a permitted sender.

Yes, that's as it should be...

> My ISP blocks the email

...that's also as it should be IFF there is really an
SPF FAIL. For that your ISP should look at the HELO
and the MAIL FROM (not the 2822-From mentioned above),
based on what you found that is:

| Received-SPF: pass (googlegroups.com designates
| 209.85.146.244 as a trusted SMTP server)

That's an SPF PASS for the HELO wa-out-0708.google.com
(you see that HELO name in the Received header field).

| Received-SPF: fail (un.org does not designate
| 209.85.146.244 as a permitted sender)

*Apparently* an SPF FAIL for MAIL FROM user[at]un.org
But actually there was *no* such MAIL FROM, it was:

| Return-Path: <grbounce-kig5qauaaaaznpbi2wszj0atqg4i62pa=
| jkirkwood=kclinfo.com[at]googlegroups.com>

Line split by me. What your ISP should have checked
was the SPF policy of googlegroups.com, *NOT* un.org.
Googlegroups.com have the SPF policy:
"v=spf1 redirect=_spf.google.com"

Redirect to _spf.google.com, SPF policy:
"v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19
ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17
ip4:66.102.0.0/20 ip4:74.125.0.0/16 ?all"

The ip4:209. (etc.) covers the sending IP, the result
should have been SPF PASS. BTW, this policy never
results in a FAIL, at worst it is NEUTRAL for ?all.

Your ISP checked the wrong policy. One case where
that can happen is if a receiver confuses SPF with
Microsoft's Sender ID for the "PRA". But the "PRA"
is simplified "take 2822-Sender if it is there".

The mail had an 2822-Sender:
Sender: geneva-web-group[at]googlegroups.com

Again Googlegroups, they have no PRA policy, and if
a receiver is confused they could misinterpret SPF,
and then would get the same PASS as explained above.

Executive summary, what your ISP checks is wrong.
SPF does not work on the 2822-From, and Sender ID
PRA also does not work on the 2822-From (if there
is an 2822-Sender).

Apparently something with their SPF software or
mail setup is broken. Very badly broken. Get a
full refund and fire your postmaster broken.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

alex at ergens

Jul 18, 2008, 9:37 AM

Post #4 of 10 (1093 views)
Permalink

Re: SPF and Google Groups (sending on behalf of) [In reply to]

On Fri, Jul 18, 2008 at 05:17:35PM +0200, John Kirkwood wrote:

> user[at]un.org posts a message to the email list server
> geneva-web-group[at]googlegroups.
> Google Groups then sends a group email, marked From: user[at]un.org, but sent
> using a Google mailserver.

and, important, using "Sender: geneva-web-group[at]googlegroups.com".

> The SPF record at un.org does not designate Google as a permitted sender.

no problem. The sender is googlegroups.com

> My ISP blocks the email (dotster.com / mail3.dotsterhost.com - quite strict
> on RFC and SPF imperfections, for example will <fail> on an invalid SPF
> record).
>
> Received-SPF: pass (googlegroups.com designates 209.85.146.244 as a trusted
> SMTP server)
> Received-SPF: fail (un.org does not designate 209.85.146.244 as a permitted
> sender)
>
> Any ideas? (Full headers of sent mail below - with sender's name changed -
> email retrieved from a Death2Spam mail relay server).

Real true SPF will only look at 'mail from' in the SMTP transaction. This is
visible as the return path in the message's headers.

SPF-by-microsoft abuses SPF records and pretend they're SenderID records.
Instead of rejecting in the SMTP session before any data is sent, it will
look at the headers of a message.

I believe that, if 'Sender: ' is present, it overrides 'From: ', so google
has even overcome the problem introduced by microsoft.

> Received-SPF: pass (googlegroups.com designates 209.85.146.244 as a trusted
> SMTP server)
> Received-SPF: fail (un.org does not designate 209.85.146.244 as a permitted
> sender)

And where does it find un.org ?

> X-Sender: user[at]un.org

If microsoft's protocol states that X-Sender is more important than Sender,
then your ISP does the right thing. Else it does not.

Either way: this does not, IMHO, belong on this list. This is SPF help, not
microsoft help. Try contacting microsoft for clarification on their protocols.

HTH
Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail

Jul 18, 2008, 1:58 PM

Post #5 of 10 (1087 views)
Permalink

Re: SPF and Google Groups (sending on behalf of) [In reply to]

Alex van den Bogaerdt wrote:

>> X-Sender: user[at]un.org

> If microsoft's protocol states that X-Sender is more
> important than Sender, then your ISP does the right thing.

LOL, no, Sender ID PRA does not use X-Sender. And it also
wouldn't check the HELO, as shown in this example. I think
it was a plain broken SPF check based on the 2822-From, not
on the "X-Sender".

Guessing: Google wants to protect the mail from Sender ID
PRA confusions, therefore it adds its own Sender. There
was already an old Sender, therefore Google renamed this
to X-Sender. Because the Sender ID PRA "technique" using
a Resent-From in such cases is FUBAR.

Everybody and everything did exactly the right thing, but
the receiver checked 2822-From instead of MAIL FROM, and
that is obviously wrong.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

alex at ergens

Jul 18, 2008, 3:02 PM

Post #6 of 10 (1079 views)
Permalink

Re: Re: SPF and Google Groups (sending on behalf of) [In reply to]

On Fri, Jul 18, 2008 at 10:58:45PM +0200, Frank Ellermann wrote:

> LOL, no, Sender ID PRA does not use X-Sender. And it also
> wouldn't check the HELO, as shown in this example. I think
> it was a plain broken SPF check based on the 2822-From, not
> on the "X-Sender".

Whatever.

Point is: SPF checks (2)821, not (2)822.

We did not cause this confusion. If implementations get this wrong,
go ask at the place causing the confusion.

That this is very hard to do, with high probability of falling
on deaf ears, does still not mean the discussion belongs here.

Cheers,
Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail

Jul 19, 2008, 9:36 AM

Post #7 of 10 (1077 views)
Permalink

Re: SPF and Google Groups (sending on behalf of) [In reply to]

Alex van den Bogaerdt wrote:

> If implementations get this wrong, go ask at the place
> causing the confusion.

That was the original question, is it an implementation
getting it wrong, or something else. So far we know

* it's no problem at the old sender (un.org)
* it's no problem at the new sender (googlegroups)
* it's no problem with SPF HELO checks
* it's no problem with SPF MAIL FROM checks
* it's no problem with Sender ID confusions
* it's no problem with rejecting FAIL
* it is a bogus FAIL checking the wrong address

What we don't know is if this a broken implementation,
as in "some code got it wrong", or a broken setup, as
in "code is fine, but operator arranged for the wrong
address to be checked".

The latter case could turn out to be "code is dubious,
as it supports to do something stupid"...

> does still not mean the discussion belongs here.

IBTD because I'd like to know if this is dubious code.
If we know this we could put a warning on the SPF site.

SPF users should never have to worry about such issues,
and if an implementor confused MAIL FROM with 2822-From
(s)he belongs into a "hall of shame" on the main page -
hopefully convincing other implementors that this isn't
how they want a link to their code.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

alex at ergens

Jul 20, 2008, 6:12 AM

Post #8 of 10 (1058 views)
Permalink

Re: Re: SPF and Google Groups (sending on behalf of) [In reply to]

On Sat, Jul 19, 2008 at 06:36:41PM +0200, Frank Ellermann wrote:

> > does still not mean the discussion belongs here.
>
> IBTD because I'd like to know if this is dubious code.
> If we know this we could put a warning on the SPF site.
>
> SPF users should never have to worry about such issues,
> and if an implementor confused MAIL FROM with 2822-From
> (s)he belongs into a "hall of shame" on the main page -
> hopefully convincing other implementors that this isn't
> how they want a link to their code.

I think you know very well what I was saying, but for the off chance
that you didn't: there's one specific entity which takes our carefully
crafted SPF records and then {ab|re}uses them for their own incompatible
protocol: SenderID.

If implementors get it wrong when parsing the various headers with all
their if-then-else decisions, that's indirectly the fault of this other
protocol, not ours. Why should we provide support?

I strongly believe that anything looking at message headers (perhaps
with the exception of return-path) is SenderID and that questions on
this should be redirected to the appropriate place.

I urge all who do actually implement SenderID to mention SenderID in
their error messages/bounces, not SPF.

Right now I feel like we are an unpaid helpdesk for MS, something I
do not like very much.

Cheers
Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

jkirkwood at kclinfo

Jul 23, 2008, 11:31 PM

Post #9 of 10 (1027 views)
Permalink

RE: Re: SPF and Google Groups (sending on behalf of) [In reply to]

Dear all,

Many thanks for your clarifications and input. It turns out that the
SPF implementation was fine, but some separate processing had been
added temporarily, which interfered and has now been removed.
Apologies for the static.

However, the situation I now face is that my mail is MX relayed via
death2spam.net and then on to dotster.com, and dotster.com is
reapplying SPF as if death2spam.net were the originating MTA. (I was
assured that mail relay was allowed for the dotster.com mailservers,
although I am now told that it is not and that the only solution is to
remove the relay).

Before I go hunting for another mail provider, can anyone say whether
SPF would normally have any problems with mail relay? (I am loathe to
lose my death2spam mail filtering - it does a damn good job).

Many thanks,
John

-----Original Message-----
From: Alex van den Bogaerdt [mailto:alex[at]ergens.op.het.net]
Sent: 20 July 2008 15:13
To: spf-help[at]v2.listbox.com
Subject: Re: [spf-help] Re: SPF and Google Groups (sending on behalf
of)

On Sat, Jul 19, 2008 at 06:36:41PM +0200, Frank Ellermann wrote:

> > does still not mean the discussion belongs here.
>
> IBTD because I'd like to know if this is dubious code.
> If we know this we could put a warning on the SPF site.
>
> SPF users should never have to worry about such issues,
> and if an implementor confused MAIL FROM with 2822-From
> (s)he belongs into a "hall of shame" on the main page -
> hopefully convincing other implementors that this isn't
> how they want a link to their code.

I think you know very well what I was saying, but for the off chance
that you didn't: there's one specific entity which takes our carefully
crafted SPF records and then {ab|re}uses them for their own
incompatible
protocol: SenderID.

If implementors get it wrong when parsing the various headers with all
their if-then-else decisions, that's indirectly the fault of this
other
protocol, not ours. Why should we provide support?

I strongly believe that anything looking at message headers (perhaps
with the exception of return-path) is SenderID and that questions on
this should be redirected to the appropriate place.

I urge all who do actually implement SenderID to mention SenderID in
their error messages/bounces, not SPF.

Right now I feel like we are an unpaid helpdesk for MS, something I
do not like very much.

Cheers
Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

<!D2S:heatherbr[at]kclinfo.com/good/3a2d0b1/>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

rob.macgregor at gmail

Jul 24, 2008, 2:18 AM

Post #10 of 10 (1033 views)
Permalink

Re: Re: SPF and Google Groups (sending on behalf of) [In reply to]

On Thu, Jul 24, 2008 at 07:31, John Kirkwood <jkirkwood[at]kclinfo.com> wrote:
>
> Before I go hunting for another mail provider, can anyone say whether
> SPF would normally have any problems with mail relay? (I am loathe to
> lose my death2spam mail filtering - it does a damn good job).

See

http://www.openspf.org/FAQ/Forwarding

In short, yes, it can break forwarding and there are solutions.

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com