Allan Hansen writes: > But Apple Mail puts the mangled address To: into the ‘Previous > Recipients’ list to help with auto-completion later.
I assume by "To" you mean "From". We don't munge "To" in this situation (there is a personalized list configuration where To is changed from the list to the subscriber, but that shouldn't cause client problems or DMARC issues). I don't see how we can do anything reliable about that. From is a *required* field in RFC 5322 message syntax, and it *must* contain a mailbox (perhaps along with a display name). Some possibilities follow. We could stick a .invalid address in there, which would immediately bounce back to the sender. But that screws those users because the client hides the address and we don't control the delivery service notice in that case, it's the user's outgoing mail gateway that will reject it. Or possibly silently drop it. So there's no guarantee they'll get a message that makes any sense to them. And if they figure out the list is related, you'll take some heat. We could put an "oopsie, did you mean to send to us" address at the Mailman host in there that replies with explanation from Mailman, but when you don't have the list in Reply-To, people who *intend* a reply to list will have to copy/paste by hand (as mentioned earlier a link in the footer will not have the features of a client-composed reply). That might be OK for you, since you seem to really discourage replies to list. Another try would be a Rule that checks for the "via list-at-this- server" formulation and automatically bounces the mail back (regardless of any "don't at me" settings), with an explanation of why the mail bounced and a suggestion to clean up Previous Recipients. You could simulate this with the existing spam hold feature, but I'm not sure that can be set to reject on a per recipe basis, and I don't think it would allow for the explanation to differ across rejections. Of course that will fail if the user changes the display name. What is your experience? Do these users just accept the display name with "via list" attached, or do they tend to fix it while failing to notice the unintended address? It sounds like this might be good enough, possibly combined with a second Rule which looks for the list's display name (and any variants popular with posters) and holds posts that don't contain it for moderation. (Note to me: Possibly the mail's entire content would need to be scrubbed when bouncing but available at the archive as a .bin thingie to avoid certain kinds of bounce spam. And if so, it would need to be removed in say 24 hours since it's almost certainly private. Also maybe a check for In-Reply-To/References could help identify likely private mail?) > I do tell people to clean up their ‘Previous Recipients’ list, they > eventually forget and this happens again. You're a hero! But this sucks for you. The point of an advanced list manager is that you shouldn't have to do this kind of mechanical work. Steve ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org