So much for keeping our company domain off of the postfix mailling lists, LOL. Redacting moving forward.
Rather than try to reply to every point you cited, let me start over: Our process to send to this list would do the following: Construct an email like this: To: support-st...@dayjob.org From: Support Staff <support-st...@dayjob.org> BCC: internal-al...@dayjob.org And then, in our delivery maps, we map: internal-al...@dayjob.org to support-contacts-someno...@support.dayjob.org (where our internal rt instance lives), with an :include: of a periodically-generated file generated by our ticket system. Because we do not want the customer list in our recipients, we rely on the BCC mechanism. This has worked pretty much flawlessly for years with two problems: 1) We wanted the address that was bcc'd to be "secret" (and security through obscurity is bad, but any real security postfix could offer us (checking the sender?) could be easily spoofed as well. The overhead of making an address internally-deliverable only is complicated: the RT machine *needs to accept mail*. 2) This weirdness. These original mailing lists (on the "support" system did not have the additional support-contacts-somenonce-owner: alias present. Whatever expanded that internal list, was leaking that somewhere into the headers. Looking at the internal bounce I got back from Office365, I see that the message made it *somewhere* into the bowels of o365 before being rejected, but the headers don't have the usual "for" line. Received: from BN9PR03CA0876.namprd03.prod.outlook.com (2603:10b6:408:13c::11) by SJ0P105MB0302.NAMP105.PROD.OUTLOOK.COM (2603:10b6:a03:2fd::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18; Tue, 10 Jan 2023 19:08:20 +0000 Received: from BN8NAM12FT017.eop-nam12.prod.protection.outlook.com (2603:10b6:408:13c:cafe::77) by BN9PR03CA0876.outlook.office365.com (2603:10b6:408:13c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18 via Frontend Transport; Tue, 10 Jan 2023 19:08:20 +0000 Authentication-Results: spf=pass (sender IP is 149.20.64.53) smtp.mailfrom=dayjob.org; dkim=pass (signature was verified) header.d=dayjob.org;dmarc=pass action=none header.from=dayjob.org;compauth=pass reason=100 Received-SPF: Pass (protection.outlook.com: domain of dayjob.org designates 149.20.64.53 as permitted sender) receiver=protection.outlook.com; client-ip=149.20.64.53; helo=mx.pao1.dayjob.org; pr=C Received: from mx.pao1.dayjob.org (149.20.64.53) by BN8NAM12FT017.mail.protection.outlook.com (10.13.182.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.11 via Frontend Transport; Tue, 10 Jan 2023 19:08:19 +0000 Received: from support.dayjob.org (support.dayjob.org [IPv6:2001:4f8:1:f::43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.dayjob.org (Postfix) with ESMTPS id 94D313AB02F; Tue, 10 Jan 2023 19:08:17 +0000 (UTC) I should note that we have several users using o365 and only got one bounce, and I'm not sure what deep inspection they're doing. They are an opaque box. I'm going to spin up both testing-with-owner-aliases and testing-without-owner-aliases that use the same mail flow, and see if I can narrow down the problem-set, but something's not right. My actual question of "is there a mailing list engine that *just* handles a tiny subset of what a full-blown mailman does (no cgi, no membership management, some basic body tagging perhaps)" remains unanswered and I can't believe that such an animal doesn't exist. This is exactly the featureset we'd get with some kind of ESP, except in-house. -Dan
