Subject: [Tools-discuss] SPF issues & relaying on zinfandel.ietf.org

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Jul 2010 13:49:26 +0300

Hi,

Enrico and me are trying to debug a mail delivery issue that occurs when he sends email to a @tools.ietf.org alias that forwards to me (e.g., [email-masked]).

What happens is that the Nokia MX drops the incoming email:

 [email-masked]
   (generated from [email-masked])
   SMTP error from remote mail server after end of data:
   host mx2.nokia.com [147.243.177.56]: 551 5.0.0 DKIM or SPF failed

This is because telecomitalia.it publishes an SPF record with 

“Found v=spf1 record for _spf.telecomitalia.it:
v=spf1 ip4:156.54.232.99 ip4:156.54.232.100 ip4:217.169.121.4 ip4:217.169.121.5 ip4:156.54.233.200 ip4:156.54.233.201 ip4:217.169.121.20 ip4:217.169.121.21 –all”

and relay=zinfandel.tools.ietf.org [64.170.98.42] does of course not appear in that SPF record for the envelope sender [email-masked].

I'm not super knowledgable about SPF, so it may well be that the Nokia MX is misconfigured, but at least our admins claim that it isn't. Is this a configuration issue on zinfandel?

Thanks,
Lars

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 19 Jul 2010 14:48:12 +0200

Hi Lars,

> I'm not super knowledgable about SPF, so it may well be that the Nokia MX is misconfigured, but at least our admins claim that it isn't. Is this a configuration issue on zinfandel?

Me neither; but I remember that somebody who is knowledgeable about this
wrote about this problem in an IETF mail thread not too long ago.  I'll
see if I can find it.

>From what I remember, my impression is that this is partially a configuration
error (not on zinfandel, possibly on telecom italia's server) but also
partially a weakness of SPF in that it's not really up to handling the
current situation correctly.  But I'll try to find the earlier thread,
and see if that brings more enlightenment.

Alternatively maybe someone else on the list has more clue.

Best,

	Henrik

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Jul 2010 15:56:13 +0300

CC'ing Barry, who may have the expertise. (And also Enrico, whom I thought I had CC'ed earlier already. Hm.)

---

From: Douglas Otis <[email-masked]>
Date: Mon, 19 Jul 2010 08:55:22 -0700

>> Alternatively maybe someone else on the list has more clue.
Two approaches were to handle this type of issue.  Rewriting the Mail 
 From (return path) that reduces NDN integrity, or injecting a message 
header field such as resent-* where a PRA algorithm is expected.  The 
published records do not preclude a possible assumption of the latter. 
When the path of any handled message is not fully described, or when PRA 
is not always followed, the record should end with "?all" to produce a 
neutral result.

-Doug

---

From: SM <[email-masked]>
Date: Mon, 19 Jul 2010 12:00:28 -0700

Hi Lars,
At 03:49 19-07-10, Lars Eggert wrote:
>Enrico and me are trying to debug a mail 
>delivery issue that occurs when he sends email 
>to a @tools.ietf.org alias that forwards to me 
>(e.g., [email-masked]).
>

I gather that the message is not DKIM signed.

>v=spf1 ip4:156.54.232.99 ip4:156.54.232.100 
>ip4:217.169.121.4 ip4:217.169.121.5 
>ip4:156.54.233.200 ip4:156.54.233.201 
>ip4:217.169.121.20 ip4:217.169.121.21 all”
>
>and relay=zinfandel.tools.ietf.org 
>[64.170.98.42] does of course not appear in that 
>SPF record for the envelope sender [email-masked].

The SPF workaround is to have 
zinfandel.tools.ietf.org rewrite the reverse-path 
(MAIL FROM).  It's called Sender Rewriting Scheme 
and it is a way to get around SPF issues.

>I'm not super knowledgable about SPF, so it may 
>well be that the Nokia MX is misconfigured, but 
>at least our admins claim that it isn't. Is this 
>a configuration issue on zinfandel?

This is neither a configuration issue on the 
Nokia MX nor a configuration issue on 
zinfandel.  The quick fix is to ask Enrico not to 
use the telecomitalia.it email address for 
messages that may go through forwarders.

Regards,
-sm

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Jul 2010 14:05:25 -0700

The problem is caused by tools.ietf.org functioning as an 'alias' rather
than a mailing list.  An alias does "plain message forwarding", as described
in http://en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding

Solution: zinfandel.ietf.org needs to rewrite the Return-Path to something
else.  For example, zinfandel could rewrite the MAIL FROM address using the
idea from VERP (http://cr.yp.to/proto/verp.txt), so that
[email-masked] gets rewritten to
tools-bounce+enrico.marocco=[email-masked].  Zinfandel
would undo addresses those addresses in the opposite direction.

It is unfortunate that SPF continues to live on; it has lots of nasty corner
cases like this which interfere with its successful deployment.  DKIM is
superior but more complicated.

-d

> -----Original Message-----
> From: [email-masked] [mailto:tools-discuss-
> [email-masked]] On Behalf Of Lars Eggert
> Sent: Monday, July 19, 2010 3:49 AM
> To: Tools Team Discussion
> Subject: [Tools-discuss] SPF issues & relaying on zinfandel.ietf.org
> 
> Hi,
> 
> Enrico and me are trying to debug a mail delivery issue that occurs
> when he sends email to a @tools.ietf.org alias that forwards to me
> "Found v=spf1 record for _spf.telecomitalia.it:
> v=spf1 ip4:156.54.232.99 ip4:156.54.232.100 ip4:217.169.121.4
> ip4:217.169.121.5 ip4:156.54.233.200 ip4:156.54.233.201
> ip4:217.169.121.20 ip4:217.169.121.21 -all"
> 
> and relay=zinfandel.tools.ietf.org [64.170.98.42] does of course not
> appear in that SPF record for the envelope sender
> [email-masked].
> 
> I'm not super knowledgable about SPF, so it may well be that the Nokia
> MX is misconfigured, but at least our admins claim that it isn't. Is
> this a configuration issue on zinfandel?
> 
> Thanks,
> Lars
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Jul 2010 16:16:23 -0500

> superior but more complicated.

Although it appears to suffer from the same behavior under these kinds 
of circumstances, as we discussed at length on the chairs mailing list 
earlier this year.

/a

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Jul 2010 20:26:51 -0700

> > cases like this which interfere with its successful deployment.  DKIM
> > is superior but more complicated.
> 

I must have been busy skiing during that discussion.

-d