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

[Jim Fenton <[e-mail]>]

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

On 2/27/20 11:55 AM, Carsten Bormann wrote:
> 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 <[e-mail]> 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
>>
>> On 2/26/20 11:18 AM, Carsten Bormann wrote:
>>> Generic, undirected PING…
>>>
>>> Grüße, Carsten
>>>
>>>
>>>> On 2019-12-20, at 18:33, Carsten Bormann <[e-mail]> wrote:
>>>>
>>>> Hi Robert,
>>>>
>>>>> On Dec 20, 2019, at 17:16, Robert Sparks <[e-mail]> 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=[e-mail]?)
>>>>
>>>> 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 <[e-mail]> 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
>>>>>> [e-mail]
>>>>>> 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 [e-mail]
>>>>>>
>>>>>> Please report tools.ietf.org bugs at
>>>>>> http://tools.ietf.org/tools/issues
>>>>>> or send email to [e-mail]
>>>>> ___________________________________________________________
>>>>> Tools-discuss mailing list
>>>>> [e-mail]
>>>>> 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 [e-mail]
>>>>>
>>>>> Please report tools.ietf.org bugs at
>>>>> http://tools.ietf.org/tools/issues
>>>>> or send email to [e-mail]
>>>> ___________________________________________________________
>>>> Tools-discuss mailing list
>>>> [e-mail]
>>>> 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 [e-mail]
>>>>
>>>> Please report tools.ietf.org bugs at
>>>> http://tools.ietf.org/tools/issues
>>>> or send email to [e-mail]
>> ___________________________________________________________
>> Tools-discuss mailing list
>> [e-mail]
>> 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 [e-mail]
>>
>> Please report tools.ietf.org bugs at
>> http://tools.ietf.org/tools/issues
>> or send email to [e-mail]
> ___________________________________________________________
> Tools-discuss mailing list
> [e-mail]
> 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 [e-mail]
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [e-mail]