Some random thoughts. Remember, you asked! :-) Jayson Smith writes:
> To mitigate this, what I've been doing is to set up a second Email > address called committeefwd which no one needs to even know > about. Then when a desirable (not spam) Email comes to committee, I > use the Mutt Email client's Bounce feature to send it to > committeefwd, which does the actual forwarding. I don't think the moderation step is the problem, especially not if you're using Mutt which is very reliable. (The only common issue might be the "Delivered-To" header field, which would make clear that the message was reinjected, but the often gets stripped by the outgoing MTA.) It's the forwarding itself. Is that your understanding? > The problem is that it seems Gmail especially doesn't like this. Gmail, the email provider that qualifies for a position in a Trump cabinet on maliciousness and stupidity. > I assume they're seeing incoming Emails which still have lots of > evidence of having been sent from the original sender's domain > (DKIM signatures, headers, etc.), yet something seems funny about > them, because of course it does! There's *nothing* "funny" about this because Gmail, Microsoft, Yahoo!, and so on all do it *as a business*. > As a test, I sent an Email to myself from a Hotmail account, then > manually forwarded it I assume by "forward" you mean "bounce" since that's what you do for your committeefwd case. > to a local account which forwards to a Gmail account. The message > ended up in spam on Gmail. The local account is on a host you manage? Does your MTA sign everything? (If a true "bounce" = "reinject the message as received by the MTA", that shouldn't matter[1], but likely does as we already know Gmail is nonconforming to DMARC.) > It seems to me that what is needed here is something that can take > an incoming message, make it look like a new message from my > server, then send it to the destination addresses. But you *can't* do that in principle, because as described you can't authenticate as the author. I guess you could use ARC (RFC 8617) to *testify* that *you* authenticated the author before destroying the authentication in this case. Google and Microsoft are said to respect ARC testimony, but I have no direct evidence for or against that. I have seen ARC-Seals from both of them, FWIW. > At first I thought Sender Rewriting Scheme (SRS) might be the > answer, but that would still leave lots of funny-tasting stuff in > the message in terms of headers from the original sending domain, > etc. I'm surprised someone hasn't written a program to do this. They have. It's called "anonymous mailing lists". The thing is, most Message Delivery Agents (MDAs) are in fact also Message Transport Agents (MTAs), and they handle .forward at the routing stage, before going to the local delivery transport. I'd have to check, but they may not even add Resent-* fields; only the Received field as if they were acting as MX. (@Mark, do you know?) > I'm sure Mailman could be used (abused?) to do this, but this seems > to me like overkill. Think about this like a software developer, not a CPU. ;-) The CPU cares only about wasted cycles, memory, and storage. But the developer also cares about her own time. Why should you spend time tracking Gmail (and Yahoo!) misbehavior, when we'll do it for you? OK, Mailman 3 is a *lot* of cycles and memory (you don't need storage since "bounce" isn't keeping archives) -- but are you really that short on any of the above, except your own time and peace of mind? :-) Steve Footnotes: [1] There are some header fields that a "bounce" should add that theoretically might be oversigned to discourage replay attacks, but that should be extremely rare. -- 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]
