Hi Frank, > > 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). > > That part is at least pretty easy: use > git format-patch --from "Real Name git <y...@email.com>" > which will then force a second fake From: header into the body of > the commit email, where git-am can find it.
Sure, there are various ways to deal with that, both on the sender's and the receiver's side, however all require a manual intervention and are therefore prone to a human error. Which will obviously happen sooner or later. > > 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. [...] > > Unfortunately naive .forward based forwarding looks exactly like faked > or spam email to a third party MTAs. And can certainly score a positive though not a definite rating in spam qualification. I don't think we ought to encourage bad IT management practices by trying to adapt to them too hard and hurting ourselves (our workflow) in the process. > > 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? [...] > > I'm not sure, but their mails tend to be laden with a vast number of > Cc:'s, which bypass mailing list reflectors. Surely all the bots receive messages via a mailing list subscription though. Cc's are solely for maintainers, reviewers or other explicitly interested parties. Some maintainers actually require submissions to come via the relevant mailing list rather directly to them. Somehow it works. Thank you for your input regardless! Maciej
