Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-18 Thread David Wright
On Tue 16 Jun 2020 at 21:28:11 (+0200), l0f...@tuta.io wrote:
> 16 juin 2020 16:30 de deb...@lionunicorn.co.uk:
> 
> > It might be easier for people to follow the substance of this thread
> > if you posted in such a way as to include one simple self-descriptive
> > test in each post, and not include all the deeply-nested "noise" like
> > the above. So, for example, you could write:
> >
> > >From foo. This line was written with a leading unescaped From, "From ".
> >
> > >From bar. This line was written with a leading escaped From, ">From ".
> >
> > You could, in addition, include a file attachment of the test as written.
> >
> Good suggestion.
> 
> > You might also wish to omit/change your Attribution line temporarily,
> > because it prevents your tests from ever consisting entirely of 7-bit
> > ASCII, owing to its "à".
> >
> What's the consequence of it please?

AFAICT from the header, you encode these emails (quoted-printable).
I thought that might be avoided if entirely 7-bit ASCII, but I think
you frequently use other non-ASCII, like funny spaces, as well as à,
which also cause encoding to be necessary. And it's possible that
your sending encoded emails is obligatory (or set to be).

> > These little things might help clarify your reports of the distorting
> > effects of a medium, when those reports are subject to the same
> > potential distortion.
> >
> Yes, it's not always  easy to communicate efficiently & clearly by email ;)

Cheers,
David.



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-17 Thread Richard Hector
On 18/06/20 8:08 am, Greg Wooledge wrote:
> On Thu, Jun 18, 2020 at 08:02:11AM +1200, Richard Hector wrote:
>> > See  for more details.
> 
>> I understand the phenomenon. I don't understand why modern software (eg
>> the list software) still does it.
> 
> Well, imagine you're a mailing list.  A dozen people are subscribing
> to you, and you have no way to know which MTA and mailbox formats each
> of your subscribers is using.
> 
> If you don't do the From mangling, and you send a message to
> subscriber #7 who happens to be using a traditional /var/spool/mail
> mbox format, the results could be undesirable -- #7 will see half a
> message followed by a broken message.

If subscriber #7 can't deal with lines with a leading From, then surely
they're going to see breakage with any such incoming mail, not just
those from the list. And so if needed, their own mail system (MTA or
MUA) will mangle the From lines.

How is a message from a list fundamentally different? It doesn't supply
me with an mbox file, it still sends a properly formatted email.

Richard



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-17 Thread Greg Wooledge
On Thu, Jun 18, 2020 at 08:02:11AM +1200, Richard Hector wrote:
> > See  for more details.

> I understand the phenomenon. I don't understand why modern software (eg
> the list software) still does it.

Well, imagine you're a mailing list.  A dozen people are subscribing
to you, and you have no way to know which MTA and mailbox formats each
of your subscribers is using.

If you don't do the From mangling, and you send a message to
subscriber #7 who happens to be using a traditional /var/spool/mail
mbox format, the results could be undesirable -- #7 will see half a
message followed by a broken message.

The easy fix is to perform From mangling on every message that passes
through you.  That way, people won't see massively broken messages.
Occasionally, people will see a single broken line in a message, but
99% of the rest of your traffic will be OK.

It's a conservative strategy, and it works... mostly.  Close enough.



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-17 Thread Richard Hector
On 15/06/20 11:44 pm, Greg Wooledge wrote:
> On Sun, Jun 14, 2020 at 10:13:11AM -0500, David Wright wrote:
>> On Sat 13 Jun 2020 at 16:05:17 (+0200), l0f...@tuta.io wrote:
>> > However, this extra ">" should have been deleted upon viewing the email, 
>> > no?
>> 
>> How would the viewer's email client know whether the > in
>> >From had been added by some such scheme as above and should
>> be removed, or was a genuine occurrence in the original email?
> 
> Exactly.  It's a non-reversible mangling of the message body, prompted by
> an extremely well-known limitation of the mbox formats.
> 
> See  for more details.
> In particular, we're talking about the
>  section.
> 
> This same discussion seems to happen every month on this list, and it's
> still not clear to me WHY people can't understand it.  It's not a new
> phenomenon.  It's been this way forever.
> 

I understand the phenomenon. I don't understand why modern software (eg
the list software) still does it.

Richard



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-17 Thread Reco
Hi.

On Mon, Jun 15, 2020 at 02:06:08PM +0200, l0f...@tuta.io wrote:
> Hi,
> 
> 13 juin 2020 à 21:14 de recovery...@enotuniq.net:
> 
> > You're looking at the wrong header. It's X-Spam-Status and
> > X-Amavis-Spam-Status you should worry about. Authetication-Results is
> > set by your MTA receiving your own mail from the list.
> >
> > But yes, they are both OK for this and your previous e-mails.
> >
> Ok, thanks but still confusing...

Let's try it one more time. This particular phrase failed DKIM test in
another thread.

>From Linux kernel POV, *asynchronous* I/O is a pair of
io_submit/io_getevents syscalls, and dd does not do these regardless of
the options that are provided.

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-16 Thread Reco
On Tue, Jun 16, 2020 at 09:28:11PM +0200, l0f...@tuta.io wrote:
> Hi,
> 
> 16 juin 2020 14:50 de recovery...@enotuniq.net:
> 
> > And *now* it gets interesting. Because what's came to the list was text:
> >
> > Message-ID: 
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> >
> Can we imagine that the ML simply 64-decodes the email and resent it as 
> text/plain?

That's possible. But the e-mail in question was also DKIM-signed
(including the body), so such transformation would lead to DKIM failure.
And it did not happen.

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-16 Thread l0f4r0
Hi,

16 juin 2020 14:50 de recovery...@enotuniq.net:

> And *now* it gets interesting. Because what's came to the list was text:
>
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
Can we imagine that the ML simply 64-decodes the email and resent it as 
text/plain?

16 juin 2020 16:30 de deb...@lionunicorn.co.uk:

> It might be easier for people to follow the substance of this thread
> if you posted in such a way as to include one simple self-descriptive
> test in each post, and not include all the deeply-nested "noise" like
> the above. So, for example, you could write:
>
> >From foo. This line was written with a leading unescaped From, "From ".
>
> >From bar. This line was written with a leading escaped From, ">From ".
>
> You could, in addition, include a file attachment of the test as written.
>
Good suggestion.

