ilf wrote in
:
|Eric Wong:
|> Without opening the above URLs, you can immediately tell it's
|> from April 6, 2016.
|
|Message-IDs are not supposed to be human-meaningful:
I am with Eric Wong here and agreed with almost everything he says
(except i hate git-send-email being standard now sinc
ilf wrote:
> Eric Wong:
> > Without opening the above URLs, you can immediately tell it's from April
> > 6, 2016.
>
> Message-IDs are not supposed to be human-meaningful:
> https://tools.ietf.org/html/rfc5322#section-3.6.4
That does not change the fact that they have been meaningful for
years
On Mon, Jan 11, 2021 at 08:22:08AM +, Eric Wong wrote:
> Derek Martin wrote:
> Well, mistakes happen... How we deal with them moving forward
> is important, though.
I certainly agree with that.
> Fwiw, I concur the PID in Message-IDs was a bad idea since it
> does unnecessarily leak informa
On 2021-01-11 08:22:08 +, Eric Wong wrote:
> Derek Martin wrote:
> > On Sat, Jan 09, 2021 at 10:54:28PM +, Eric Wong wrote:
> > > Hi Remco,
> > >
> > > So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
> > > (I noticed this in mutt 2.0.2 on FreeBSD)
> > >
> > > This is a bad cha
Eric Wong:
Without opening the above URLs, you can immediately tell it's
from April 6, 2016.
Message-IDs are not supposed to be human-meaningful:
The "Message-ID:" field provides a unique message identifier that
refers to a particular version of a particular message. The
uniqueness of the me
Derek Martin wrote:
> On Sat, Jan 09, 2021 at 10:54:28PM +, Eric Wong wrote:
> > Hi Remco,
> >
> > So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
> > (I noticed this in mutt 2.0.2 on FreeBSD)
> >
> > This is a bad change
>
> You should have just stopped there. This is a bad cha
On Sat, Jan 09, 2021 at 10:54:28PM +, Eric Wong wrote:
> Hi Remco,
>
> So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
> (I noticed this in mutt 2.0.2 on FreeBSD)
>
> This is a bad change
You should have just stopped there. This is a bad change, as I argued
when it was originally
Remco Rijnders wrote:
> On Sat, Jan 09, 2021 at 10:54:28PM +, Eric wrote in
> <20210109225428.GA27462@dcvr>:
> > This is a bad change for public mail archives which use
> > https://$SOMETHING_SOMETHING/$MSGID for robustness across
> > different public mail archives and hosts.
>
> > Having the
Hi Eric,
On Sat, Jan 09, 2021 at 10:54:28PM +, Eric wrote in
<20210109225428.GA27462@dcvr>:
So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
(I noticed this in mutt 2.0.2 on FreeBSD)
Encoding mmddHHMMSS into the Message-ID doesn't hurt users
privacy in cases where mutt is gen
Hi Remco,
So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
(I noticed this in mutt 2.0.2 on FreeBSD)
This is a bad change for public mail archives which use
https://$SOMETHING_SOMETHING/$MSGID for robustness across
different public mail archives and hosts.
Encoding mmddHHMMSS into
On Sun, May 24, 2020 at 06:52:06PM -0400, Remco Rijnders wrote:
Please find (in seperate emails to follow shortly) three proposed
patches to address this issue that I and others have raised. All three
patches have the use of (some of) the other patches I sent today as a
prerequisite.
Thanks Rem
A Message-ID should be globally unique. Currently mutt generates this ID
based on the current date and time, followed by ".G", followed by a letter
A to Z (A for the 1st and 27th email sent, Z for the 26th, etc.), followed
by the pid of the active mutt process, followed by "@" and the configured
fq
A Message-ID should be globally unique. Currently mutt generates this ID
based on the current date and time, followed by ".G", followed by a letter
A to Z (A for the 1st and 27th email sent, Z for the 26th, etc.), followed
by the pid of the active mutt process, followed by "@" and the configured
fq
A Message-ID should be globally unique. Currently mutt generates this ID
based on the current date and time, followed by ".G", followed by a letter
A to Z (A for the 1st and 27th email sent, Z for the 26th, etc.), followed
by the pid of the active mutt process, followed by "@" and the configured
fq
Please find (in seperate emails to follow shortly) three proposed
patches to address this issue that I and others have raised. All three
patches have the use of (some of) the other patches I sent today as a
prerequisite.
Patch #1 generates ID's in the form:
<1590350694.yJEHqG0ie/TbuynV@settler>,
On 2020-04-26 23:32:38 +0200, Gero Treuner wrote:
> Hi Vincent,
>
> On Sun, Apr 26, 2020 at 10:51:51PM +0200, Vincent Lefevre wrote:
> > On 2020-04-26 02:33:00 +0200, Gero Treuner wrote:
> > > The MessageId still starts with the time, but is now included in the
> > > base64 part, joined with the r
Hi Vincent,
On Sun, Apr 26, 2020 at 10:51:51PM +0200, Vincent Lefevre wrote:
> On 2020-04-26 02:33:00 +0200, Gero Treuner wrote:
> > The MessageId still starts with the time, but is now included in the
> > base64 part, joined with the random section before encoding.
>
> Why is the time needed? Si
On 2020-04-26 02:33:00 +0200, Gero Treuner wrote:
> The MessageId still starts with the time, but is now included in the
> base64 part, joined with the random section before encoding.
Why is the time needed? Since you use a CSPRNG, you can just use
random data for the full local part of the Messag
Hi,
On Wed, Apr 22, 2020 at 09:05:28PM -0400, re...@webconquest.com wrote:
> On Mon, Apr 20, 2020 at 11:18:55AM +0200, Oswald wrote in
[...]
> Thanks, I will incorporate this in the patch!
Here is another patch calling the openssl/gnutls random functions if
compiled with any of those, otherwise o
Kevin J. McCarthy wrote in
<20200423170108.gy17...@afu.lan>:
|On Thu, Apr 23, 2020 at 01:40:06PM +0200, Vincent Lefevre wrote:
|>> The memory allocated and returned by mutt_gen_base64_enc_rand() is being
|>> leaked.
|>
|>I'm thinking that there are two meanings of "leak".
|>This can be confus
On Sun, Apr 19, 2020 at 07:38:39AM -0400, Remco Rijnders wrote:
> On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek wrote in
> <20200419021334.go19...@bladeshadow.org>:
> > OK I'm getting pretty bored with this, it's already been decided by
> > Kevin it won't be accepted, but I'll answer this last me
On Thu, Apr 23, 2020 at 01:40:06PM +0200, Vincent Lefevre wrote:
The memory allocated and returned by mutt_gen_base64_enc_rand() is being
leaked.
I'm thinking that there are two meanings of "leak".
This can be confusing. :-)
*facepalm*. I did use the exact same word "leak" again, didn't I?
On 2020-04-22 18:37:09 -0700, Kevin J. McCarthy wrote:
> On Wed, Apr 22, 2020 at 09:05:28PM -0400, re...@webconquest.com wrote:
> > On Mon, Apr 20, 2020 at 11:18:55AM +0200, Oswald wrote in
> > > you're leaking the random strings. i suggest passing in fixed-size
> > > buffers instead.
> >
> > I am
On 2020-04-22 21:00:44 -0400, re...@webconquest.com wrote:
> On Tue, Apr 21, 2020 at 09:54:17AM +0200, Gero wrote in
> <20200421075417.gv11...@innocircle.com>:
> > > One thing, though: use base36, not base64 - as recommended in [0].
> > > Base64 only saves 4 characters and you don't necessarily nee
On Wed, Apr 22, 2020 at 09:05:28PM -0400, re...@webconquest.com wrote:
On Mon, Apr 20, 2020 at 11:18:55AM +0200, Oswald wrote in
you're leaking the random strings. i suggest passing in fixed-size
buffers instead.
I am not sure I understand how the random strings are being leaked,
and I'd like
On Mon, Apr 20, 2020 at 11:18:55AM +0200, Oswald wrote in
<20200420091855.GA283365@ugly>:
+ r = rand_uint64();
+
+ rbuf[0] = r & 0xFF;
+ rbuf[1] = (r >> 8) & 0xFF;
+ rbuf[2] = (r >> 16) & 0xFF;
+ rbuf[3] = (r >> 24) & 0xFF;
+ rbuf[4] = (r >> 32) & 0xFF;
+ rbuf[5] = (r >> 40) & 0xF
On Mon, Apr 20, 2020 at 04:52:13PM +0200, Vincent wrote in
<20200420145213.gb726...@zira.vinc17.org>:
Since you're interested only in a 64-bit unsigned number, this
should be:
r = r * ((uint64_t) RAND_MAX + (uint64_t) 1) + (uint64_t) random();
Thanks, I will incorporate this in the patch!
On Tue, Apr 21, 2020 at 09:54:17AM +0200, Gero wrote in
<20200421075417.gv11...@innocircle.com>:
One thing, though: use base36, not base64 - as recommended in [0].
Base64 only saves 4 characters and you don't necessarily need to put all
160 bits of the sha1 into the Message-ID.
Also agreed.
As
On Mon, Apr 20, 2020 at 06:57:29PM +0200, Vincent wrote in
<20200420165729.ge726...@zira.vinc17.org>:
Between 13:23 and 18:23, either Derek didn't send any mail, or he did
send mail (with another Mutt instance). Or perhaps he sent 26 messages
elsewhere with the same instance (though this is unlik
On 2020-04-21 23:21:14 +0100, Ian Collier wrote:
> On Tue, Apr 21, 2020 at 11:16:03PM +0200, Vincent Lefevre wrote:
> > This is a user-side problem. Users should make sure that their
> > hostname setting is unique (possibly with a very high probability,
> > assuming no attacks). See below.
>
> No.
Vincent Lefevre wrote in
<20200421205425.gb838...@zira.vinc17.org>:
|On 2020-04-20 19:57:23 +0200, Gero Treuner wrote:
...
|> If we don't want to be deterministic, then I don't see a major advantage
|> of hash functions compared to random data.
|
|In this case you need to make sure that such
On Tue, Apr 21, 2020 at 10:54:25PM +0200, Vincent Lefevre wrote:
> On 2020-04-20 19:57:23 +0200, Gero Treuner wrote:
> > This is necessary to stay on the deterministic track: For this we
> > require that different Mutt instances use information which differs by
> > the pid and time/sequence number
On Tue, Apr 21, 2020 at 11:16:03PM +0200, Vincent Lefevre wrote:
> This is a user-side problem. Users should make sure that their
> hostname setting is unique (possibly with a very high probability,
> assuming no attacks). See below.
No. The hostname is what goes after the @ in your default email
On 2020-04-20 21:49:11 +0100, Ian Collier wrote:
> On Mon, Apr 20, 2020 at 07:08:07PM +0200, Gero Treuner wrote:
> > The concern is that the inputs based on local and/or private information
> > can be leaked. To achieve this the search space must be big enough.
> [heavily snipped, of course]
> > We
On 2020-04-20 19:57:23 +0200, Gero Treuner wrote:
> This is necessary to stay on the deterministic track: For this we
> require that different Mutt instances use information which differs by
> the pid and time/sequence number at some point, which is the data fed to
> the hash algorithm.
OK, that w
On 2020-04-20 21:56:43 +0200, Arnt Gulbrandsen wrote:
> I chose to hash in a similar situation. Basically I pass the entire message
> through MD5 or another hash, then base64.
>
> A proper hash (even MD5) is indistinguishable from pure randomness if you
> have no knowledge of the input, and hashin
Hi all,
On Mon, Apr 20, 2020 at 09:49:11PM +0100, Ian Collier wrote:
> As Arnt has implied, the current method of generating the Message-ID
> does not *guarantee* uniqueness; merely makes it highly improbable to
> be non-unique. The thing is that we are not just concerned with other
> instances o
On Mon, Apr 20, 2020 at 07:08:07PM +0200, Gero Treuner wrote:
> The concern is that the inputs based on local and/or private information
> can be leaked. To achieve this the search space must be big enough.
[heavily snipped, of course]
> We need data which is unrelated to the email but - to be dete
I chose to hash in a similar situation. Basically I pass the entire
message through MD5 or another hash, then base64.
A proper hash (even
MD5) is indistinguishable from pure randomness if you have no knowledge
of the input, and hashing needs only the message. Random numbers
require a source o
Hi Vincent,
On Mon, Apr 20, 2020 at 07:38:06PM +0200, Vincent Lefevre wrote:
> > For hiding our pid etc. all data which can be found in the same email
> > or maybe related emails is of no use for feeding to the hash, because
> > it can easily be inserted as constants in brute-force searchs. Only
>
On 2020-04-20 19:08:07 +0200, Gero Treuner wrote:
> On Mon, Apr 20, 2020 at 05:57:00PM +0200, Vincent Lefevre wrote:
> > But why not using a cryptographic hash for the full local part, then?
> > This could be based on the full message (including the generated
> > headers at this point) + some rando
On Mon, Apr 20, 2020 at 05:57:00PM +0200, Vincent Lefevre wrote:
> On 2020-04-19 16:34:57 +0200, Gero Treuner wrote:
> > For the small purpose of avoiding collisions within a time frame of 1s
> > a couple of extra bytes are comparatively high cost IMO.
> >
> > But you are right, and the timestamp
On 2020-04-19 07:38:39 -0400, Remco Rijnders wrote:
> On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek wrote in
> <20200419021334.go19...@bladeshadow.org>:
> > OK I'm getting pretty bored with this, it's already been decided by
> > Kevin it won't be accepted, but I'll answer this last message since
On 2020-04-18 13:12:02 -0500, Derek Martin wrote:
> And let's be clear about what it would take to generate messages with
> the same ID in Mutt:
>
> - You need to generate > 26 messages in the same second--not any one
>second, but XX:XX:XX.00 - XX:XX:XX.99. This is actually very
>
Hi,
On Mon, Apr 20, 2020 at 05:03:00PM +0200, Matthias Andree wrote:
> Am 20.04.20 um 15:51 schrieb Kevin J. McCarthy:
> > My time is a bit limited to continue on this right now. But later, I
> > would appreciate others opinions about randomizing versus hashing
>
> Other than that, whatever ma
On 2020-04-19 16:34:57 +0200, Gero Treuner wrote:
> For the small purpose of avoiding collisions within a time frame of 1s
> a couple of extra bytes are comparatively high cost IMO.
>
> But you are right, and the timestamp could also be base64-ified to
> compensate.
But why not using a cryptograp
Am 20.04.20 um 15:51 schrieb Kevin J. McCarthy:
> On Mon, Apr 20, 2020 at 11:35:08AM +0200, Matthias Andree wrote:
>>> If there were a *real* threat model, Derek and I would take this more
>>> seriously. But I'm not going to backtrack on the generator
>>> determinism just to satisfy vague "securit
On 2020-04-19 17:35:50 -0400, Remco Rijnders wrote:
> For the same future consideration, please find attached a proposed patch.
> Deterministic it is not (unless you want to save the seed and a message
> counter somewhere), guaranteed to be unique, it is.
Well... If you have
+#if RAND_MAX/256 >=
On Mon, Apr 20, 2020 at 11:35:08AM +0200, Matthias Andree wrote:
If there were a *real* threat model, Derek and I would take this more
seriously. But I'm not going to backtrack on the generator
determinism just to satisfy vague "security" threats.
There is a possibility that if mail-to-news ga
On Sun, Apr 19, 2020 at 05:35:50PM -0400, Remco Rijnders wrote:
+/* Return a Base64 encoded representation of a 64 bit random number */
+char *mutt_gen_base64_enc_rand (void)
+{
+ unsigned char rbuf[8];
+ unsigned char result[12];
+ uint64_t r = 0;
+
+ r = rand_uint64();
+
+ rbuf[0] = r
Am 18.04.20 um 19:47 schrieb Kevin J. McCarthy:
> On Sat, Apr 18, 2020 at 08:41:47AM -0400, Remco Rijnders wrote:
>> On Fri, Apr 17, 2020 at 07:14:02PM -0700, Kevin wrote:
>>> I would also note that the current message id generation algorithm
>>> is deterministic. It's easy to understand how it ge
On Sun, Apr 19, 2020 at 09:26:46AM -0700, Kevin wrote in
<20200419162646.gj29...@afu.lan>:
However, I have opened a placeholder ticket #222 for future
consideration.
For the same future consideration, please find attached a proposed patch.
Deterministic it is not (unless you want to save the s
On Sun, Apr 19, 2020 at 12:00:45PM +0200, ilf wrote:
Should I open a ticket with this suggestion?
Thanks ilf, and others.
I think I've made my thoughts clear elsewhere in this thread. However,
I have opened a placeholder ticket #222 for future consideration.
--
Kevin J. McCarthy
GPG Finger
Hi,
> > > You would have to salt the values in some way before the hash and
> > > that might effect the deterministic part you'd like to keep.
> >
> salting doesn't make a hash collision more likely.
That's why more sources of deterministic data are required and the
reason to inspect inode data
On Sun, Apr 19, 2020 at 03:22:00PM +0200, Gero Treuner wrote:
On Sun, Apr 19, 2020 at 08:02:05AM -0400, Remco Rijnders wrote:
On the proposal to use a hashed value for the GA12345 part, I now have some
doubts as I think it would be a small effort to iterate through all
plausible values for this
Hi Remco and all,
On Sun, Apr 19, 2020 at 08:02:05AM -0400, Remco Rijnders wrote:
> On the proposal to use a hashed value for the GA12345 part, I now have some
> doubts as I think it would be a small effort to iterate through all
> plausible values for this to regenerate the hashes and still make
On Sat, Apr 18, 2020 at 06:54:36PM -0700, Kevin wrote in
<20200419015436.gi29...@afu.lan>:
On Sat, Apr 18, 2020 at 08:00:24PM -0400, Remco Rijnders wrote:
These might all seem far fetched, but the point is, information is
being disclosed that is of no value to be included in the Message-ID
head
On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek wrote in
<20200419021334.go19...@bladeshadow.org>:
OK I'm getting pretty bored with this, it's already been decided by
Kevin it won't be accepted, but I'll answer this last message since it
attempts to directly address a challenge I made.
Your ini
Derek Martin:
Using a standard method for generating IDs is one I would support in
general, as I believe in standards conformance in absentia of a good
reason not to conform.
Yes, in this thread I have also come to the conclusion that Mutt should
not try to invent its own way of generating Me
On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek Martin wrote:
None of these are also compelling, partly because they all describe
shady behavior,
shadyness lies in the eye of the beholder.
They also require either full access to all of your e-mail, or to a
very specific set of messages that b
OK I'm getting pretty bored with this, it's already been decided by
Kevin it won't be accepted, but I'll answer this last message since it
attempts to directly address a challenge I made.
On Sat, Apr 18, 2020 at 08:00:24PM -0400, Remco Rijnders wrote:
> On Sat, Apr 18, 2020 at 06:23:53PM -0500, De
On Sat, Apr 18, 2020 at 08:00:24PM -0400, Remco Rijnders wrote:
These might all seem far fetched, but the point is, information is
being disclosed that is of no value to be included in the Message-ID
header.
The information does have value for the purposes of uniqueness.
But your examples hav
On Sat, Apr 18, 2020 at 06:23:53PM -0500, Derek wrote in
<20200418232353.gm19...@bladeshadow.org>:
i'm sure one could come up with other data points if one is inclined
so.
This is not a compelling argument, and I'm equally sure that you can't.
"Ah... All this time you've been saying you do no
On Sun, Apr 19, 2020 at 01:03:06AM +0200, Oswald Buddenhagen wrote:
> On Sat, Apr 18, 2020 at 01:23:50PM -0500, Derek Martin wrote:
> > On Sat, Apr 18, 2020 at 01:57:50PM -0400, Remco Rijnders wrote:
> > > On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in
> > > > In other words, this scheme
On Sun, Apr 19, 2020 at 12:33:19AM +0200, Oswald Buddenhagen wrote:
> On Sat, Apr 18, 2020 at 12:04:05PM -0500, Derek Martin wrote:
> > OK, please enlighten me: Tell me what you've learned,
> >
> nothing, because i don't care. ;)
>
> > how it's any worse than all the other information I demonstr
On Sat, Apr 18, 2020 at 01:23:50PM -0500, Derek Martin wrote:
On Sat, Apr 18, 2020 at 01:57:50PM -0400, Remco Rijnders wrote:
On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in
> In other words, this scheme does not guarantee uniqueness, and is
> therefore broken.
Well, the odds of the sa
On Sat, Apr 18, 2020 at 12:04:05PM -0500, Derek Martin wrote:
OK, please enlighten me: Tell me what you've learned,
nothing, because i don't care. ;)
how it's any worse than all the other information I demonstrated is
necessarily leaked from the headers, and how it is in any way
exploitable
Mutt produces duplicate message-ids if others use the same format but
different number sources, if someone's system clock is bad or... I
forget the third case.
(Digression: There are so many hosts with
address 192.168.1.42 these days, and poor clocks too.)
Arnt
On Sat, Apr 18, 2020 at 01:57:50PM -0400, Remco Rijnders wrote:
> On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in
> > In other words, this scheme does not guarantee uniqueness, and is
> > therefore broken.
>
> Well, the odds of the same number being selected are about 1 in 2 billion
> (on
I'd like finally to elaborate on just a couple more points:
On Sat, Apr 18, 2020 at 10:47:58AM -0700, Kevin J. McCarthy wrote:
> On Sat, Apr 18, 2020 at 08:41:47AM -0400, Remco Rijnders wrote:
> > On Fri, Apr 17, 2020 at 07:14:02PM -0700, Kevin wrote:
> > > I would also note that the current messa
On Sat, Apr 18, 2020 at 12:33:47PM -0500, Derek Martin wrote:
> On Sat, Apr 18, 2020 at 08:27:55PM +0300, Consus wrote:
> > > > Nope, hostname it is, even if you're using built-in smtp.
> > >
> > > False. Try it.
> >
> > Check my headers :)
> >
> > > Tell mutt your hostname is your domain name
On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in
<20200418172634.gi19...@bladeshadow.org>:
Using a standard method for generating IDs is one I would support in
general, as I believe in standards conformance in absentia of a good
reason not to conform. Gowever in this case, it appears the
On Sat, Apr 18, 2020 at 08:41:47AM -0400, Remco Rijnders wrote:
On Fri, Apr 17, 2020 at 07:14:02PM -0700, Kevin wrote:
I would also note that the current message id generation algorithm
is deterministic. It's easy to understand how it generates, and to
know the exact limitations where it might
On Sat, Apr 18, 2020 at 08:27:55PM +0300, Consus wrote:
> > > Nope, hostname it is, even if you're using built-in smtp.
> >
> > False. Try it.
>
> Check my headers :)
>
> > Tell mutt your hostname is your domain name. This is a common
> > configuration, so that mutt auto-generates your e-mail
On Sat, Apr 18, 2020 at 12:17:11PM -0500, Derek Martin wrote:
> On Sat, Apr 18, 2020 at 01:10:47PM +0300, Consus wrote:
> > On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
> > > On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> > > > The Message-ID that mutt generates
On Sat, Apr 18, 2020 at 06:14:58PM +0200, ilf wrote:
> IMHO all the arguments also apply here. IMHO we should chose a form of
> Message-ID that (a) does not include unneccessary system information and (b)
> matches that of other MUAs. Maybe we should follow these "Recommendations
> for generating M
On Sat, Apr 18, 2020 at 01:10:47PM +0300, Consus wrote:
> On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
> > On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> > > The Message-ID that mutt generates is supposed to be unique. Up till now
> > > mutt would generate this I
On Sat, Apr 18, 2020 at 08:26:56AM -0400, Remco Rijnders wrote:
> > - the PID is the only thing that could possibly be vaguely useful to
> > an attacker, but only if they're already able to get onto the
> > user's system, in which case finding out the PID will be trivial
> > anyway. POINTLESS
On Sat, Apr 18, 2020 at 11:07:34AM +0200, Oswald Buddenhagen wrote:
> > Because it adds additional complexity to the program for absolutely zero
> > practical gain.
> >
> actually, the patch makes the code simpler.
I admitted already I did not look at the patch, so I was speaking in
general terms
I agree with Remco.
IMHO any information about a users system (like PID) is irrelevant for a
Message-ID and therefore should not be in there. If you consider this
information sensitive or not is entirely subjective. If only one user
considers it sensitive, we should not generate and transmit i
On Fri, Apr 17, 2020 at 07:14:02PM -0700, Kevin wrote in
<20200418021402.gg2...@afu.lan>:
On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
This is utterly pointless. This may come off as harsh but please
understand that's not intended. I just want to be completely clear
hee so th
On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek wrote in
<20200418005901.gb19...@bladeshadow.org>:
This is utterly pointless. This may come off as harsh but please
understand that's not intended. I just want to be completely clear
hee so there is no misunderstanding or equivocation.
Well, poi
On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
> On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> > The Message-ID that mutt generates is supposed to be unique. Up till now
> > mutt would generate this ID based on the current date and time, followed by
> > ".G". foll
On Sat, Apr 18, 2020 at 02:40:11AM -0500, Derek Martin wrote:
Because those people don't know what they're talking about, and
humoring them helps no one.
oh the irony ...
Because it adds additional complexity to the program for absolutely
zero practical gain.
actually, the patch makes the
On Sat, Apr 18, 2020 at 04:17:45AM +0200, Gero Treuner wrote:
> On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
> > On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> > > The Message-ID that mutt generates is supposed to be unique. Up till now
> > > mutt would generate
Hi all,
On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
> On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> > The Message-ID that mutt generates is supposed to be unique. Up till now
> > mutt would generate this ID based on the current date and time, followed by
> > "
On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
This is utterly pointless. This may come off as harsh but please
understand that's not intended. I just want to be completely clear
hee so there is no misunderstanding or equivocation.
I would also note that the current message id
On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> The Message-ID that mutt generates is supposed to be unique. Up till now
> mutt would generate this ID based on the current date and time, followed by
> ".G". followed by a letter A to Z (A for the 1st and 27th email sent, Z for
> th
The Message-ID that mutt generates is supposed to be unique. Up till now
mutt would generate this ID based on the current date and time, followed by
".G". followed by a letter A to Z (A for the 1st and 27th email sent, Z for
the 26th, etc.), followed by the pid of the active mutt process, followed
89 matches
Mail list logo
