Subject: [Tools-discuss] Can't send mail to Cenk (Fwd: Undelivered Mail Returned to Sender)

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Dec 2020 10:51:36 +0100

This went to mail=2Bietf=[email-masked], and I thought that was all that is needed to get mail out.

Grüße, Carsten

> Begin forwarded message:
> 
> From: [email-masked] (Mail Delivery System)
> Subject: Undelivered Mail Returned to Sender
> Date: 2020-12-11 at 10:48:36 CET
> To: [email-masked]
> Message-Id: <[email-masked]>
> 
> This is the mail system at host ietfa.amsl.com.
> 
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> 
> For further assistance, please send mail to postmaster.
> 
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
> 
>                   The mail system
> 
> <[email-masked]>: host gundogan.net[37.120.167.193] said: 550 5.7.23
>    <[email-masked]>: Recipient address rejected: Message rejected due
>    to: SPF fail - not authorized. Please see
>    http://www.openspf.net/Why?s=mfrom;id=[email-masked];ip=4.31.198.44;r=<UNKNOWN>
>    (in reply to RCPT TO command)
> Reporting-MTA: dns; ietfa.amsl.com
> X-Postfix-Queue-ID: 1F7303A084D
> X-Postfix-Sender: rfc822; [email-masked]
> Arrival-Date: Fri, 11 Dec 2020 01:48:34 -0800 (PST)
> 
> Final-Recipient: rfc822; [email-masked]
> Original-Recipient: rfc822;[email-masked]
> Action: failed
> Status: 5.7.23
> Remote-MTA: dns; gundogan.net
> Diagnostic-Code: smtp; 550 5.7.23 <[email-masked]>: Recipient address
>    rejected: Message rejected due to: SPF fail - not authorized. Please see
>    http://www.openspf.net/Why?s=mfrom;id=[email-masked];ip=4.31.198.44;r=<UNKNOWN>
> 
> From: Carsten Bormann <[email-masked]>
> Subject: Re: [Tools-discuss] Diacritics in bibtex export
> Date: 2020-12-11 at 10:48:26 CET
> To: Cenk Gündoğan <[email-masked]>
> Cc: Tools Team Discussion <[email-masked]>
> Message-Id: <[email-masked]>
> 
> 
> On 2020-12-11, at 10:42, Cenk Gündoğan <mail=2Bietf=[email-masked]> wrote:
>> 
>> [2] https://datatracker.ietf.org/doc/rfc8724/bibtex
> 
> Do you need anything else than
> \usepackage[utf8]{inputenc}
> to make this work?
> 
> Grüße, Carsten
> 
> 
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Dec 2020 11:57:35 +0200

> This went to mail=2Bietf=[email-masked], and I thought that was all that is needed to get mail out.

I have seen similar errors recently. I ended up allowing 4.31.198.44 as a sender for eggert.org.

Lars

---

From: Glen <[email-masked]>
Date: Fri, 11 Dec 2020 09:24:08 -0800

> I have seen similar errors recently. I ended up allowing 4.31.198.44 as a sender for eggert.org.

I can't speak to the errors or the rewriting portion of this, because 
that is all a part of the Postconfirm system, and others here are better 
able to speak authoritatively to how it was designed and should work.

But to this point:

> allowing 4.31.198.44 as a sender

I just want to clarify that those individuals who wish to whitelist the 
IETF's servers in SPF (or elsewhere) should include six addresses in 
their list, to account for our virtual host cluster:

4.31.198.44
2001:1900:3001:11::2c
4.31.198.41
2001:1900:3001:11::29
192.95.54.41
2607:5300:60:9ccf::29

Thanks,
Glen

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Dec 2020 19:34:38 +0200

Thanks Glen! Do these addresses by chance have a common DNS name? Would make the setup a bit easier.

-- 
Sent from a mobile device; please excuse typos.

> On Dec 11, 2020, at 19:24, Glen <[email-masked]> wrote:
> 
> I can't speak to the errors or the rewriting portion of this, because that is all a part of the Postconfirm system, and others here are better able to speak authoritatively to how it was designed and should work.
> 
> But to this point:
> 
> I just want to clarify that those individuals who wish to whitelist the IETF's servers in SPF (or elsewhere) should include six addresses in their list, to account for our virtual host cluster:
> 
> 4.31.198.44
> 2001:1900:3001:11::2c
> 4.31.198.41
> 2001:1900:3001:11::29
> 192.95.54.41
> 2607:5300:60:9ccf::29
> 
> Thanks,
> Glen
> 
> ___________________________________________________________
> 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: Glen <[email-masked]>
Date: Fri, 11 Dec 2020 09:42:46 -0800