> You might also wish to omit/change your Attribution line temporarily,
> because it prevents your tests from ever consisting entirely of 7-bit
> ASCII, owing to its "à".
>
What's the consequence of it please?

> These little things might help clarify your reports of the distorting
> effects of a medium, when those reports are subject to the same
> potential distortion.
>
Yes, it's not always  easy to communicate efficiently & clearly by email ;)

Best regards,
l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-16 Thread David Wright
On Tue 16 Jun 2020 at 13:10:38 (+0200), l0f...@tuta.io wrote:
> 13 juin 2020 à 21:05 de recovery...@enotuniq.net:
> > On Sat, Jun 13, 2020 at 09:01:59PM +0200, l0f...@tuta.io wrote:
> >> 13 juin 2020 à 17:12 de recovery...@enotuniq.net:
> >> > On Sat, Jun 13, 2020 at 06:10:15PM +0300, Reco wrote:
> >> >
> >> >> Let's see.
> >> >>
> >> >> >From what I saw this should fail DKIM test.
> >> >>
> >> >> And, for the good measure:
> >> >>
> >> >> >From: this is not a valid RFC-822 header
> >> >>
> >> >
> >> > Ok, clearly I don't have any problem with DKIM on this list.
> >> >
> >> Ok let's see for me as well:
> >>
> >> >From my point of view
> >>
> >> >From: l0f4r0
> >>
> >> l0f4r0
> >>
> > Your e-mail passed DKIM test on my MTA with flying colors.
> >
> > Try that base64-encoded html thing next.
> >
> It was already base64 encoded, see below:
> 
> --79Bu5A16qPEYcVIZL@tutanota
> Content-Type: text/html; charset=UTF-8
> Content-transfer-encoding: base64
> 
> PGRpdj4xMyBqdWluIDIwMjAgw6AgMTc6MTIgZGUgcmVjb3ZlcnltNG5AZW5vdHVuaXEubmV0Ojxicj
> 48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0idHV0YW5vdGFfcXVvdGUiPjxkaXY+T24gU2F0LCBKdW4g
> MTMsIDIwMjAgYXQgMDY6MTA6MTVQTSArMDMwMCwgUmVjbyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcX
> VvdGU+PGRpdj5MZXQncyBzZWUuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jmd0O0Zyb20g
> d2hhdCBJIHNhdyB0aGlzIHNob3VsZCBmYWlsIERLSU0gdGVzdC48YnI+PC9kaXY+PGRpdj48YnI+PC
> 9kaXY+PGRpdj5BbmQsIGZvciB0aGUgZ29vZCBtZWFzdXJlOjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp
> dj48ZGl2PiZndDtGcm9tOiB0aGlzIGlzIG5vdCBhIHZhbGlkIFJGQy04MjIgaGVhZGVyPGJyPjwvZG
> l2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9rLCBjbGVhcmx5IEkgZG9uJ3QgaGF2
> ZSBhbnkgcHJvYmxlbSB3aXRoIERLSU0gb24gdGhpcyBsaXN0Ljxicj48L2Rpdj48L2Jsb2NrcXVvdG
> U+PGRpdj5PayBsZXQncyBzZWUgZm9yIG1lIGFzIHdlbGw6PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2
> PjxkaXY+Jmd0O0Zyb20gbXkgcG9pbnQgb2Ygdmlldzxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZG
> l2PiZndDtGcm9tOiBsMGY0cjA8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5sMGY0cjA8YnI+
> PC9kaXY+
> 
> --79Bu5A16qPEYcVIZL@tutanota--

It might be easier for people to follow the substance of this thread
if you posted in such a way as to include one simple self-descriptive
test in each post, and not include all the deeply-nested "noise" like
the above. So, for example, you could write:

>From foo. This line was written with a leading unescaped From, "From ".

>From bar. This line was written with a leading escaped From, ">From ".

You could, in addition, include a file attachment of the test as written.

You might also wish to omit/change your Attribution line temporarily,
because it prevents your tests from ever consisting entirely of 7-bit
ASCII, owing to its "à".

These little things might help clarify your reports of the distorting
effects of a medium, when those reports are subject to the same
potential distortion.

Cheers,
David.



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-16 Thread Reco
Hi.

On Tue, Jun 16, 2020 at 01:10:38PM +0200, l0f...@tuta.io wrote:
> > Your e-mail passed DKIM test on my MTA with flying colors.
> >
> > Try that base64-encoded html thing next.
> >
> It was already base64 encoded, see below:
> 
> --79Bu5A16qPEYcVIZL@tutanota
> Content-Type: text/html; charset=UTF-8
> Content-transfer-encoding: base64
> 
> PGRpdj4xMyBqdWluIDIwMjAgw6AgMTc6MTIgZGUgcmVjb3ZlcnltNG5AZW5vdHVuaXEubmV0Ojxicj
> 48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0idHV0YW5vdGFfcXVvdGUiPjxkaXY+T24gU2F0LCBKdW4g
> MTMsIDIwMjAgYXQgMDY6MTA6MTVQTSArMDMwMCwgUmVjbyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcX
> VvdGU+PGRpdj5MZXQncyBzZWUuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jmd0O0Zyb20g
> d2hhdCBJIHNhdyB0aGlzIHNob3VsZCBmYWlsIERLSU0gdGVzdC48YnI+PC9kaXY+PGRpdj48YnI+PC
> 9kaXY+PGRpdj5BbmQsIGZvciB0aGUgZ29vZCBtZWFzdXJlOjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp
> dj48ZGl2PiZndDtGcm9tOiB0aGlzIGlzIG5vdCBhIHZhbGlkIFJGQy04MjIgaGVhZGVyPGJyPjwvZG
> l2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9rLCBjbGVhcmx5IEkgZG9uJ3QgaGF2
> ZSBhbnkgcHJvYmxlbSB3aXRoIERLSU0gb24gdGhpcyBsaXN0Ljxicj48L2Rpdj48L2Jsb2NrcXVvdG
> U+PGRpdj5PayBsZXQncyBzZWUgZm9yIG1lIGFzIHdlbGw6PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2
> PjxkaXY+Jmd0O0Zyb20gbXkgcG9pbnQgb2Ygdmlldzxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZG
> l2PiZndDtGcm9tOiBsMGY0cjA8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5sMGY0cjA8YnI+
> PC9kaXY+
> 
> --79Bu5A16qPEYcVIZL@tutanota--

And *now* it gets interesting. Because what's came to the list was text:

Message-ID: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yet it passed DKIM test.

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-16 Thread l0f4r0
Hi,

