Subject: Re: [Tools-discuss] SPF rejection of mail to chairs

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Feb 2020 18:18:20 +0100

Generic, undirected PING…

Grüße, Carsten

> On 2019-12-20, at 18:33, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Robert,
> 
>> On Dec 20, 2019, at 17:16, Robert Sparks <[email-masked]> wrote:
>> 
>> Hi Carsten -
>> 
>> We're aware of this problem. Unfortunately there is not any quick fix for it.
>> 
>> The path through the mail processing chain for the aliases is very different than the path for the mailing lists, and the way we are applying the current workaround isn't applicable there.
> 
> I suspected so.
> 
> A lot of our processes are set up to make use of the aliases, so in the end this creates  (hidden-terminal like) problems for these as well.
> 
> I’m not sure the majority of mail servers are set up to report SPF failures as delivery status, so I’m not even sure I know the extent of this problem.  (So far, I have often resorted to the explanation that some people are too lazy to read my mail, but maybe SPF vs. forwarding is the real problem.)
> 
>> We are discussing what we can do instead.
> 
> I wonder if there is a way to stay informed about the progress of issues like this (that are not naturally rooted in the issue tracker of some piece of software).  I mostly brought this up again on the list because I have no visibility.
> 
> (I also need a better workaround.  I wonder if I need to move to sending IETF mail from a mail account with a ~all SPF setting, like it’s 2014 again…  Maybe I can just manually set my From address to cabo=[email-masked]?)
> 
> Grüße, Carsten
> 
> [1]: https://en.wikipedia.org/wiki/Hidden_node_problem
> 
>> 
>> RjS
>> 
>> On 12/20/19 1:14 AM, Carsten Bormann wrote:
>>> On Nov 21, 2019, at 10:52, Michael Richardson <[email-masked]> wrote:
>>>>> Is there a need for the DMARC hack for the chair aliases, too?
>>>> Oh crap, yes we do.
>>>> and on all of the Internet-draft author lists.
>>> Just fell into the trap again (on a draft…@ietf.org alias).
>>> 
>>> Where do I need to report this bug to so it gets addressed?
>>> 
>>> Grüße, Carsten
>>> 
>>> ___________________________________________________________
>>> Tools-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>> 
>>> Please report datatracker.ietf.org and mailarchive.ietf.org
>>> bugs at http://tools.ietf.org/tools/ietfdb
>>> or send email to [email-masked]
>>> 
>>> Please report tools.ietf.org bugs at
>>> http://tools.ietf.org/tools/issues
>>> or send email to [email-masked]
>> 
>> ___________________________________________________________
>> Tools-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>> 
>> Please report datatracker.ietf.org and mailarchive.ietf.org
>> bugs at http://tools.ietf.org/tools/ietfdb
>> or send email to [email-masked]
>> 
>> Please report tools.ietf.org bugs at
>> http://tools.ietf.org/tools/issues
>> or send email to [email-masked]
> 
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Feb 2020 13:44:38 -0600

Hi Carsten -

The situation hasn't changed so far. Our efforts the last few weeks have 
been focused on the server replacement and finalizing the python2/3 
transitions. I expect we will get to spend some time talking about 
changing the behavior of the draft and chair aliases while we're in 
Vancouver.

I understand your point about not having a place to go to follow the 
status things like this, and am looking for ways to better provide that.

RjS

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Feb 2020 20:55:03 +0100

Hi Robert,

thanks for replying.  Certainly keeping the system running is more urgent than solving this particular problem.

I’m looking forward to the March 11 briefing; I hope I can make it (it’s going to be 21:00 here).  I particularly like that you plan to discuss monitoring and knowing whether user-visible features actually work; my favorite way of improving service quality further.  Let me hint that I’ll be bringing up performance (response time) monitoring in that vein.

And I hope we can talk in Vancouver despite the current troubles…

Grüße, Carsten

> On 2020-02-27, at 20:44, Robert Sparks <[email-masked]> wrote:
> 
> Hi Carsten -
> 
> The situation hasn't changed so far. Our efforts the last few weeks have been focused on the server replacement and finalizing the python2/3 transitions. I expect we will get to spend some time talking about changing the behavior of the draft and chair aliases while we're in Vancouver.
> 
> I understand your point about not having a place to go to follow the status things like this, and am looking for ways to better provide that.
> 
> RjS
>

---

From: Jay Daley <[email-masked]>
Date: Fri, 28 Feb 2020 09:02:24 +1300