> Thanks Glen! Do these addresses by chance have a common DNS name? Would make the setup a bit easier.

Hi Lars -

ietf[abc].amsl.com

Thanks!
Glen

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Dec 2020 19:00:18 +0100

Hmm.

check() {
    addr=$1
    printf "$addr: "
    NAME=`dig +short -x $addr`
    printf "$NAME -> "
    printf `dig +short $NAME A`/
    dig +short $NAME AAAA
}
cat <<HERE | while read addr; do check $addr; done
4.31.198.44
2001:1900:3001:11::2c
4.31.198.41
2001:1900:3001:11::29
192.95.54.41
2607:5300:60:9ccf::29
HERE

4.31.198.44: mail.ietf.org. -> 4.31.198.44/2001:1900:3001:11::2c
2001:1900:3001:11::2c: mail.ietf.org. -> 4.31.198.44/2001:1900:3001:11::2c
4.31.198.41: mail.ietf.org. -> 4.31.198.44/2001:1900:3001:11::2c
2001:1900:3001:11::29: mail.ietf.org. -> 4.31.198.44/2001:1900:3001:11::2c
192.95.54.41: ietfc.amsl.com. -> 192.95.54.41/2607:5300:60:9ccf::29
2607:5300:60:9ccf::29: ietfc.amsl.com. -> 192.95.54.41/2607:5300:60:9ccf::29

I’m sure quite a few mail servers will croak on the v6 address of the second server, and maybe even on the v4 addresses.

Grüße, Carsten

---

From: Glen <[email-masked]>
Date: Fri, 11 Dec 2020 10:03:29 -0800

> I’m sure quite a few mail servers will croak on the v6 address of the second server, and maybe even on the v4 addresses.

Carsten -

They won't.  Only the first server is live and resolving.  If we ever 
had to bring an alternative server online, the DNS would be updated 
automatically and the new server would take the old server's place. The 
DNS you're seeing now is just "backup" records.

Glen

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2020 13:33:28 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

>>    http://www.openspf.net/Why?s=mfrom;id=[email-masked];ip=4.31.198.44;r=<UNKNOWN>

Your message was relayed through the IETF's mail server and your SPF
-all tells him to reject relayed mail.  His mail system is doing exactly
what you've asked it to do.

If you believe that the IETF should do something else to forwarded
mail it would be helpful if you could point to relevant RFCs. Or, of
course, you could fix your SPF record.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2020 13:34:19 -0500

>able to speak authoritatively to how it was designed and should work.

It's working fine.  Carsten's SPF tells people to reject relayed mail and that's what happened here.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Dec 2020 14:10:27 -0500

John Levine <[email-masked]> wrote:
    >> This went to mail=2Bietf=[email-masked], and I thought
    >> that was all that is needed to get mail out.

    > -all tells him to reject relayed mail.  His mail system is doing
    > exactly what you've asked it to do.

    > If you believe that the IETF should do something else to forwarded mail
    > it would be helpful if you could point to relevant RFCs. Or, of course,
    > you could fix your SPF record.

Well, I believe that the IETF should stop with the dmarc.ietf.org, and
we should simply do, as you said, what the sender's SPF and DMARC records
say, and simply drop their email rather than allow it through mailman.

They didn't want it relayed, we shouldn't relay it. Period.

If we are going to do this rewriting, then we had better get it right, and
that means rewriting it both ways.

{I'm been told that ARC solves all of this, but that was like 8 years ago,
and we still don't have much.  I guess we have a document, but I haven't seen
it deployed yet.  Is it?}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 11 Dec 2020 20:12:12 +0100

> that means rewriting it both ways.

We are rewriting it both ways.  This was not a bug in our setup.

	Henrik

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2020 14:20:16 -0500

>> They didn't want it relayed, we shouldn't relay it. Period.

In my experience only a small fraction of mail systems pay attention to 
SPF -all because the false positive rate is stupendous.  The current 
behavior is fine.