13 juin 2020 à 21:05 de recovery...@enotuniq.net:

> Hi.
>
> On Sat, Jun 13, 2020 at 09:01:59PM +0200, l0f...@tuta.io wrote:
>
>> 13 juin 2020 à 17:12 de recovery...@enotuniq.net:
>>
>> > On Sat, Jun 13, 2020 at 06:10:15PM +0300, Reco wrote:
>> >
>> >> Let's see.
>> >>
>> >> >From what I saw this should fail DKIM test.
>> >>
>> >> And, for the good measure:
>> >>
>> >> >From: this is not a valid RFC-822 header
>> >>
>> >
>> > Ok, clearly I don't have any problem with DKIM on this list.
>> >
>> Ok let's see for me as well:
>>
>> >From my point of view
>>
>> >From: l0f4r0
>>
>> l0f4r0
>>
> Your e-mail passed DKIM test on my MTA with flying colors.
>
> Try that base64-encoded html thing next.
>
It was already base64 encoded, see below:

--79Bu5A16qPEYcVIZL@tutanota
Content-Type: text/html; charset=UTF-8
Content-transfer-encoding: base64

PGRpdj4xMyBqdWluIDIwMjAgw6AgMTc6MTIgZGUgcmVjb3ZlcnltNG5AZW5vdHVuaXEubmV0Ojxicj
48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0idHV0YW5vdGFfcXVvdGUiPjxkaXY+T24gU2F0LCBKdW4g
MTMsIDIwMjAgYXQgMDY6MTA6MTVQTSArMDMwMCwgUmVjbyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcX
VvdGU+PGRpdj5MZXQncyBzZWUuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jmd0O0Zyb20g
d2hhdCBJIHNhdyB0aGlzIHNob3VsZCBmYWlsIERLSU0gdGVzdC48YnI+PC9kaXY+PGRpdj48YnI+PC
9kaXY+PGRpdj5BbmQsIGZvciB0aGUgZ29vZCBtZWFzdXJlOjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp
dj48ZGl2PiZndDtGcm9tOiB0aGlzIGlzIG5vdCBhIHZhbGlkIFJGQy04MjIgaGVhZGVyPGJyPjwvZG
l2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9rLCBjbGVhcmx5IEkgZG9uJ3QgaGF2
ZSBhbnkgcHJvYmxlbSB3aXRoIERLSU0gb24gdGhpcyBsaXN0Ljxicj48L2Rpdj48L2Jsb2NrcXVvdG
U+PGRpdj5PayBsZXQncyBzZWUgZm9yIG1lIGFzIHdlbGw6PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2
PjxkaXY+Jmd0O0Zyb20gbXkgcG9pbnQgb2Ygdmlldzxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZG
l2PiZndDtGcm9tOiBsMGY0cjA8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5sMGY0cjA8YnI+
PC9kaXY+

--79Bu5A16qPEYcVIZL@tutanota--

l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-15 Thread l0f4r0
Hi,

13 juin 2020 à 21:14 de recovery...@enotuniq.net:

> You're looking at the wrong header. It's X-Spam-Status and
> X-Amavis-Spam-Status you should worry about. Authetication-Results is
> set by your MTA receiving your own mail from the list.
>
> But yes, they are both OK for this and your previous e-mails.
>
Ok, thanks but still confusing...


> Which one of these is under your control btw, w3.tutanota.de or
> w4.tutanota.de?
>
None, these are domains from my email provider.
I don't own any email infrastructure myself...

14 juin 2020 à 17:13 de deb...@lionunicorn.co.uk:

> On Sat 13 Jun 2020 at 16:05:17 (+0200), l0f...@tuta.io wrote:
>
>> Thanks, I was not aware of this.
>> However, this extra ">" should have been deleted upon viewing the email, no?
>>
> How would the viewer's email client know whether the > in
> >From had been added by some such scheme as above and should
> be removed, or was a genuine occurrence in the original email?
>
If ">" was intentional, then it could have been escaped with an additional ">".
See https://en.wikipedia.org/wiki/Mbox#Family:

"  >From my point of view...
In the mboxo format, such lines have irreversible ambiguity. In the mboxo 
format, this can lead to corruption of the message. If a line already contained 
>From  at the beginning (such as in a quotation), it is unchanged when written. 
When subsequently read by the mail software, the leading > is erroneously 
removed. The mboxrd format solves this by converting From  to >From  and 
converting >From  to >>From , etc. The transformation is then always 
reversible."

l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-15 Thread Greg Wooledge
On Sun, Jun 14, 2020 at 10:13:11AM -0500, David Wright wrote:
> On Sat 13 Jun 2020 at 16:05:17 (+0200), l0f...@tuta.io wrote:
> > However, this extra ">" should have been deleted upon viewing the email, no?
> 
> How would the viewer's email client know whether the > in
> >From had been added by some such scheme as above and should
> be removed, or was a genuine occurrence in the original email?

Exactly.  It's a non-reversible mangling of the message body, prompted by
an extremely well-known limitation of the mbox formats.

See  for more details.
In particular, we're talking about the
 section.

This same discussion seems to happen every month on this list, and it's
still not clear to me WHY people can't understand it.  It's not a new
phenomenon.  It's been this way forever.



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-14 Thread David Wright
On Sat 13 Jun 2020 at 16:05:17 (+0200), l0f...@tuta.io wrote:
> 13 juin 2020 à 14:21 de a...@strugglers.net:
> 
> > The mbox mail archive format is a single file containing all
> > messages concatenated together. Separate messages are recognised by
> > a line that starts:
> >
> > >From > y...@example.com>  ...
> >
> > As you can imagine if a message body contained such text it might
> > prematurely end the emails and then the next email would be of an
> > invalid format.
> >
> > As a result a lot of (mostly older) mail software escapes mail body
> > lines that begin with "From" by putting a ">" in front, sometimes
> > even when not in the context of archiving into an mbox. This is most
> > likely what happened here. The use of ">" for this is just a very
> > common convention.
> >
> Thanks, I was not aware of this.
> However, this extra ">" should have been deleted upon viewing the email, no?

How would the viewer's email client know whether the > in
>From had been added by some such scheme as above and should
be removed, or was a genuine occurrence in the original email?

> If I'm right, escaping "From" with a leading ">" is just for mailing software 
> internals (mbox), the reverse process is applied when displaying the final 
> message...

