GNU bug report logs -
#45631
27.1; regression: message-forward-ignored-headers no longer applies when forwarding as MIME
Previous Next
Reported by: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
Date: Sun, 3 Jan 2021 17:13:01 UTC
Severity: normal
Tags: fixed
Found in version 27.1
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45631 in the body.
You can then email your comments to 45631 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Sun, 03 Jan 2021 17:13:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 03 Jan 2021 17:13:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've been using emacs as my MUA for years.
When I upgraded from emacs 26.3 to emacs 27.1, i noticed that
message-forward-as-mime now defaults to nil. I prefer to forward as
MIME generally, so i set it back to t.
The only downside to forwarding as MIME is the inclusion of some headers
that the received message has accumulated in transit, which might have
privacy-sensitive implications. I've been using
message-forward-ignored-headers for a while now to trim out headers like
Received and Delivered-To when forwarding.
But as of 27.1, message-forward-ignored-headers doesn't work when
forwarding as MIME. indeed, the help text for the variable now says
>> This variable is only consulted when forwarding "normally", not when
>> forwarding as MIME or the like.
But this is a regression from 26.3. I'd expect it to keep working.
Please restore the functionality so that i can automatically strip
privacy-sensitive headers when forwarding.
Thanks,
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Tue, 05 Jan 2021 13:08:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> I've been using emacs as my MUA for years.
>
> When I upgraded from emacs 26.3 to emacs 27.1, i noticed that
> message-forward-as-mime now defaults to nil. I prefer to forward as
> MIME generally, so i set it back to t.
>
> The only downside to forwarding as MIME is the inclusion of some headers
> that the received message has accumulated in transit, which might have
> privacy-sensitive implications. I've been using
> message-forward-ignored-headers for a while now to trim out headers like
> Received and Delivered-To when forwarding.
>
> But as of 27.1, message-forward-ignored-headers doesn't work when
> forwarding as MIME. indeed, the help text for the variable now says
>
> >> This variable is only consulted when forwarding "normally", not when
> >> forwarding as MIME or the like.
>
> But this is a regression from 26.3. I'd expect it to keep working.
>
> Please restore the functionality so that i can automatically strip
> privacy-sensitive headers when forwarding.
Iʼve compared emacs-26 and emacs-27, and the code is the same, which
leads me to suspect something different in your
configuration. 'message-forward-ignored-headers' is applied even when
forwarding as MIME (despite the docstring), except when
'message-forward-show-mml' is nil, or when itʼs 'best' and the
forwarded message is either signed or encrypted. Or maybe youʼre
forwarding from inside the *Article* buffer, I think Gnus behaves
differently then.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Wed, 06 Jan 2021 04:13:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 45631 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Robert--
Thanks for taking a look into this!
On Tue 2021-01-05 14:06:54 +0100, Robert Pluim wrote:
> Iʼve compared emacs-26 and emacs-27, and the code is the same, which
> leads me to suspect something different in your
> configuration. 'message-forward-ignored-headers' is applied even when
> forwarding as MIME (despite the docstring)
hm, the docstring change was recent, apparently in response to #27715 :
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=57fbf0cf7bd4a85f2ad6f14aa92494545106b887
that's why i assumed there had been a change.
> except when 'message-forward-show-mml' is nil, or when itʼs 'best' and
> the forwarded message is either signed or encrypted.
Hm, i'm using 'best' for message-forward-show-mml (as the default) and
yes, it looks like the issue is that i just noticed it happening when
i went to forward a signed message. Maybe it wasn't an issue before
because i wasn't forwarding a signed message? I no longer have emacs
26.3 installed so i can't check that handily right now.
The message headers (outside of the cryptographic envelope) do *not*
affect the digital signature, so they ought to be safe to trim out
without invalidating the digital signature. These are the message
headers that i want to trim.
> Or maybe youʼre forwarding from inside the *Article* buffer, I think
> Gnus behaves differently then.
I'm using notmuch-emacs, not gnus, but it reuses a lot of the existing
emacs MUA codebase, which is why i'm reporting it here.
Do you have a suggestion for how i can apply
message-forward-ignored-headers to a signed message? I only want it to
apply to headers that aren't covered by the digital signature anyway.
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Wed, 06 Jan 2021 10:32:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> Hi Robert--
>
> Thanks for taking a look into this!
>
> On Tue 2021-01-05 14:06:54 +0100, Robert Pluim wrote:
>> Iʼve compared emacs-26 and emacs-27, and the code is the same, which
>> leads me to suspect something different in your
>> configuration. 'message-forward-ignored-headers' is applied even when
>> forwarding as MIME (despite the docstring)
>
> hm, the docstring change was recent, apparently in response to #27715 :
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=57fbf0cf7bd4a85f2ad6f14aa92494545106b887
>
> that's why i assumed there had been a change.
>
Documentation lags implementation, as always :-)
>> except when 'message-forward-show-mml' is nil, or when itʼs 'best' and
>> the forwarded message is either signed or encrypted.
>
> Hm, i'm using 'best' for message-forward-show-mml (as the default) and
> yes, it looks like the issue is that i just noticed it happening when
> i went to forward a signed message. Maybe it wasn't an issue before
> because i wasn't forwarding a signed message? I no longer have emacs
> 26.3 installed so i can't check that handily right now.
>
> The message headers (outside of the cryptographic envelope) do *not*
> affect the digital signature, so they ought to be safe to trim out
> without invalidating the digital signature. These are the message
> headers that i want to trim.
>
>> Or maybe youʼre forwarding from inside the *Article* buffer, I think
>> Gnus behaves differently then.
>
> I'm using notmuch-emacs, not gnus, but it reuses a lot of the existing
> emacs MUA codebase, which is why i'm reporting it here.
>
> Do you have a suggestion for how i can apply
> message-forward-ignored-headers to a signed message? I only want it to
> apply to headers that aren't covered by the digital signature anyway.
I think setting message-forward-show-mml to t will do what you want,
then message won't bother to check if the message is signed/encrypted,
and will thus apply message-forward-ignored-headers.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Sun, 10 Jan 2021 15:19:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> I think setting message-forward-show-mml to t will do what you want,
> then message won't bother to check if the message is signed/encrypted,
> and will thus apply message-forward-ignored-headers.
Looking over that mess again, I think my analysis of when that variable
is used, and when it's supposed to be used, was wrong. I've now make it
respect that variable even if message-forward-show-mml is nil. The only
instance it won't be used is if message-forward-show-mml is `best', and
we're forwarding an encrypted/signed message.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 10 Jan 2021 15:19:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
45631 <at> debbugs.gnu.org and Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 10 Jan 2021 15:19:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Sun, 10 Jan 2021 17:26:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 45631 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 10 Jan 2021 16:18:23 +0100
> Cc: 45631 <at> debbugs.gnu.org, Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
>
> Robert Pluim <rpluim <at> gmail.com> writes:
>
> > I think setting message-forward-show-mml to t will do what you want,
> > then message won't bother to check if the message is signed/encrypted,
> > and will thus apply message-forward-ignored-headers.
>
> Looking over that mess again, I think my analysis of when that variable
> is used, and when it's supposed to be used, was wrong. I've now make it
> respect that variable even if message-forward-show-mml is nil.
Should this be fixed on the emacs-27 branch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Mon, 11 Jan 2021 01:45:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 45631 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Lars--
On Sun 2021-01-10 16:18:23 +0100, Lars Ingebrigtsen wrote:
> Looking over that mess again, I think my analysis of when that variable
> is used, and when it's supposed to be used, was wrong. I've now make it
> respect that variable even if message-forward-show-mml is nil. The only
> instance it won't be used is if message-forward-show-mml is `best', and
> we're forwarding an encrypted/signed message.
Thanks for taking a look at this. I'm trying to understand the
rationale for *not* trimming headers when message-forward-show-mml is
`best' and we're forwarding an encrypted/signed message.
If the headers being trimmed are strictly in the header section of the
forwarded message, then they aren't in the cryptographic envelope [0],
which means that they aren't implicated in either a standard PGP/MIME or
S/MIME signature or encryption.
Is the expectation that headers of internal parts of the message are
being trimmed (in which case, they might be implicated in the signature
or encryption)? or, is there some situation i'm missing where they
might have an impact on the cryptographic structure?
--dkg
[0]
https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.html
has definitions of "cryptographic envelope" and other
hopefully-useful concepts and terminology.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Mon, 11 Jan 2021 15:05:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Looking over that mess again, I think my analysis of when that variable
>> is used, and when it's supposed to be used, was wrong. I've now make it
>> respect that variable even if message-forward-show-mml is nil.
>
> Should this be fixed on the emacs-27 branch?
If it doesn't introduce any regressions, but my confidence here isn't
exactly 100%... I think we should wait a few weeks before backporting,
at least.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Mon, 11 Jan 2021 15:10:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> Is the expectation that headers of internal parts of the message are
> being trimmed (in which case, they might be implicated in the signature
> or encryption)? or, is there some situation i'm missing where they
> might have an impact on the cryptographic structure?
Well, we'd have to include the relevant headers at a minimum:
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"
But this code is almost a couple of decades old, and I have no idea what
the thought process behind this was at this date. Anybody know?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Tue, 12 Jan 2021 20:20:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 45631 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon 2021-01-11 16:09:18 +0100, Lars Ingebrigtsen wrote:
> Well, we'd have to include the relevant headers at a minimum:
>
> Content-Type: multipart/signed; boundary="=-=-=";
> micalg=pgp-sha256; protocol="application/pgp-signature"
I agree, but if the user is stripping the Content-Type header, i think
they're going to break a lot more than digital signatures or encryption
(imagine what that does to a multipart/alternative message). I think
that stripping Content-Type is more of a case of "don't do that, then".
Maybe we even want to warn if the user tries to strip any of the
Content-* headers more generally.
> But this code is almost a couple of decades old, and I have no idea what
> the thought process behind this was at this date. Anybody know?
As long as the code doesn't attempt to strip *internal* MIME headers
(that is, headers of subparts of the MIME structure) i think it should
be safe to apply it to the forwarded message.
Note also that if we care about breakng cryptographic signatures more
generally, DKIM signatures are *more* likely to break if headers are
stripped than PGP/MIME or S/MIME, as DKIM is capable of covering headers
directly. Even given that concern, i think the most we'd want the
"best" setting to do to constrain header stripping would be to compare
the stripped version of the file to the non-stripped version -- if the
non-stripped version passes DKIM validation, but the stripped does not,
then either produce a warning message about DKIM signature breakage or
(if in an interactive mode) prompt the user about whether they want to
apply the filter or not.
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Wed, 13 Jan 2021 09:26:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> generally, DKIM signatures are *more* likely to break if headers are
> stripped than PGP/MIME or S/MIME, as DKIM is capable of covering headers
> directly. Even given that concern, i think the most we'd want the
> "best" setting to do to constrain header stripping would be to compare
> the stripped version of the file to the non-stripped version -- if the
> non-stripped version passes DKIM validation, but the stripped does not,
> then either produce a warning message about DKIM signature breakage or
> (if in an interactive mode) prompt the user about whether they want to
> apply the filter or not.
Adding unconditional checking of DKIM signatures to Emacs when
forwarding a message is a no-no. Think of people who work on email
when offline, or people who donʼt want to advertise the fact that
they've received email from a particular domain.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Wed, 13 Jan 2021 18:24:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 45631 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed 2021-01-13 10:25:51 +0100, Robert Pluim wrote:
> Adding unconditional checking of DKIM signatures to Emacs when
> forwarding a message is a no-no. Think of people who work on email
> when offline, or people who donʼt want to advertise the fact that
> they've received email from a particular domain.
Agreed! I'm not actually suggesting that we want to do DKIM signature
checking -- i'm just pointing out that if we're worried about header
removal damaging any sort of cryptographic signature, that's the most
likely scenario where that'll happen. The other forms of cryptographic
signature (PGP/MIME and S/MIME) aren't likely to be affected by header
stripping.
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Mon, 18 Jan 2021 15:51:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
>> Content-Type: multipart/signed; boundary="=-=-=";
>> micalg=pgp-sha256; protocol="application/pgp-signature"
>
> I agree, but if the user is stripping the Content-Type header, i think
> they're going to break a lot more than digital signatures or encryption
> (imagine what that does to a multipart/alternative message). I think
> that stripping Content-Type is more of a case of "don't do that, then".
> Maybe we even want to warn if the user tries to strip any of the
> Content-* headers more generally.
This is bringing back memories...
When forwarding messages, we have three cases:
1) Forward as non-MIME
Heeding message-forward-included-headers is unproblematic here: The
recipient isn't going to be able to reconstruct the original message at
all, since none of the MIME headers (and stuff) is included in
`message-forward-included-headers'. This basically means that the
recipient can just read the text itself.
2) MIME, but `message-forward-show-mml'
We can also remove all the headers here, because Message will
reconstruct all the MIME headers needed for the recipient to reconstruct
the entire original message, with multipart bits and all.
3) MIME, but not `message-forward-show-mml'
We don't remove any headers, because we don't know which ones are needed
for the recipient to actually read the resulting nested message.
Certainly not based on `message-forward-included-headers' -- this just
leaves From/Subject/etc.
So... I think what message was doing before my last change was correct,
but insufficiently documented: If we have `message-forward-as-mime', but
not `message-forward-show-mml', then we can't remove headers based on
`message-forward-included-headers', because the resulting message will
be invalid.
If headers are to be removed in 3), then we have to come up with a
`message-forward-headers-not-removed-when-using-mime-but-not-mml' (phew)
variable, that contains the headers necessary for reconstructing the
resulting message.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug No longer marked as fixed in versions 28.1 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 18 Jan 2021 15:51:01 GMT)
Full text and
rfc822 format available.
Removed tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 18 Jan 2021 15:51:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Mon, 18 Jan 2021 17:44:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 45631 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I'm getting a little confused here, so i'm going to back up and try to
simplify. There are two distinct (yet somehow overlapping) variables:
- message-forward-included-headers (an "allowlist")
- message-forward-ignored-headers (a "blocklist")
Can we agree on that?
Either or both (or neither) of these variables might be applied in any
of the three scenarios. If both are applied, i have no idea which order
they are applied in, so applying both is probably not a great idea. ☹
The simplest approach would be the following:
On Mon 2021-01-18 16:50:10 +0100, Lars Ingebrigtsen wrote:
> 1) Forward as non-MIME
apply the allowlist.
> 2) MIME, but `message-forward-show-mml'
apply the blocklist.
> 3) MIME, but not `message-forward-show-mml'
apply the blocklist.
What are the downsides to approaching it this way?
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Tue, 19 Jan 2021 03:13:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> Either or both (or neither) of these variables might be applied in any
> of the three scenarios. If both are applied, i have no idea which order
> they are applied in, so applying both is probably not a great idea. ☹
Both are applied.
> The simplest approach would be the following:
>
> On Mon 2021-01-18 16:50:10 +0100, Lars Ingebrigtsen wrote:
>> 1) Forward as non-MIME
>
> apply the allowlist.
>
>> 2) MIME, but `message-forward-show-mml'
>
> apply the blocklist.
>
>> 3) MIME, but not `message-forward-show-mml'
>
> apply the blocklist.
>
> What are the downsides to approaching it this way?
We can't change when they're applied, because that will break people's
setups. So we have to introduce a new variable for 3).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Tue, 19 Jan 2021 16:21:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 45631 <at> debbugs.gnu.org (full text, mbox):
On Tue 2021-01-19 04:12:02 +0100, Lars Ingebrigtsen wrote:
> Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
>
>> Either or both (or neither) of these variables might be applied in any
>> of the three scenarios. If both are applied, i have no idea which order
>> they are applied in, so applying both is probably not a great idea. ☹
>
> Both are applied.
In all cases? I think neither are applied in case 3, right?
At any rate, if they're typically applied in tandem, it seems like their
help text should probably refer to each other -- this discussion is the
first place i've learned about message-forward-included-headers :/
> We can't change when they're applied, because that will break people's
> setups. So we have to introduce a new variable for 3).
In case 3, neither are currently applied.
The only thing i'm asking for is to apply *only* the blocklist in case
3. What setups will that break?
--dkg
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Wed, 20 Jan 2021 16:19:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
>>> Either or both (or neither) of these variables might be applied in any
>>> of the three scenarios. If both are applied, i have no idea which order
>>> they are applied in, so applying both is probably not a great idea. ☹
>>
>> Both are applied.
>
> In all cases? I think neither are applied in case 3, right?
>
> At any rate, if they're typically applied in tandem, it seems like their
> help text should probably refer to each other -- this discussion is the
> first place i've learned about message-forward-included-headers :/
Indeed.
>> We can't change when they're applied, because that will break people's
>> setups. So we have to introduce a new variable for 3).
>
> In case 3, neither are currently applied.
>
> The only thing i'm asking for is to apply *only* the blocklist in case
> 3. What setups will that break?
It's just surprising behaviour -- that Message will strip a completely
different set of headers based on what forwarding method is used.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Wed, 20 Jan 2021 19:33:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 45631 <at> debbugs.gnu.org (full text, mbox):
On Wed 2021-01-20 17:17:55 +0100, Lars Ingebrigtsen wrote:
> It's just surprising behaviour -- that Message will strip a completely
> different set of headers based on what forwarding method is used.
I agree that the current behavior is already surprising.
I think it reduces the amount of surprise to have the blocklist applied
when forwarding as MIME.
--dkg
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45631
; Package
emacs
.
(Thu, 21 Jan 2021 15:48:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 45631 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> On Wed 2021-01-20 17:17:55 +0100, Lars Ingebrigtsen wrote:
>> It's just surprising behaviour -- that Message will strip a completely
>> different set of headers based on what forwarding method is used.
>
> I agree that the current behavior is already surprising.
>
> I think it reduces the amount of surprise to have the blocklist applied
> when forwarding as MIME.
The blocklist isn't very extensive -- the allowlist should also be
applied when forwarding as MIME, but that's not straightforward as
things are now.
I've now introduced the new variable, and headers seem to be
removed/kept in all the combinations of the variables now, I hope.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 21 Jan 2021 15:48:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
45631 <at> debbugs.gnu.org and Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 21 Jan 2021 15:48:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 19 Feb 2021 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 80 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.