On Tue, Jan 10, 2023 at 05:10:41PM -0800, Dan Mahoney wrote:
> Construct an email like this:
>
> To: support-st...@dayjob.org
> From: Support Staff <support-st...@dayjob.org>
> BCC: internal-al...@dayjob.org
So far, so good. Presumably, once this leaves the MUA, the initial
envelope the MUA hands off to the MSA (or sendmail(1)) is:
MAIL FROM:<support-st...@dayjob.org>
RCPT TO:<support-st...@dayjob.org>
RCPT TO:<internal-al...@dayjob.org>
> And then, in our delivery maps, we map:
>
> internal-al...@dayjob.org to support-contacts-someno...@support.dayjob.org
When you say 'delivery maps', I assume you mean some aliases(5)-like
files configured to be used by the local(8) delivery agent and that the
destination domain is (or at least that particular recipient address
ends up in the local(8)) delivery agent for processing.
> 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*.
A non-public redistribution address is fine, you can also use a domain
that would be refused if it arrived at your door via SMTP from outside:
inernal-alias@local.invalid
with the inbound MX smtpd(8) rejecting all ".invalid" recipients via
some recipient access(5) lookup.
> 2) This weirdness.
>
> These original mailing lists (on the "support" system did not have the
> additional support-contacts-somenonce-owner: alias present.
Actually, the "owner-" token is a *PREFIX* not a *suffix*. So that
would be:
owner-support-contacts-somenonce: ...
> Whatever expanded that internal list, was leaking that somewhere into
> the headers.
It might only show up in "Delivered-To:", otherwise since it appears
in "Bcc:" from the MUA, it should not appear in "To:" or "Cc:" or
"Received: ... for <...>", unless the envelope "splits" with an
intermediate forwading hop before the alias expansion happens.
> 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.
Microsoft does not add these IIRC.
> 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
They accepted the message (violating the trace header syntax as always,
since "Microsoft SMTP" and "Frontend Transport" are not "atoms" as
required for the "with" and "via" clauses:
https://www.rfc-editor.org/rfc/rfc5321#page-60
Via = CFWS "VIA" FWS Link
With = CFWS "WITH" FWS Protocol
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; Additional standard names for links are
; registered with the Internet Assigned Numbers
; Authority (IANA). "Via" is primarily of value
; with non-Internet transports. SMTP servers
; SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are
; registered with the Internet Assigned Numbers
; Authority (IANA) in the "mail parameters"
; registry [9]. SMTP servers SHOULD NOT
; use unregistered names.
The one thing that would be particularly useful here, is if "id
15.20.6002.11" is actually a unique id for the message envelope, that
you could match against your logs. Then as an alternative to "VERP"
(mentioned below) if you *temporarily* configure the transport used to
hand off mail to Microsoft with a recipient limit of "1", each recipient
would get a separate message, and the logs will have a unique id for
the message accepted by Microsoft, which might match up with the trace
information in the bounce.
> 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.
Presumably, some sort of rule was put in place the restricts who can
send mail to some mailbox that is an ultimate recipient of the message.
To assign blame, you'd need to use VERP when submitting the message
so that each recipient gets a unique envelope address, allowing the
bounce to disclose the original recipient address (handed off to
Microsoft).
> 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.
Seems at first blush to be a case of restricted posting rights to some
mailbox on Microsoft side. Not much you can do about that. If that
recipient does not want your message, does it matter?
> 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.
Your question is unrelated to your problem description. Why do you
believe that mailman or similar would help? It is only really useful
for automated archiving, s-u-b-scribe, u-n-s-u-b-scribe, and bounce
handling, which it doesn't seem you need.
If you're lucky, "owner-" aliases will help. Otherwise, perhaps more
likely, you'll have to track down which particular recipient doesn't
want your mail.
--
Viktor.