Cheers,
David.



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Steve McIntyre
Andy Smith wrote:
>On Sat, Jun 13, 2020 at 12:21:12PM +, Andy Smith wrote:
>> The mbox mail archive format is a single file containing all
>> messages concatenated together. Separate messages are recognised by
>> a line that starts:
>> 
>> >From y...@example.com ...
>
>Amusingly I didn't think to point out that by sending a line that
>starts with that, Debian's list software will quote it! I should
>probably have indented it with whitespace. Anyway, I didn't type the
>">" there; Debian's list software inserted it.

Nod. Smartlist is based on procmail, and that is keen on adding ">" to
the beginning of lines starting with "From", even when it's *not*
working on mbox-style folders.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Reco
On Sat, Jun 13, 2020 at 09:05:24PM +0200, l0f...@tuta.io wrote:
> 13 juin 2020 à 21:01 de l0f...@tuta.io:
> 
> > Ok let's see for me as well:
> >
> > >From my point of view
> >
> > >From: l0f4r0
> >
> > l0f4r0
> >
> Everything's ok:
> 
> Authentication-Results: w3.tutanota.de (dis=neutral; info=dmarc domain 
> policy); 
> dmarc=pass (dis=neutral p=quarantine; aspf=r; adkim=s; pSrc=dns) 
> header.from=tuta.io;
> dkim=pass header.d=tuta.io header.s=s1 header.b=m6Vop4KZ

You're looking at the wrong header. It's X-Spam-Status and
X-Amavis-Spam-Status you should worry about. Authetication-Results is
set by your MTA receiving your own mail from the list.

But yes, they are both OK for this and your previous e-mails.

Which one of these is under your control btw, w3.tutanota.de or
w4.tutanota.de?

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread l0f4r0
13 juin 2020 à 21:01 de l0f...@tuta.io:

> Ok let's see for me as well:
>
> >From my point of view
>
> >From: l0f4r0
>
> l0f4r0
>
Everything's ok:

Authentication-Results: w3.tutanota.de (dis=neutral; info=dmarc domain policy); 
dmarc=pass (dis=neutral p=quarantine; aspf=r; adkim=s; pSrc=dns) 
header.from=tuta.io;
dkim=pass header.d=tuta.io header.s=s1 header.b=m6Vop4KZ

Really confusing...

l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Reco
Hi.

On Sat, Jun 13, 2020 at 09:01:59PM +0200, l0f...@tuta.io wrote:
> 13 juin 2020 à 17:12 de recovery...@enotuniq.net:
> 
> > On Sat, Jun 13, 2020 at 06:10:15PM +0300, Reco wrote:
> >
> >> Let's see.
> >>
> >> >From what I saw this should fail DKIM test.
> >>
> >> And, for the good measure:
> >>
> >> >From: this is not a valid RFC-822 header
> >>
> >
> > Ok, clearly I don't have any problem with DKIM on this list.
> >
> Ok let's see for me as well:
> 
> >From my point of view
> 
> >From: l0f4r0
> 
> l0f4r0

Your e-mail passed DKIM test on my MTA with flying colors.

Try that base64-encoded html thing next.

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread l0f4r0
13 juin 2020 à 17:12 de recovery...@enotuniq.net:

> On Sat, Jun 13, 2020 at 06:10:15PM +0300, Reco wrote:
>
>> Let's see.
>>
>> >From what I saw this should fail DKIM test.
>>
>> And, for the good measure:
>>
>> >From: this is not a valid RFC-822 header
>>
>
> Ok, clearly I don't have any problem with DKIM on this list.
>
Ok let's see for me as well:

>From my point of view

>From: l0f4r0

l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Reco
Hi.

On Sat, Jun 13, 2020 at 12:21:12PM +, Andy Smith wrote:
> Hi,
> 
> On Sat, Jun 13, 2020 at 02:08:14PM +0200, l0f...@tuta.io wrote:
> > 13 juin 2020 à 09:52 de a...@strugglers.net:
> > > Looking at the email concerned, it had a line starting with "From"
> > > quoted with a ">".
> > >
> > Indeed! I hope it's not a mistake of mine (usually I proofread my emails 
> > before sending them but who knows...).
> 
> It was almost certainly done by Debian's mailing list software.

It was definitely done by Debian's mailing list software.
It looks like this:

1) bendel.debian.org (postfix) receives the e-mail in question from
w4.tutanota.de.

2) bendel (postfix) feeds incoming e-mail to bendel (amavisd), which
reports that DKIM is OK:

X-Amavis-Spam-Status: No, ... DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1 ...

3) bendel (amavisd) tosses e-mail back to bendel (postfix), which tosses
it in turn to bendel (spamassassin).

4) The latter reports that DKIM test failed:

X-Spam-Status: No, ... tests=DIGITS_LETTERS,DKIM_INVALID, DKIM_SIGNED

5) bendel (spamassassin) tosses the e-mail to bendel (postfix) again,
the latter does the delivery. DKIM test fails again:

Authentication-Results: w3.tutanota.de (dis=spam; info=dmarc domain policy); 
dmarc=fail (dis=spam p=quarantine; aspf=r; adkim=s; pSrc=dns) 
header.from=tuta.io; dkim=fail reason="body hash does not match"

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Reco
On Sat, Jun 13, 2020 at 06:10:15PM +0300, Reco wrote:
>   Hi.
> 
> On Sat, Jun 13, 2020 at 04:32:02PM +0200, l0f...@tuta.io wrote:
> > I've another example: 
> > https://lists.debian.org/debian-user/2020/06/msg00016.html
> > One more time, I started a new line with "From" which got escaped with a 
> > leading ">".
> > Result: dkim=fail reason="body hash does not match".
> > Maybe it's the root cause after all...
> > Does someone else have DKIM issues as well? Or maybe you don't pay 
> > attention to that ;)
> 
> Let's see.
> 
> >From what I saw this should fail DKIM test.
> 
> And, for the good measure:
> 
> >From: this is not a valid RFC-822 header

Ok, clearly I don't have any problem with DKIM on this list.

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Reco
Hi.

On Sat, Jun 13, 2020 at 04:32:02PM +0200, l0f...@tuta.io wrote:
> I've another example: 
> https://lists.debian.org/debian-user/2020/06/msg00016.html
> One more time, I started a new line with "From" which got escaped with a 
> leading ">".
> Result: dkim=fail reason="body hash does not match".
> Maybe it's the root cause after all...
> Does someone else have DKIM issues as well? Or maybe you don't pay attention 
> to that ;)

