Project

General

Profile

Actions
Copy link

tickets #139289

open

mailman3 cannot talk to mx2

Added by pjessen 6 months ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
pjessen
Category:
Servers hosted in PRG
Target version:
-
Start date:
2023-11-11
Due date:
% Done:

0%

Estimated time:

Description

I'm guessing this is also fall-out from the ongoing migration?
On mailman3, the mail queue has 30-40 messages that cannot be delivered to mx2 due to "Permission denied".
Trying to ping mx2:

mailman3 (lists.o.o):~ # ping6 2001:67c:2178:8::35
PING 2001:67c:2178:8::35(2001:67c:2178:8::35) 56 data bytes
From 2a07:de40:b27e:1203::3 icmp_seq=1 Destination unreachable: Administratively prohibited
From 2a07:de40:b27e:1203::3 icmp_seq=2 Destination unreachable: Administratively prohibited

When mx2 has been moved, I expect this to clear itself up, but I'm logging it just in case.

Actions
Copy link
 #1

Updated by crameleon 6 months ago

  • Category set to Servers hosted in PRG
  • Private changed from Yes to No

Hi,

there's no internal IPv6 route to NUE1 (old location), hence if you want to communicate to machines there (ones which happen to have an external IPv6 address) before they are migrated you need to pass -4. Otherwise it tries to send your traffic to the internet, and such is only allowed on a whitelist basis.
Also note that the mx* servers are now the only remaining machines.

Cheers,
Georg

Actions
Copy link
 #2

Updated by pjessen 6 months ago

crameleon wrote in #note-1:

Hi,

there's no internal IPv6 route to NUE1 (old location), hence if you want to communicate to machines there (ones which happen to have an external IPv6 address) before they are migrated you need to pass -4.

Doesn't really work well for postfix :-)

Also note that the mx* servers are now the only remaining machines.

I guess the mails on mailman3 will just have to wait till mx[12] have been moved. Or maybe I'll do a temp config for ipv4only on mailman3. (how does mailman3 talk to ipv4-only servers when it has no ipv4 interface?)

Actions
Copy link
 #3

Updated by pjessen 6 months ago

  • Assignee set to pjessen

how does mailman3 talk to ipv4-only servers when it has no ipv4 interface?

I see - it doesn't. Have disabled the direct delivery to mx12 for now.

Actions
Copy link
 #4

Updated by crameleon 6 months ago

Hi,

machines just talk via IPv6. The DNS64 system will provide AAAA records for internet domains which do not have any. The NAT64 gateway will translate the traffic to IPv4 if needed.

Cheers
Georg

Actions
Copy link
 #5

Updated by crameleon 6 months ago

The issue is when you try to contact a host which does have a "real" AAAA record, but one which contains an address that is not reachable! Such are mx{1,2}.

Actions
Copy link
 #6

Updated by pjessen 5 months ago

  • Assignee changed from pjessen to crameleon

This is ongoing, mailman3 has some 50 messages queued, unable to talk to mx[12]. Many of them are just spam, so it's not important, but some are NDRs that ought to go through.

Actions
Copy link
 #7

Updated by pjessen 5 months ago

  • Assignee changed from crameleon to pjessen

pjessen wrote in #note-6:

but some are NDRs that ought to go through.

Some are also delivery-status reports, e.g. "delivery delayed". I am beginning to wonder if these (and similar) should really be processed directly by mailman - we never saw them in the past, because they were just sent back to mx[12]. Re-assigning to @pjessen

Actions
Copy link
 #8

Updated by pjessen 5 months ago ยท Edited

Some are also messages to unknown lists (e.g. xorg@list, packet-writing@lists, cpanel@lists, radeonhd@lists) which mailman doesn't touch, so we just try to deliver them, outbound again. In the past, these would likely just have bounced, after a number of hops.

Actions
Copy link
 #9

Updated by pjessen 5 months ago

I tried routing lists.opensuse.org over hel.i.o.o, which led to the "too many hops", as expected.

Part of the issue is - what do we do with emails to unknown lists? The transport_maps setup in /var/lib/mailman/data/postfix_lmtp means they are not delivered to mailman, so we just try to deliver them, which is silly. I suggest they ought to bounce.
As a test, I added error:non-existent mailing list to the regular transport map - that does the trick:

2023-12-04T09:53:55.839183+00:00 mailman3 postfix/smtpd[30995]: connect from mx2.infra.opensuse.org[2a07:de40:b27e:1209::12]
2023-12-04T09:53:55.841617+00:00 mailman3 postfix/smtpd[30995]: NOQUEUE: reject: RCPT from mx2.infra.opensuse.org[2a07:de40:b27e:1209::12]: 550 5.1.1 <klop99@lists.opensuse.org>: Recipient address rejected: non-existent mailing list; from=<SRS0=MQ8t=HP=jessen.ch=per@opensuse.org> to=<klop99@lists.opensuse.org> proto=ESMTP helo=<mx2.opensuse.org>
2023-12-04T09:53:55.850024+00:00 mailman3 postfix/smtpd[30995]: disconnect from mx2.infra.opensuse.org[2a07:de40:b27e:1209::12] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=4/6

It also means stuff like this will be rejected:

2023-12-04T09:57:46.688284+00:00 mailman3 postfix/smtpd[31070]: connect from mx2.infra.opensuse.org[2a07:de40:b27e:1209::12]
2023-12-04T09:57:46.690100+00:00 mailman3 postfix/smtpd[31070]: NOQUEUE: reject: RCPT from mx2.infra.opensuse.org[2a07:de40:b27e:1209::12]: 550 5.1.1 <SRS0=qBBF=HP=lists.opensuse.org=risc-v-bounces@lists.opensuse.org>: Recipient address rejected: non-existent mailing list; from=<> to=<SRS0=qBBF=HP=lists.opensuse.org=risc-v-bounces@lists.opensuse.org> proto=ESMTP helo=<mx2.opensuse.org>

Mailman doesn't know what to do with an SRS address, so we might as well bounce it, I think.

Actions
Copy link

Also available in: Atom PDF