From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:56
"Avery Pennarun" [off-list ref] writes:
And it's the MDA's job to munge it, not the MTA, so the
lines should never be munged while in transit *to* ...
Yeah, you're right. Sending side should not have any issues like that.
My receiving end (I think fetchmail slurps from my ISP and drops mails in
my local mbox, but it's a long time ago I configured my system...) does
quote only the "From " at the beginning, which is consistent with the
traditional mbox behaviour, so I see one, one, two, three in my local
mbox, and zero, one, two, three on gmane news article.
If this additional option claims to produce a mbox, I think:
(1) quoting only /^From / (not /^>*From/) to be consistent with the
standard practice is the right thing to do; and
(2) reading side might need to also pay attention to /^>From /, in case
somebody feeds an output from this option back to send-email.
However, strictly speaking,(2) may break the standard workflow of
generating patches with format-patch and feeding the result to send-email,
as format-patch does not do /^From / munging (and it shouldn't). The
issue is mostly theoretical --- it only matters if your commit log has a
line that begins with ">From ", and people who have worked with e-mail for
any nontrivial period have already learned to reword their sentences to
avoid lines that begin with "From " (or ">From ", for that matter) anyway.
If this additional option claims to produce a mbox, I think:
(1) quoting only /^From / (not /^>*From/) to be consistent with the
standard practice is the right thing to do; and
(2) reading side might need to also pay attention to /^>From /, in case
somebody feeds an output from this option back to send-email.
However, strictly speaking,(2) may break the standard workflow of
generating patches with format-patch and feeding the result to send-email,
as format-patch does not do /^From / munging (and it shouldn't).
Note that it's generally very bad practice to do (2) unless you always
quote /^>*From/. Quoting only /^From/ and *then* trying to dequote it
correctly actually increases the number of places where you can
corrupt a message. As a sign that very few programs do (2), I think
it's pretty clear that a lot more people see "From" rewritten as
">From" in their mail app of choice than the reverse.
There is also some debate about what "standard practice" means. See:
http://homepages.tesco.net/J.deBoynePollard/FGA/mail-mbox-formats.html
.
If git is going to start actually producing mbox files (as opposed to
just individual messages as it does now), it should probably
explicitly take a stance on the issue... or perhaps make it
configurable.
Have fun,
Avery
If this additional option claims to produce a mbox, I think:
(1) quoting only /^From / (not /^>*From/) to be consistent with
the standard practice is the right thing to do; and
(2) reading side might need to also pay attention to /^>From /,
in case somebody feeds an output from this option back to
send-email.
However, strictly speaking,(2) may break the standard workflow of
generating patches with format-patch and feeding the result to
send-email, as format-patch does not do /^From / munging (and it
shouldn't).
Note that it's generally very bad practice to do (2) unless you always
quote /^>*From/. Quoting only /^From/ and *then* trying to dequote it
correctly actually increases the number of places where you can
corrupt a message. As a sign that very few programs do (2), I think
it's pretty clear that a lot more people see "From" rewritten as
">From" in their mail app of choice than the reverse.
Junio is right when he says we should match against "From " instead of
"From" (i.e. we should not touch lines beginning with "Fromage" for
example). Should I resubmit or can it be corrected during the merge?
When I started working on this, I visited Wikipedia which provided a
link to qmail's site, which looks quite authoritative on this matter:
http://www.qmail.org/man/man5/mbox.html
I just followed that spec.
If git is going to start actually producing mbox files (as opposed to
just individual messages as it does now), it should probably
explicitly take a stance on the issue... or perhaps make it
configurable.
Have fun,
Avery
From: Eduard - Gabriel Munteanu <hidden> Date: 2016-06-15 22:44:56
On Sun, 13 Jul 2008 15:44:29 -0700
Junio C Hamano [off-list ref] wrote:
However, strictly speaking,(2) may break the standard workflow of
generating patches with format-patch and feeding the result to
send-email, as format-patch does not do /^From / munging (and it
shouldn't). The issue is mostly theoretical --- it only matters if
your commit log has a line that begins with ">From ", and people who
have worked with e-mail for any nontrivial period have already
learned to reword their sentences to avoid lines that begin with
"From " (or ">From ", for that matter) anyway.
Munging happens only when doing --export. If you don't supply that
option, it won't affect anything, so there is no breakage.
BTW, git-format-patch already produces output somewhat compatible with
mbox, as it adds a From_ line.
Eduard
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:56
"Avery Pennarun" [off-list ref] writes:
If git is going to start actually producing mbox files (as opposed to
just individual messages as it does now), it should probably
explicitly take a stance on the issue...
Yeah, that makes one reason I should not be enthusiastic to take this
patch.
If git is going to start actually producing mbox files (as opposed to
> just individual messages as it does now), it should probably
> explicitly take a stance on the issue...
Yeah, that makes one reason I should not be enthusiastic to take this
patch.
Eduard: perhaps instead of a --export option, what about an option to
run an external program that will take the given email on stdin and
process it however you want? ... aha, it seems this already exists in
the --smtp-server option. So a shell script like this as your
--smtp-server should do what you want:
#!/bin/sh
exec sed s/'^\(>*From \)/>\1/'
Thus the result of git-send-email would be a series of emails
concatenated to stdout, with From lines escaped appropriately.
Have fun,
Avery