Let's see.

>From what I saw this should fail DKIM test.

And, for the good measure:

>From: this is not a valid RFC-822 header

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread l0f4r0
I've another example: https://lists.debian.org/debian-user/2020/06/msg00016.html
One more time, I started a new line with "From" which got escaped with a 
leading ">".
Result: dkim=fail reason="body hash does not match".
Maybe it's the root cause after all...
Does someone else have DKIM issues as well? Or maybe you don't pay attention to 
that ;)

Anyway, what I understand so far is that one has no guarantee DKIM will succeed 
when writing to mailing lists. Maybe it's not so serious as long as there is no 
specific DMARC policy discarding the emails...

l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Andy Smith
Hi,

On Sat, Jun 13, 2020 at 09:28:45AM -0400, Gene Heskett wrote:
> On Saturday 13 June 2020 09:19:39 Andy Smith wrote:
> > On Sat, Jun 13, 2020 at 09:12:06AM -0400, Gene Heskett wrote:
> > > No > present
> >
> > I think you are confused. None of us wrote any such line so I have
> > no idea where you are seeing it, unless you are looking at the header
> > section and getting confused. We are talking about the body of the
> > email. You can see the ">From" text in the archives and in the
> > original message in this thread if you look in your own mail client:
> >
> The quote was from the rawmessage display that tde's version of kmail 
> gives you for a press of the v key, and yes its from the header.

Which is not, and has never been, what we are talking about. Please
read more carefully.

> > https://lists.debian.org/debian-user/2020/06/msg00215.html
> 
> Looks normal there.

If you do not see a line on the above web page that starts with
">From" then something is very very wrong somewhere. But I think you
have not looked hard enough.

Regards,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread l0f4r0
Hi,

13 juin 2020 à 14:21 de a...@strugglers.net:

> The mbox mail archive format is a single file containing all
> messages concatenated together. Separate messages are recognised by
> a line that starts:
>
> >From > y...@example.com>  ...
>
> As you can imagine if a message body contained such text it might
> prematurely end the emails and then the next email would be of an
> invalid format.
>
> As a result a lot of (mostly older) mail software escapes mail body
> lines that begin with "From" by putting a ">" in front, sometimes
> even when not in the context of archiving into an mbox. This is most
> likely what happened here. The use of ">" for this is just a very
> common convention.
>
Thanks, I was not aware of this.
However, this extra ">" should have been deleted upon viewing the email, no?
If I'm right, escaping "From" with a leading ">" is just for mailing software 
internals (mbox), the reverse process is applied when displaying the final 
message...

13 juin 2020 à 15:12 de ghesk...@shentel.net:

> On Saturday 13 June 2020 08:24:49 Andy Smith wrote:
>
>> Amusingly I didn't think to point out that by sending a line that
>> starts with that, Debian's list software will quote it! I should
>> probably have indented it with whitespace. Anyway, I didn't type the
>> ">" there; Debian's list software inserted it.
>>
> It is not present when your msg arrives here.
>
I confirm. Maybe it's your email client that did that?

l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Gene Heskett
On Saturday 13 June 2020 09:19:39 Andy Smith wrote:

> Hi Gene,
>
> On Sat, Jun 13, 2020 at 09:12:06AM -0400, Gene Heskett wrote:
> > Here is a copy/paste of the from line as it arrives here
> >  From: l0f...@tuta.io
> > No > present
>
> I think you are confused. None of us wrote any such line so I have
> no idea where you are seeing it, unless you are looking at the header
> section and getting confused. We are talking about the body of the
> email. You can see the ">From" text in the archives and in the
> original message in this thread if you look in your own mail client:
>
The quote was from the rawmessage display that tde's version of kmail 
gives you for a press of the v key, and yes its from the header.

> https://lists.debian.org/debian-user/2020/06/msg00215.html

Looks normal there. Bur that msg is not From: l0f...@tuta.io
its from you.

> Cheers,
> Andy


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Jim Popovitch
On Sat, 2020-06-13 at 07:56 +, Andy Smith wrote:
> On Sat, Jun 13, 2020 at 07:52:55AM +, Andy Smith wrote:
> > Looking at the email concerned, it had a line starting with "From"
> > quoted with a ">".
> > 
> > Mailing lists often do things like that, breaking DKIM.
> 
> I will add that I recall that Debian postmasters have been asked
> before about making changes to accommodate receiving sites that are
> strict about DKIM, and they explicitly declined to do so. I think
> that was more in the context of rewriting the mail's From header
> though (not preventing body changes as is the case here).
> 
> So I would not expect the DKIM situation to change any time soon with
> regard to Debian mailing lists.

DKIM and Mailinglists has never changed, it's never been advised to mix
the two, and it won't be.  What you should be aspiring for is ARC.

-Jim P.



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Andy Smith
Hi Gene,

On Sat, Jun 13, 2020 at 09:12:06AM -0400, Gene Heskett wrote:
> Here is a copy/paste of the from line as it arrives here
>  From: l0f...@tuta.io
> No > present

I think you are confused. None of us wrote any such line so I have
no idea where you are seeing it, unless you are looking at the header
section and getting confused. We are talking about the body of the
email. You can see the ">From" text in the archives and in the
original message in this thread if you look in your own mail client:

https://lists.debian.org/debian-user/2020/06/msg00215.html

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Gene Heskett
On Saturday 13 June 2020 08:24:49 Andy Smith wrote:

> On Sat, Jun 13, 2020 at 12:21:12PM +, Andy Smith wrote:
> > The mbox mail archive format is a single file containing all
> > messages concatenated together. Separate messages are recognised by
> >
> > a line that starts:
> > >From y...@example.com ...
>
> Amusingly I didn't think to point out that by sending a line that
> starts with that, Debian's list software will quote it! I should
> probably have indented it with whitespace. Anyway, I didn't type the
> ">" there; Debian's list software inserted it.
>
It is not present when your msg arrives here.

> Cheers,
> Andy
Here is a copy/paste of the from line as it arrives here
 From: l0f...@tuta.io
No > present

So I would be questioning your service provider. tuta.io

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Andy Smith
On Sat, Jun 13, 2020 at 12:21:12PM +, Andy Smith wrote:
> The mbox mail archive format is a single file containing all
> messages concatenated together. Separate messages are recognised by
> a line that starts:
> 
> >From y...@example.com ...

