Macs R We via Mailman-Users writes: > > Have you had complaints about needing to manually view the > > attachment [when using DMARC Wrap Message]?
> My experience has been that the attachment is entirely transparent > on iOS (amazingly so), and that Apple Mail may or may not show the > attachment as direct text or an attachment block, which is easily > clicked. Hallelujah! > My problem is that messages that recipients unwittingly never > receive rarely generate any complaints at all, so my lack of > complaints may actually be a bad sign. It's easy enough to check by getting a freemail account and subscribing it. It's not a 100% reliable check but it will help diagnose a lot of common problems where mail is arriving at the remote address, and some where it doesn't. > That was my understanding as well... which led to much surprise > when I inspected the headers of the (automatically-generated) > messages I was receiving from it only to find no SPF or DKIM > headings in them at all. Now, maybe this was because mine were > purely intra-server transport (the only reason I was successfully > receiving them in the first place), There are no SPF header fields, except for mentions in the various Authentication-Results fields which are based on a DNS check, not on a message header. OpenDKIM's default configuration is to not sign messages being delivered to localhost. So you're probably right that the lack of authentication information in the header of messages you receive at firearmspolitics.info is due to local transport. > but I have thought of no way to capture and examine the copies of > those messages that went out to remote users and got rejected. A message that is *discarded* disappears without a visible trace, after leaving a "successfully delivered to host.domain.tld" message in the MTA log. In some cases recipient hosts may be polite enough to tell you something about discards (DMARC reports, reputation reports) but never at the "this message was discarded" level. A message that is *rejected* results either in a message being returned to sender (a DSN = delivery status notice, which sometimes contains the original message) or an entry in the sending MTA's log that the message was rejected, whether the rejection was temporary or permanent, and usually a code indicating why it was rejected. In your Mailman configuration, it will say what host and port Mailman is sending email to. The default is localhost:25, which is probably the right thing. Do you have access to the MTA logs on that host? As for capturing messages "on the way out", this is actually easy enough to do if you have control of the MTA that Mailman communicates with. There are several ways to do it. But your problem can probably be diagnosed and fixed without that. > Well, sure, I was under the impression I had [Configured All The > Things]. There is no cross-server activity going on at my end. What do you mean by "no cross-server activity"? If you mean "server.wickenburg.us should not be involved", you're wrong: the PTR for firearmspolitics.info's IP address goes there, and firearmspolitics.info's SMTP server says the same. 48.170.125.96.in-addr.arpa domain name pointer server.wickenburg.us. # nc -C firearmspolitics.info 25 220-server.wickenburg.us ESMTP Exim 4.99.1 #2 Tue, 03 Mar 2026 10:47:00 -0700 220-We do not authorize the use of this system to transport unsolicited, 220 and/or bulk e-mail. QUIT 221 server.wickenburg.us closing connection # This is correct configuration of DNS and the mail server. Other servers will trust that this server is somehow authenticating firearmspolitics.info before forwarding mail from it. However, serving multiple domains will require proper configuration of the DKIM software, since "server" and "firearmspolitics" have different domain keys, and the DMARC policy is "p=reject;sp=reject". > The domain using mailman (firearmspolitics.info) is one of about > eight subdomains on this host, which has ONE mail server and ONE IP > address. That's useful information. > The main server (server.wickenburg.us > <http://server.wickenburg.us/> or wickenburg.us > <http://wickenburg.us/>) and all its subdomains have SPF records, > all identical except for an > "include wickenburg.us <http://wickenburg.us/>" Is that verbatim? That's not a valid include specification according to RFC 7208. (Checking ...) OK, the DNS gives sane answers. Oh ... are you sending HTML-only mail? This list converts that to plain text, I guess that's where all the URLs in <> are coming from. > in firearmspolitics.info's, which I was told to add to help solve > the original alignment problem with user-to-community message > forwarding. It shouldn't help at all, since all it does is repeat the information in firearmspolitics.info's TXT record. You're not getting good advice. WARNING: You say ypu are using cPanel's Mailman 2.2. This version was completely rewritten by cPanel to port from Python 2 to Python 3, and includes a fair number of cPanel proprietary hacks. We do not have access to the source code (unless they've published it recently, which seems unlikely since they think their hacks are value-add they can monetize). None of what I write from here on can be relied on for that reason, and because to date cPanel Mailman 2.2 has been rife with bugs. That disclaimer out of the way, here are some guesses. > I think what helps complicate this is various hidden, > unconfigurable cruft in the bowels of mailman... It's not hidden, and it's only partially unconfigurable. > such as the fact that these automatic messages are being generated > by "[email protected] > <mailto:[email protected]>". Is that the "From" address in the mail header? That doesn't seem right, because that's the reply address used if you want to contact the human responsible for the site. Replies to "-bounces" addresses are handled internally by Mailman, and recorded as problems with the intended recipient of the automatic message that caused the bounce. The "server.wickenburg.us" part is happening because the host name for your list(s) has not been configured, and I guess cPanel's configuration process configured "server" as default. In a stock Mailman 2, there is a requirement (later regretted after experience) that there be a "site list" by default named "mailman" at the main list host. IIRC the rationale was that this would be a last resort address for communication among administrators, but it was rarely used. It still appears in rare contexts where Mailman 2 cannot figure out who is a better sender address. The "-bounces" part in the envelope sender is the standard way to avoid getting non-delivery notifications sent to everyone on a mailing list. > This is no user I have defined -- had I defined it, I would have > put it under firearmspolitics.info <http://firearmspolitics.info/>, > not the unrelated main server name. I can't help but suspect this > may be playing some part in my predicament. Undoubtedly it is playing a role. Possibly these messages are being rejected because server.wickenburg.us has a DMARC p=reject policy. Because of the legacy nature of the "mailman" list, I don't know where its rejects would go, it depends on how it was configured. Do you have settings for DEFAULT_EMAIL_HOST = DEFAULT_URL_HOST = DEFAULT_URL_PATTERN = in mm_cfg.py? (If not check in Defaults.py.) If the domain in the first two is not "firearmspolitics.info", change it to that (except that the existing DEFAULT_URL_PATTERN is probably OK). Do this in mm_cfg.py even if there is an existing setting in Defaults.py. Defaults.py will be overwritten on upgrades, but they never touch mm_cfg.py (in stock Mailman 2, I can't swear for cPanel since they try to save you from some of that effort, they might mess with mm_cfg.py). Do all such manual configuration in mm_cfg.py. Oops, forgot to check: Is Mailman serving other virtual domains hosted on that server? If so, you should not change the DEFAULT_* settings mentioned above without careful consideration. Instead you may want to set up the firearmspolitics.info domain as a virtual domain in mm_cfg.py. See the comments above those settings in Defaults.py. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan ------------------------------------------------------ Mailman-Users mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/[email protected]/ https://mail.python.org/archives/list/[email protected]/ Member address: [email protected]