Carsten

> On 28/02/2020, at 8:55 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Robert,
> 

Those points were raised by me and for the monitoring I certainly want to see performance monitoring considered.  If you’re not already aware, there are two cloud services gaining a strong foothold in this area - Pingdom for state monitoring and New Relic for performance monitoring.  Both of those can be linked into something like statuspage.io <http://statuspage.io/> to give end users immediate visibility into current status and any issues.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]
+64 21 678840

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Feb 2020 13:20:04 -0800

To clarify, we're really talking about DMARC rejection rather than SPF
rejection, correct? SPF does have a "hardfail" policy, but just about
nobody actually rejects mail because the problems with doing that are
fairly obvious. DMARC's "reject" policy ((DKIM or SPF) and binding to
From address) and the problems with it are harder to understand. But
there are a lot of industry people pushing DMARC, so some large domains
are enforcing it even though it's an Informational RFC.

-Jim

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Feb 2020 23:41:32 +0100

On 2020-02-27, at 22:20, Jim Fenton <[email-masked]> wrote:
> 
> SPF does have a "hardfail" policy, but just about
> nobody actually rejects mail

I would have thought that, but I now know better…

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Feb 2020 17:49:32 -0500

> are enforcing it even though it's an Informational RFC.

And, I wish we would help them by respecting their p=reject email that
arrives by dropping it for our mailing lists, since clearly they don't want
email forwarded :-)
Yes, it would hurt for a month.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Feb 2020 15:08:49 -0800

> I would have thought that, but I now know better…
You're saying that this rejection is actually due to SPF and not DMARC
then? If that were the case, it would be a lot easier to remediate (just
rewrite the envelope-from address to a different domain). DMARC binds to
the From header field, which requires the much uglier rewriting we're
all seeing.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Feb 2020 06:55:00 +0100

> the From header field, which requires the much uglier rewriting we're

I’m not an expert in nomenclature for ways of making email not work, so I have instead included an example of the rejection that AMSL sees when I send mail to IETF aliases.
(I probably should collect them more rigorously, as there may be different situations in other cases.)

Grüße, Carsten

<[email-masked]> (expanded from <[email-masked]>):
   host cloud8.spamtitan.com[13.58.8.62] said: 550 5.7.1 SPF Policy Rejection
   t=[email-masked], s=mfrom, id=[email-masked] (in reply to RCPT TO
   command)
Reporting-MTA: dns; ietfa.amsl.com
X-Postfix-Queue-ID: 42C173A0CFD
X-Postfix-Sender: rfc822; [email-masked]
Arrival-Date: Wed, 26 Feb 2020 09:13:40 -0800 (PST)

Final-Recipient: rfc822; [email-masked]
Original-Recipient: rfc822;[email-masked]
Action: failed
Status: 5.7.1
Remote-MTA: dns; cloud8.spamtitan.com
Diagnostic-Code: smtp; 550 5.7.1 SPF Policy Rejection t=[email-masked],
   s=mfrom, id=[email-masked]

From: Carsten Bormann <[email-masked]>
Subject: Re: [Cbor] Interim today
Date: 2020-02-26 at 18:13:33 CET
To: CBOR Working Group <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Resent-From: <[email-masked]>
Resent-To: [email-masked], [email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Sat, 29 Feb 2020 12:04:39 -0800

> (I probably should collect them more rigorously, as there may be different situations in other cases.)

I stand corrected; the header you sent indeed does represent an SPF
rejection and not DMARC.

This is happening to you because of your SPF record:

tzi.org.        86400    IN    TXT    "v=spf1 mx
a:submithost.informatik.uni-bremen.de
a:imaphost.informatik.uni-bremen.de a:smtp.uni-bremen.de
ip4:134.102.50.0/24 ip4:134.102.51.0/24 ip4:134.102.22.0/24 -all"

The -all at the end is requesting that message recipients reject your
mail if it doesn't come from one of the named hosts, and
augustcellars.com (actually spamtitan.com on their behalf) is doing that.

I'm wondering why I haven't been running into that problem. I just
checked and (to my surprise) my domain's SPF record has a -all as well.
Perhaps it's because I DKIM-sign my outgoing email (you don't seem to).

From a tools standpoint, we could rewrite the envelope-from address, but
that would also have the effect of redirecting bounce messages to that
address. Unless we rewrote it to an address that redirected back to the
original sender. I wonder a bit if there are ways that those rewriting
tricks can be abused, though.

-Jim