Amusingly I didn't think to point out that by sending a line that
starts with that, Debian's list software will quote it! I should
probably have indented it with whitespace. Anyway, I didn't type the
">" there; Debian's list software inserted it.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

> The optimum programming team size is 1.
Has Jurassic Park taught us nothing? — pfilandr



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Andy Smith
Hi,

On Sat, Jun 13, 2020 at 02:08:14PM +0200, l0f...@tuta.io wrote:
> 13 juin 2020 à 09:52 de a...@strugglers.net:
> > Looking at the email concerned, it had a line starting with "From"
> > quoted with a ">".
> >
> Indeed! I hope it's not a mistake of mine (usually I proofread my emails 
> before sending them but who knows...).

It was almost certainly done by Debian's mailing list software.

> Why would they do that? ">" is rather usually indicated to insert quotations 
> isn't it?

The mbox mail archive format is a single file containing all
messages concatenated together. Separate messages are recognised by
a line that starts:

>From y...@example.com ...

As you can imagine if a message body contained such text it might
prematurely end the emails and then the next email would be of an
invalid format.

As a result a lot of (mostly older) mail software escapes mail body
lines that begin with "From" by putting a ">" in front, sometimes
even when not in the context of archiving into an mbox. This is most
likely what happened here. The use of ">" for this is just a very
common convention.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread l0f4r0
Hi,

12 juin 2020 à 22:53 de recovery...@enotuniq.net:

> Yes, but I just cannot find that particular e-mail of yours with
> Message-Id: <> m9er2er--...@tuta.io> >.
>
I didn't understand where you got the ID then? ^^

> And the search via Web interface finds nothing.
>
https://lists.debian.org/debian-user/2020/06/msg00215.html

12 juin 2020 à 23:16 de mst...@debian.org:

> On Fri, Jun 12, 2020 at 11:53:40PM +0300, Reco wrote:
>
>> No, the body is not interesting at all here.
>> What I'm interested in is the result of DKIM check, and that's might be
>> written in e-mail headers. Or not.
>>
> dkim=fail (2048-bit key) reason="fail (body has been altered)"
>   
>  header.d=tuta.io
>
Thanks Michael. The "reason" is stated a little bit differently from my side 
but it boils down to the same thing. Here are the full headers as requested by 
Reco:

Authentication-Results: w3.tutanota.de (dis=spam; info=dmarc domain policy);
dmarc=fail (dis=spam p=quarantine; aspf=r; adkim=s; pSrc=dns) 
header.from=tuta.io;  dkim=fail reason="body hash does not match" 
header.d=tuta.io header.s=s1 header.b=FCKFHXRgReceived: from w4.tutanota.de 
([192.168.1.165])by w3.tutanota.dewith SMTP (SubEthaSMTP 3.1.7) 
id KB5CNTA9for l0f...@tuta.io;Sun, 07 Jun 2020 19:38:11 +0200 
(CEST)Received-SPF: None (mailfrom) identity=mailfrom; client-ip=82.195.75.100; 
helo=bendel.debian.org; 
envelope-from=bounce-debian-user=l0f4r0=tuta...@lists.debian.org; 
receiver= Received: from bendel.debian.org (bendel.debian.org 
[82.195.75.100]) by w4.tutanota.de (Postfix) with ESMTPS id E710910602CF for 
; Sun,  7 Jun 2020 17:38:11 + (UTC)Received: from localhost 
(localhost [127.0.0.1]) by bendel.debian.org (Postfix) with QMQPid 
645DA20490; Sun,  7 Jun 2020 17:38:07 + (UTC)X-Mailbox-Line: From 
debian-user-requ...@lists.debian.org Sun Jun  7 17:38:07 2020Old-Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on 
bendel.debian.orgX-Spam-Level: X-Spam-Status: No, score=-9.9 required=4.0 
tests=DIGITS_LETTERS,DKIM_INVALID,  
DKIM_SIGNED,LDOSUBSCRIBER,LDO_WHITELIST,RCVD_IN_DNSWL_NONE, 
RCVD_IN_MSPIKE_H2 autolearn=unavailable autolearn_force=no  
version=3.4.2X-Original-To: lists-debian-u...@bendel.debian.org Delivered-To: 
lists-debian-u...@bendel.debian.org Received: from localhost (localhost 
[127.0.0.1])  by bendel.debian.org (Postfix) with ESMTP id 28D0220487 for 
; Sun,  7 Jun 2020 17:38:00 + 
(UTC)X-Virus-Scanned: at lists.debian.org with policy bank 
en-htX-Amavis-Spam-Status: No, score=-6.201 tagged_above=-1 required=5.3
  tests=[BAYES_00=-2, DIGITS_LETTERS=1, DKIM_SIGNED=0.1,  DKIM_VALID=-0.1, 
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,LDO_WHITELIST=-5, 
RCVD_IN_DNSWL_NONE=-0.0001,   RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham 
autolearn_force=noReceived: from bendel.debian.org ([127.0.0.1])by 
localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)with ESMTP 
id E4EkTvek1ETa for ;   Sun,  7 Jun 2020 
17:37:55 + (UTC)X-policyd-weight: using cached result; rate: -4.6Received: 
from w4.tutanota.de (w4.tutanota.de [81.3.6.165])   (using TLSv1.3 with 
cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (2048 bits) server-digest SHA256   client-signature 
RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tutanota.com", Issuer 
"Sectigo RSA Domain Validation Secure Server CA" (not verified))  by 
bendel.debian.org (Postfix) with ESMTPS id AE09620485for 
; Sun,  7 Jun 2020 17:37:55 + (UTC)Received: 
from w3.tutanota.de (unknown [192.168.1.164])by w4.tutanota.de 
(Postfix) with ESMTP id E763E1060254  for ; Sun,  
7 Jun 2020 17:37:52 + (UTC)DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; 
c=relaxed/relaxed; t=1591551472; s=s1; d=tuta.io;
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
  bh=s0Y3rXEVXjnN/M6XYAtvSYoqbqPfl8XS3uJxBmHyC0Q=;
