> I thought I had won by setting the flag that encapsulates incoming > mail as an attachment before rebroadcasting it to the community. > I'm surprised that works for your users. When I introduced it, I > thought it would be the best way to handle it, and MUAs would quickly > learn to at least preview those when from a list, but in practice none > did. Worse, Apple Mail for iOS provided no way to get at it at all. > > Have you had complaints about needing to manually view the attachment? > 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. 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.
> Mailman won't do DKIM. This is really the MTA's responsibility. > 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), 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. > The quickest way to get some protection is to figure out what the IP > address(es) of your outgoing SMTP gateway(s) is (are), and add an SPF > record specifying them as allowed to send mail for your site. Most > recipient sites will accept mail if the IP is allowed and the From > address is aligned per DMARC. > Well, sure, I was under the impression I had done all that. There is no cross-server activity going on at my end. The domain using mailman (firearmspolitics.info) is one of about eight subdomains on this host, which has ONE mail server and ONE IP address. 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/>" in firearmspolitics.info's, which I was told to add to help solve the original alignment problem with user-to-community message forwarding. mxtoolbox will happily display all the relevant records; they are the simplest forms of SPF, DKIM, and DMARC records possible (given the overly baroque world of SPF/DKIM/DMARC). I think what helps complicate this is various hidden, unconfigurable cruft in the bowels of mailman... such as the fact that these automatic messages are being generated by "[email protected] <mailto:[email protected]>". 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. > ------------------------------------------------------ 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]