> We are rewriting it both ways.  This was not a bug in our setup.

On mail to dmarc.ietf.org addresses, we rewrite the recipient but not the 
sender unless I suppose the sender also has a DMARC policy.  I agree that 
is not a bug.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 11 Dec 2020 19:27:37 +0000

Reality is always more important than philosophical stands;  King Canute would approve :)

Yes, my employer is one of the folks in the dmarc hack. But so are other small players like Google. :)

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 11 Dec 2020 14:52:06 -0500

> On Dec 11, 2020, at 2:27 PM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

From someone who runs my own mail server, it bugs me that my address gets rewritten.

I’m thinking that I’m adhering to all of the best practices for mail servers (I do have a problem with my upstream provider not cooperating). But, I’m obviously not jumping through all of the hoops that the IETF wants me to jump through to keep my address from being rewritten.

So I’m annoyed because I don’t know what the criteria are.

But then I see Akamai addresses are getting rewritten too and I think if they’re not jumping through all the hoops, maybe there’s just too many hoops.

Tom

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2020 15:24:51 -0500

> From someone who runs my own mail server, it bugs me that my address gets rewritten.

That's because you publish a DMARC policy with p=quarantine.  Change it to 
p=none and the rewriting will stop.

For small personal domains, DMARC policies other than p=none cause lots of 
problems and solve none.  If your name were Paypal, the advice would be 
different.

Regards,

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 11 Dec 2020 15:34:21 -0500

> On Dec 11, 2020, at 3:24 PM, John R Levine <[email-masked]> wrote:
> 
> That's because you publish a DMARC policy with p=quarantine.  Change it to p=none and the rewriting will stop.
> 
> For small personal domains, DMARC policies other than p=none cause lots of problems and solve none.  If your name were Paypal, the advice would be different.
> 
> Regards,
> John Levine

Thanks!

Add that to an IETF FAQ somewhere please.

Tom

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Dec 2020 22:10:18 +0100

I understand what is going on.

I just wasn’t aware that the problem that my mail address has been having with using alias addresses at ietf.org also extends to recipients at dmarc.ietf.org.
That is very logical, still it hit me by surprise.

>> We are rewriting it both ways.  This was not a bug in our setup.

I don’t know what "rewriting it both ways” means, but the, er, missing feature that I have seen for half a year or so is that ietf alias forwarders rewrite based on sender DMARC policy when they also would need to consider SPF policy.  (My message to [email-masked] reached xyz with my original sender address, so I can’t confirm an observation that you were “rewriting it both ways”, at least not in my case.)

> On mail to dmarc.ietf.org addresses, we rewrite the recipient but not the sender unless I suppose the sender also has a DMARC policy.  I agree that is not a bug.

See above.  I also agree that is not a bug, but it is a missing feature that I have now learned makes it impossible for me to send mail to some [email-masked].  If I could get my admins to publish a DMARC policy, that missing feature would no longer matter.  (But they only do SPF, in response to tzi.org having been a favorite sender domain for spammers, which in turn has been causing some black listing that we don’t need.)

Grüße, Carsten

---

From: Cenk Gündoğan <[email-masked]>
Date: Fri, 11 Dec 2020 22:13:40 +0100

Hello,

only a small percentage is actually leveraging the reply-to-list
feature.  Maybe it's something that one MUA can do better than another
MUA, but in my experience mails via ietf lists are sufficiently tagged
(List-ID, List-Post, ...) to use this feature.

When replying, I just hit to-list-only and do not deal with
DMARC-related From: rewriting at all.  While this configured mailman is
doing a decent job at deduplicating mails, other software might not be
that apt.  I like to think of this as a (maybe nowadays outdated?)
netiquette.

>> For small personal domains, DMARC policies other than p=none cause lots of problems and solve none.  If your name were Paypal, the advice would be different.

I'll think about this.  If this is what it takes to improve the user
experience of my correspondences, I might adopt that (: I'd prefer this
over allowlisting the earlier mentioned IPs.

Cheers,
Cenk

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2020 21:43:17 -0500

>over allowlisting the earlier mentioned IPs.

I'd suggest adjusting your mail filtering so the SPF result is used as
part of a spam score rather than just yes/no. In particular, as we
have seen rejecting mail becuase of SPF -all has a very high false
positive rate.

R's,
John