b=FCKFHXRgAWn5LR7h0/3d6Xxik44GKm3SLLgp0YhDEVrIFOC6xrJZYVh7ccv1UQGf  
6QtvLewAWCYnk1VUntaSnEXprLS2Eh9uQnCN7XVbiMA5oguf6QQ4lohnRviwtTt3x3K 
NFThvwzmLuHereSCAeBoWoaNLqqZltQsUdg6tS5ubUphw0jvwHywxQT6X2floh9rFko 
kBqkQZD1nFfAgLtVuwIYm+PSv6+2FA51nufGuk5LOm3RAYUzk5J2S6mqKm0z2Dulc5i 
XAvanOIePofjpXG/ARkuqgbd306GVKL6chiqfbVl/5ZMIS5PDEshxufAxi9/MLIwoxp 
cNeZzZT14A==Date: Sun, 7 Jun 2020 19:37:52 +0200 (CEST)From: l0f...@tuta.io To: 
Debian User Message-ID: 
In-Reply-To: 
References: 
Subject: Re: why !oh why Debian 
and application listMIME-Version: 1.0Content-Type: text/plain; 
charset=UTF-8Content-Transfer-Encoding: quoted-printableX-Rc-Virus: 
2007-09-13_01X-Rc-Spam:

Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Andy Smith
On Sat, Jun 13, 2020 at 07:52:55AM +, Andy Smith wrote:
> Looking at the email concerned, it had a line starting with "From"
> quoted with a ">".
> 
> Mailing lists often do things like that, breaking DKIM.

I will add that I recall that Debian postmasters have been asked
before about making changes to accommodate receiving sites that are
strict about DKIM, and they explicitly declined to do so. I think
that was more in the context of rewriting the mail's From header
though (not preventing body changes as is the case here).

So I would not expect the DKIM situation to change any time soon with
regard to Debian mailing lists.

It is one of the reasons why I support moving to Discourse for use
cases such as this list.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Andy Smith
Hi,

On Fri, Jun 12, 2020 at 10:30:44PM +0200, l0f...@tuta.io wrote:
> 12 juin 2020 à 22:16 de mst...@debian.org:
> > More information from the OP, it looks like the message sent to the list 
> > was base64 encoded html. So I'm guessing that the list software 
> > autoconverted that to plain text--which would mean there's no way to 
> > preserve a valid DKIM signature.
> >
> It's a nice explanation BUT why most of my emails are ok then on the ML?

Looking at the email concerned, it had a line starting with "From"
quoted with a ">".

Mailing lists often do things like that, breaking DKIM.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-13 Thread Andrei POPESCU
On Vi, 12 iun 20, 22:45:13, l0f...@tuta.io wrote:
> 12 juin 2020 à 22:32 de recovery...@enotuniq.net:
> 
> > Of course,
> > refraining from sending html e-mails here would be easier solution ;)
> >
> I'd like nothing better but it seems this is not possible currently on 
> Tutanota web app.

You could be using any provider to *post* to mailing lists with public 
archives.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread Michael Stone

On Fri, Jun 12, 2020 at 11:53:40PM +0300, Reco wrote:

No, the body is not interesting at all here.
What I'm interested in is the result of DKIM check, and that's might be
written in e-mail headers. Or not.


   dkim=fail (2048-bit key) reason="fail (body has been altered)"
   header.d=tuta.io  



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread Reco
On Fri, Jun 12, 2020 at 10:45:13PM +0200, l0f...@tuta.io wrote:
> Hi Reco,
> 
> 12 juin 2020 à 22:32 de recovery...@enotuniq.net:
> 
> > Removing Content-Type (and maybe Content-Transfer-Encoding) from OP's
> > DKIM policy should do the trick, although it can has certain undesirable
> > side-effects if MTA in question is used for other purposes.
> >
> Thanks, I will submit this lead to my email provider.

As Michael Stone helpfully pointed - it might not be enough.


> > I'd like to see a headers of this problematic e-mail too. Can you post
> > them please?
> >
> I'm not sure to understand  your request.
> The only headers I  have are those from incoming emails. As a ML subscriber 
> you have access to the headers like me, don't you?

Yes, but I just cannot find that particular e-mail of yours with
Message-Id: .
And the search via Web interface finds nothing.

> Or maybe you are speaking about the original body?

No, the body is not interesting at all here.
What I'm interested in is the result of DKIM check, and that's might be
written in e-mail headers. Or not.

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread l0f4r0
Hi Reco,

12 juin 2020 à 22:32 de recovery...@enotuniq.net:

> Removing Content-Type (and maybe Content-Transfer-Encoding) from OP's
> DKIM policy should do the trick, although it can has certain undesirable
> side-effects if MTA in question is used for other purposes.
>
Thanks, I will submit this lead to my email provider.

> Of course,
> refraining from sending html e-mails here would be easier solution ;)
>
I'd like nothing better but it seems this is not possible currently on Tutanota 
web app.

> I'd like to see a headers of this problematic e-mail too. Can you post
> them please?
>
I'm not sure to understand  your request.
The only headers I  have are those from incoming emails. As a ML subscriber you 
have access to the headers like me, don't you?
Or maybe you are speaking about the original body?
Best regards,
l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread Michael Stone

On Fri, Jun 12, 2020 at 11:32:20PM +0300, Reco wrote:

Hi.

On Fri, Jun 12, 2020 at 04:16:23PM -0400, Michael Stone wrote:

On Fri, Jun 12, 2020 at 12:36:29PM -0400, Michael Stone wrote:
> On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote:
> > On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote:
> > > My email below got a DKIM issue.
> >
> > It validated fine here, not a debian list issue.
>
> For the record, I looked at the wrong email. The right one did fail DKIM 
validation while passing through debian. (Note that it goes from DKIM_VALID to
> DKIM_INVALID in what looks like two subsequent checks on bendel.) On my 
system that one says that it fails dkim because the body was altered. Looking at
> the body my best guess would be that it's a normalization/line length issue 
on the part of the dkim signer, but without the original message that's just a
> guess.

More information from the OP, it looks like the message sent to the list was 
base64 encoded html. So I'm guessing that the list software autoconverted that 
to
plain text--which would mean there's no way to preserve a valid DKIM signature.


There might be a way. Current OP DKIM policy is (I have no idea why
certain headers are listed twice):

DKIM-Signature: ... 
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;

Removing Content-Type (and maybe Content-Transfer-Encoding) from OP's
DKIM policy should do the trick, although it can has certain undesirable
side-effects if MTA in question is used for other purposes.


No, the mail should fail because the body has literally changed (all the 
html tags are gone).




Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread Reco
Hi.

