Hi! On Mon, Apr 06, 2020 at 09:58:27PM +0100, Maciej W. Rozycki wrote: > On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > Out of curiousity, is this rewriting you are talking about the cause for a > > > lot of mails showing up as "From: GCC List" rather than their real > > > senders? > > > This has become very annoying recently. > > > > Yes, for emails from domains with declared interest in email > > cleanliness, via DMARC records in DNS. We have observed mail > > -blocked- at third parties, even just days ago, when we failed to > > sufficiently authenticate outgoing reflected emails. > > > > AIUI, all this effort is driven by wanting to defeat not just spammers > > but also real security problems like phishing enabled by forgery, > > including specifically the From: header. > > And it has actually broken GCC's patchwork: > <http://patchwork.ozlabs.org/project/gcc/list/>, which I used to use to > track my patches.
Yes, I noticed (I run that patchwork). > Now I cannot do that anymore as patches submitted from > my WDC address are marked as coming from <gcc-patc...@gcc.gnu.org>, which > obviously means they are not attributed to me. Yup. > I am fairly sure it breaks `git am' too, requiring a `From' override in > the change description for author attribution in patch application to work > reliably (I tend to work on my outbox when applying my own patches, so I > avoid this issue, but I am sure the issue will hit someone sooner or > later). Yup. > And of course I cannot use the `macro@' pattern anymore to select mailing > list messages in my inbox that I sent myself. Frankly it's the least of > the annoyances, but still, and they all add up. It would break even the built-in mutt "you sent this yourself" detection. > This is all silly, requiring the SMTP envelope sender to match the `From' > header breaks even the most basic e-mail mechanisms like the use of a > `.forward' file. This even *never* is true for my mail setups, and never has been, and it all works fine. > Can we please do something about it? Is functional > regression the price we absolutely need to pay for progress? > > How come the Linux kernel people who do e-mail patch management on a > vastly larger scale than we do, both in terms of traffic and the number of > mailing list subscribers, can get away without all these odd quirks in > their list server management? Perhaps it would be good asking them how > they handle their stuff? If someone cannot connect to them because they have a broken mail setup, the kernel people say "your problem, get a working mail setup", and that works fine so far (99.999% of people *can* get working mail, just not always company mail). Segher