On Fri, Jun 12, 2020 at 04:16:23PM -0400, Michael Stone wrote:
> On Fri, Jun 12, 2020 at 12:36:29PM -0400, Michael Stone wrote:
> > On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote:
> > > On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote:
> > > > My email below got a DKIM issue.
> > > 
> > > It validated fine here, not a debian list issue.
> > 
> > For the record, I looked at the wrong email. The right one did fail DKIM 
> > validation while passing through debian. (Note that it goes from DKIM_VALID 
> > to
> > DKIM_INVALID in what looks like two subsequent checks on bendel.) On my 
> > system that one says that it fails dkim because the body was altered. 
> > Looking at
> > the body my best guess would be that it's a normalization/line length issue 
> > on the part of the dkim signer, but without the original message that's 
> > just a
> > guess.
> 
> More information from the OP, it looks like the message sent to the list was 
> base64 encoded html. So I'm guessing that the list software autoconverted 
> that to
> plain text--which would mean there's no way to preserve a valid DKIM 
> signature.

There might be a way. Current OP DKIM policy is (I have no idea why
certain headers are listed twice):

DKIM-Signature: ... 
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;

Removing Content-Type (and maybe Content-Transfer-Encoding) from OP's
DKIM policy should do the trick, although it can has certain undesirable
side-effects if MTA in question is used for other purposes. Of course,
refraining from sending html e-mails here would be easier solution ;)

I'd like to see a headers of this problematic e-mail too. Can you post
them please?

Reco



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread l0f4r0
Hi,

12 juin 2020 à 22:16 de mst...@debian.org:

> More information from the OP, it looks like the message sent to the list was 
> base64 encoded html. So I'm guessing that the list software autoconverted 
> that to plain text--which would mean there's no way to preserve a valid DKIM 
> signature.
>
It's a nice explanation BUT why most of my emails are ok then on the ML?

NB: no need to send me other specimen for the time being, many thanks :)

Best regards,
l0f4r0



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread Michael Stone

On Fri, Jun 12, 2020 at 12:36:29PM -0400, Michael Stone wrote:

On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote:

On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote:

My email below got a DKIM issue.


It validated fine here, not a debian list issue.


For the record, I looked at the wrong email. The right one did fail 
DKIM validation while passing through debian. (Note that it goes from 
DKIM_VALID to DKIM_INVALID in what looks like two subsequent checks on 
bendel.) On my system that one says that it fails dkim because the 
body was altered. Looking at the body my best guess would be that it's 
a normalization/line length issue on the part of the dkim signer, but 
without the original message that's just a guess.


More information from the OP, it looks like the message sent to the list 
was base64 encoded html. So I'm guessing that the list software 
autoconverted that to plain text--which would mean there's no way to 
preserve a valid DKIM signature. 



Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread Michael Stone

On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote:

On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote:

My email below got a DKIM issue.


It validated fine here, not a debian list issue.


For the record, I looked at the wrong email. The right one did fail DKIM 
validation while passing through debian. (Note that it goes from 
DKIM_VALID to DKIM_INVALID in what looks like two subsequent checks on 
bendel.) On my system that one says that it fails dkim because the body 
was altered. Looking at the body my best guess would be that it's a 
normalization/line length issue on the part of the dkim signer, but 
without the original message that's just a guess.


Received: from localhost (localhost [127.0.0.1])  
   by bendel.debian.org (Postfix) with QMQP  
   id 645DA20490; Sun,  7 Jun 2020 17:38:07 + (UTC)  
X-Mailbox-Line: From debian-user-requ...@lists.debian.org  Sun Jun  7 17:38:07 2020   
Old-Return-Path:  
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bendel.debian.org  
X-Spam-Level: 
X-Spam-Status: No, score=-9.9 required=4.0 tests=DIGITS_LETTERS,DKIM_INVALID, 
   DKIM_SIGNED,LDOSUBSCRIBER,LDO_WHITELIST,RCVD_IN_DNSWL_NONE,   
   RCVD_IN_MSPIKE_H2 autolearn=unavailable autolearn_force=no
   version=3.4.2 
X-Original-To: lists-debian-u...@bendel.debian.org
Delivered-To: lists-debian-u...@bendel.debian.org 
Received: from localhost (localhost [127.0.0.1])  
   by bendel.debian.org (Postfix) with ESMTP id 28D0220487   
   for ; Sun,  7 Jun 2020 17:38:00 + (UTC)  
X-Virus-Scanned: at lists.debian.org with policy bank en-ht   
X-Amavis-Spam-Status: No, score=-6.201 tagged_above=-1 required=5.3   
   tests=[BAYES_00=-2, DIGITS_LETTERS=1, DKIM_SIGNED=0.1,
   DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,  
   LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001, 
   RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from bendel.debian.org ([127.0.0.1])
   by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)  
   with ESMTP id E4EkTvek1ETa for ; 
   Sun,  7 Jun 2020 17:37:55 +00

Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread Michael Stone

On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote:

My email below got a DKIM issue.


It validated fine here, not a debian list issue.



[OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

2020-06-12 Thread l0f4r0
Hi,

My email below got a DKIM issue. This is not the first time for me on this ML 
so I'm trying to debug the situation with my email provider.

Does someone on this list mind forwarding to me (as an attachment please, not 
inline) his/her own specimen of my original email below please? I need 
headers+body, this will help the investigations.

NB: Please ignore this message if you are a Tutanota subscriber.

Thank you in advance & Best regards :)
l0f4r0


7 Jun 2020 19:37 from l0f...@tuta.io:

> Hi,
>
> 7 juin 2020 à 19:23 de notoneofmyse...@gmx.de:
>
>> I just installed Picard, and it does not show up in Sound and Video,
>> where logic would suggest it be.
>>
> >From my side, Picard appears under Multimedia>MusicBrainz Picard.
> Here is the related desktop file (org.musicbrainz.Picard.desktop):
>
> [Desktop Entry]
> Name=MusicBrainz Picard
> Comment=Tag your music with the next generation MusicBrainz tagger
> Exec=picard %F
> Terminal=false
> Type=Application
> StartupNotify=true
> StartupWMClass=MusicBrainz-Picard
> Icon=org.musicbrainz.Picard
> Categories=AudioVideo;Audio;AudioVideoEditing;
> MimeType=audio/x-mp3;audio/ogg;audio/mpeg;application/ogg;audio/x-flac;audio/x-flac+ogg;audio/x-vorbis+ogg;audio/x-speex+ogg;audio/x-oggflac;audio/x-musepack;audio/x-tta;audio/x-ms-wma;audio/x-wavpack;
>
> Best regards,
> l0f4r0
>