Re: Re: b4 modifying Cc-tags

Re: Re: b4 modifying Cc-tags

[Konstantin Ryabitsev]

On Tue, Jan 02, 2024 at 09:07:25AM +0100, Geert Uytterhoeven wrote:
> Hi Konstantin,
> 
> On Tue, Jan 2, 2024 at 9:02 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Happy New Year!
> >
> > "b4 am" converts
> >
> >     Cc: linux-m68k@lists.linux-m68k.org
> >
> > in the patch body to
> >
> >     Cc:  <linux-m68k@lists.linux-m68k.org>
> >
> > causing a warning from scripts/checkpatch.pl:
> >
> >     WARNING: Use a single space after Cc:
> >
> > Reproducer:
> >
> >     b4 am 2023121940-enlarged-editor-c9a8@gregkh
> >     cat *mbx | formail -s scripts/checkpatch.pl

Thank you for the report -- fixed in master and backported to stable-0.12.y.

> One more legitimate message caught by the overzealous
> 
>     550 5.7.1 Your message looked spammy to us. Please check
> https://subspace.kernel.org/etiquette.html and resend.
> 
> Thanks for fixing!

The main problem is that your From: is @linux-m68k.org, but you send from
Gmail. I'm afraid there isn't much I can do to tweak things on our end -- even
if we make exceptions for your address on our end, your emails will still
likely be rejected or sent to spam when we try to deliver them.

This really should be fixed on the linux-m68k.org side of things.

-K

Re: Re: Re: b4 modifying Cc-tags

[Konstantin Ryabitsev]

On Tue, Jan 02, 2024 at 04:29:41PM +0100, Geert Uytterhoeven wrote:
> > The main problem is that your From: is @linux-m68k.org, but you send from
> > Gmail. I'm afraid there isn't much I can do to tweak things on our end -- even
> > if we make exceptions for your address on our end, your emails will still
> > likely be rejected or sent to spam when we try to deliver them.
> >
> > This really should be fixed on the linux-m68k.org side of things.
> 
> What is the problem with this?
> This is working fine with the vger.kernel.org mailing lists, and picked up
> by lore.  Only some (not all?) of my emails to {users,tools}@linux.kernel.org
> seem to be rejected?

When a domain is missing DKIM/SPF records, like linux-m68k.org, a lot of
providers assign them a high "spamminess" value. When such messages are sent
via gmail.com or some other large provider, this additionally raises
suspicions, because this is a common spammer tactic (pick a domain without
DMARC settings and then use it to forge the From address).

For example, on our end your message triggered the following spamassassin
rules:

FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS

By itself, this is not usually enough to trigger the spam refusal, but this
does mean that if there's anything else spamassassin doesn't like about your
message, it's likely to be refused. In your particular case, that trigger was
BAYES_50 -- amusingly, probably because of the word "enlarged". :)

We do have a bunch of other custom rules that usually lower the score on
patches and common code-review trailers, which is why most of the time your
messages will be accepted by the list server, but it didn't help in this
particular case.

Overall, I would suggest that whoever is responsible for linux-m68k.org sets
up all the bits required by the modern email delivery stack (DKIM, SPF,
DMARC).

-K

Re: Re: Re: b4 modifying Cc-tags

[Geert Uytterhoeven]

Hi Konstantin,

On Tue, Jan 2, 2024 at 4:59 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Tue, Jan 02, 2024 at 04:29:41PM +0100, Geert Uytterhoeven wrote:
> > > The main problem is that your From: is @linux-m68k.org, but you send from
> > > Gmail. I'm afraid there isn't much I can do to tweak things on our end -- even
> > > if we make exceptions for your address on our end, your emails will still
> > > likely be rejected or sent to spam when we try to deliver them.
> > >
> > > This really should be fixed on the linux-m68k.org side of things.
> >
> > What is the problem with this?
> > This is working fine with the vger.kernel.org mailing lists, and picked up
> > by lore.  Only some (not all?) of my emails to {users,tools}@linux.kernel.org
> > seem to be rejected?
>
> When a domain is missing DKIM/SPF records, like linux-m68k.org, a lot of
> providers assign them a high "spamminess" value. When such messages are sent
> via gmail.com or some other large provider, this additionally raises
> suspicions, because this is a common spammer tactic (pick a domain without
> DMARC settings and then use it to forge the From address).
>
> For example, on our end your message triggered the following spamassassin
> rules:
>
> FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS
>
> By itself, this is not usually enough to trigger the spam refusal, but this
> does mean that if there's anything else spamassassin doesn't like about your
> message, it's likely to be refused. In your particular case, that trigger was
> BAYES_50 -- amusingly, probably because of the word "enlarged". :)

Doh, that's GregKH's fault ;-)

> We do have a bunch of other custom rules that usually lower the score on
> patches and common code-review trailers, which is why most of the time your
> messages will be accepted by the list server, but it didn't help in this
> particular case.
>
> Overall, I would suggest that whoever is responsible for linux-m68k.org sets
> up all the bits required by the modern email delivery stack (DKIM, SPF,
> DMARC).

That would be me (partially ;-)

Looking at linux-foundation.org, I guess that means adding a TXT
record with

    "v=spf1 include:_spf.kernel.org include:_spf.google.com ~all"

+ whatever outgoing servers the users of linux-m68k.org are using?

Although the latter may not be strictly required?
Or are Greg KH and Andrew Morton not using fastmail.com for sending
email, only for receiving?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Re: Re: b4 modifying Cc-tags

[Greg KH]

On Tue, Jan 02, 2024 at 06:03:44PM +0100, Geert Uytterhoeven wrote:
> Although the latter may not be strictly required?
> Or are Greg KH and Andrew Morton not using fastmail.com for sending
> email, only for receiving?

I use fastmail for sending stuff from the domain I use fastmail for
(kroah.com), but not for my linuxfoundation.org emails.

thanks,

greg k-h

Re: Re: Re: Re: b4 modifying Cc-tags

[Konstantin Ryabitsev]

On Tue, Jan 02, 2024 at 06:03:44PM +0100, Geert Uytterhoeven wrote:
> > Overall, I would suggest that whoever is responsible for linux-m68k.org sets
> > up all the bits required by the modern email delivery stack (DKIM, SPF,
> > DMARC).
> 
> That would be me (partially ;-)
> 
> Looking at linux-foundation.org, I guess that means adding a TXT
> record with
> 
>     "v=spf1 include:_spf.kernel.org include:_spf.google.com ~all"
> 
> + whatever outgoing servers the users of linux-m68k.org are using?

That wouldn't be sufficient, because setting SPF by itself won't really do
anything without DKIM signing as well. To set up DKIM with gmail, you'd pretty
much need to pay for their Google Workspace product. It's probably a huge
overkill for this purpose.

> Although the latter may not be strictly required?
> Or are Greg KH and Andrew Morton not using fastmail.com for sending
> email, only for receiving?

If you don't want to set things up and maintain them on your own, you can pay
a provider like fastmail.com to host the sending/receiving bits for you.
Unfortunately, since you have many users sending from @linux-m68k.org, they
will all need to start using fastmail to send mail once it's set up.

Sorry, properly setting up email these days is a thorny process, which is
really why we're down to a handful of major providers who now dictate how
things must be done to everyone else.

-K

Re: b4 modifying Cc-tags

[Pali Rohár]

On Tuesday 02 January 2024 15:49:45 Konstantin Ryabitsev wrote:
> On Tue, Jan 02, 2024 at 06:03:44PM +0100, Geert Uytterhoeven wrote:
> > > Overall, I would suggest that whoever is responsible for linux-m68k.org sets
> > > up all the bits required by the modern email delivery stack (DKIM, SPF,
> > > DMARC).
> > 
> > That would be me (partially ;-)
> > 
> > Looking at linux-foundation.org, I guess that means adding a TXT
> > record with
> > 
> >     "v=spf1 include:_spf.kernel.org include:_spf.google.com ~all"
> > 
> > + whatever outgoing servers the users of linux-m68k.org are using?
> 
> That wouldn't be sufficient, because setting SPF by itself won't really do
> anything without DKIM signing as well.

Is not it really sufficient to have at least one of them? Because these
things are different.

SPF in DNS zone specifies which IP addresses are allowed to send emails
from that DNS domain. DKIM is a signature in the email header, signed by
the private key and reference to public key is in the email header.
Reference can point to any DNS domain. Also in email header can be more
DKIM signatures (e.g. if email is going throw more email servers and
every one signs email). So basically these techniques are orthogonal to
each other.

DMARC is what can require that DKIM signature from the sender domain
must be present in the email.

For a longer time I had experience that DKIM signature was enough to not
mark emails as spam. But maybe spam filters changed and another
technique (SPF or DMARC) is required now too? (I do not have issues with
low traffic servers yet.)

I would recommend you to at least try to setup SPF into your DNS zone
and see if it improves situation or not. In the worst case you would
have to revert setup back.

> To set up DKIM with gmail, you'd pretty
> much need to pay for their Google Workspace product. It's probably a huge
> overkill for this purpose.

That is pity. But according to following discussion, gmail without
gsuite is adding DKIM signature (generated by gmail key):
https://support.google.com/accounts/thread/60798443/dkim-settings-without-gsuite?hl=en

Anyway, I see that linux-m68k.org has MX record pointing to gandi.net.
In past gmail had an option to send emails for non-gmail address via
external smtp server (linked account). Cannot you specify gandi smtp
server + your linux-m68k.org/gandi credentials into gmail settings and
let gandi to sign your emails with DKIM and send them?

> > Although the latter may not be strictly required?
> > Or are Greg KH and Andrew Morton not using fastmail.com for sending
> > email, only for receiving?
> 
> If you don't want to set things up and maintain them on your own, you can pay
> a provider like fastmail.com to host the sending/receiving bits for you.
> Unfortunately, since you have many users sending from @linux-m68k.org, they
> will all need to start using fastmail to send mail once it's set up.
> 
> Sorry, properly setting up email these days is a thorny process,

I think this is a myth and it is not such hard. Experienced sysadmin
must be able to do it and less experienced can learn it. All required
software is available in majority of Linux distributions and manuals and
guides are written. The problems come up when you need to send tons of
emails (when you are provider, lkml resender or so).

> which is
> really why we're down to a handful of major providers who now dictate how
> things must be done to everyone else.
> 
> -K
> 

... which is unfortunately truth :-(

Re: b4 modifying Cc-tags

[Linus Torvalds]

On Tue, 2 Jan 2024 at 16:44, Pali Rohár <pali@kernel.org> wrote:
>
> For a longer time I had experience that DKIM signature was enough to not
> mark emails as spam. But maybe spam filters changed and another
> technique (SPF or DMARC) is required now too? (I do not have issues with
> low traffic servers yet.)

DKIM with proper DMARC rules should be sufficient. At worst,
unmodified emails can be re-sent from other places, but that's kind of
the point of mailing lists, so that's actually an advantage.

But once you've set up DKIM/DMARC, doing SPF too should be so trivial
that it becomes a "why not just that too?" issue.

I note that the kernel.org DKIM setup seems to use "c=relaxed/simple”,
which seems bogus. I think it should use "c=relaxed/relaxed" because
we just know whitespace is too fragile.

At least that seems to be the case with your email (which
mx.google.com reports as

   dkim=neutral (body hash did not verify)

according to the headers I see).

Konstantin, is that c=relaxed/simple intentional?

          Linus

Re: Re: b4 modifying Cc-tags

[Konstantin Ryabitsev]

On Tue, Jan 02, 2024 at 08:35:19PM -0800, Linus Torvalds wrote:
> > For a longer time I had experience that DKIM signature was enough to not
> > mark emails as spam. But maybe spam filters changed and another
> > technique (SPF or DMARC) is required now too? (I do not have issues with
> > low traffic servers yet.)
> 
> DKIM with proper DMARC rules should be sufficient. At worst,
> unmodified emails can be re-sent from other places, but that's kind of
> the point of mailing lists, so that's actually an advantage.
> 
> But once you've set up DKIM/DMARC, doing SPF too should be so trivial
> that it becomes a "why not just that too?" issue.

DMARC requires both DKIM and SPF, so it's not really optional. We will soon
see further twists along that path as "Replay-Resistant ARC" becomes the next
required standard that will further complicate managing mailing lists, but
we're not there yet.

https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/

> I note that the kernel.org DKIM setup seems to use "c=relaxed/simple”,
> which seems bogus. I think it should use "c=relaxed/relaxed" because
> we just know whitespace is too fragile.
> 
> At least that seems to be the case with your email (which
> mx.google.com reports as
> 
>    dkim=neutral (body hash did not verify)
> 
> according to the headers I see).
> 
> Konstantin, is that c=relaxed/simple intentional?

It is, the important "relaxed" is the first one (header content). Nothing
should be doing any whitespace normalization on the body content other than
trimming any trailing whitespace characters, which is what "simple" does
already.

For example a "relaxed/relaxed" means these two Python snippets are identical
as far as DKIM is concerned, even though the second one clearly does something
else entirely.

    if logged_in:
        logger.debug('User is logged in')
        return True
    logger.critical('You must log in first')
    return False

vs:

    if logged_in:
        logger.debug('User is logged in')
    return True
    logger.critical('You must log in first')
    return False

-K

Re: Re: b4 modifying Cc-tags

[Linus Torvalds]

On Tue, 2 Jan 2024 at 21:03, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> > Konstantin, is that c=relaxed/simple intentional?
>
> It is, the important "relaxed" is the first one (header content). Nothing
> should be doing any whitespace normalization on the body content other than
> trimming any trailing whitespace characters, which is what "simple" does
> already.

Hmm. I have distinct memories of seeing people claim that some MS
mailserver would change tabs into spaces, and that you wanted to use
c=relaxed/relaxed for that reason, but I can't find it now, so maybe
that is just some memory failure for me.

                    Linus

Re: b4 modifying Cc-tags

[Geert Uytterhoeven]

Hi Pali,

On Wed, Jan 3, 2024 at 1:44 AM Pali Rohár <pali@kernel.org> wrote:
> On Tuesday 02 January 2024 15:49:45 Konstantin Ryabitsev wrote:
> > On Tue, Jan 02, 2024 at 06:03:44PM +0100, Geert Uytterhoeven wrote:
> > > > Overall, I would suggest that whoever is responsible for linux-m68k.org sets
> > > > up all the bits required by the modern email delivery stack (DKIM, SPF,
> > > > DMARC).
> > >
> > > That would be me (partially ;-)
> > >
> > > Looking at linux-foundation.org, I guess that means adding a TXT
> > > record with
> > >
> > >     "v=spf1 include:_spf.kernel.org include:_spf.google.com ~all"
> > >
> > > + whatever outgoing servers the users of linux-m68k.org are using?
> >
> > That wouldn't be sufficient, because setting SPF by itself won't really do
> > anything without DKIM signing as well.
>
> Is not it really sufficient to have at least one of them? Because these
> things are different.
>
> SPF in DNS zone specifies which IP addresses are allowed to send emails
> from that DNS domain. DKIM is a signature in the email header, signed by
> the private key and reference to public key is in the email header.
> Reference can point to any DNS domain. Also in email header can be more
> DKIM signatures (e.g. if email is going throw more email servers and
> every one signs email). So basically these techniques are orthogonal to
> each other.

That was my understanding as well...

> I would recommend you to at least try to setup SPF into your DNS zone
> and see if it improves situation or not. In the worst case you would
> have to revert setup back.

I could do that, after obtaining a list of all outgoing email servers
used by all linux-m68k.org email users...
E.g. I use Gmail, and my ISP's SMTP relay for sending patches
(I did set up an app-specific password for using Gmail's SMTP relays,
but last time (long ago) I tried, Gmail always replaced the address
in the From: line by the default address configured in Gmail, breaking
other addresses and any "+<sponsor>" additions).

> > To set up DKIM with gmail, you'd pretty
> > much need to pay for their Google Workspace product. It's probably a huge
> > overkill for this purpose.
>
> That is pity. But according to following discussion, gmail without
> gsuite is adding DKIM signature (generated by gmail key):
> https://support.google.com/accounts/thread/60798443/dkim-settings-without-gsuite?hl=en
>
> Anyway, I see that linux-m68k.org has MX record pointing to gandi.net.
> In past gmail had an option to send emails for non-gmail address via
> external smtp server (linked account). Cannot you specify gandi smtp
> server + your linux-m68k.org/gandi credentials into gmail settings and
> let gandi to sign your emails with DKIM and send them?

All linux-m68k.org email addresses are merely forwarding aliases, not
(paid since 2023-12-01) mailboxes.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: b4 modifying Cc-tags

[James Bottomley]

On Wed, 2024-01-03 at 13:26 +0100, Geert Uytterhoeven wrote:
> Hi Pali,
> 
> On Wed, Jan 3, 2024 at 1:44 AM Pali Rohár <pali@kernel.org> wrote:
> > On Tuesday 02 January 2024 15:49:45 Konstantin Ryabitsev wrote:
> > > On Tue, Jan 02, 2024 at 06:03:44PM +0100, Geert Uytterhoeven
> > > wrote:
> > > > > Overall, I would suggest that whoever is responsible for
> > > > > linux-m68korg sets up all the bits required by the modern
> > > > > email delivery stack (DKIM, SPF, DMARC).
> > > > 
> > > > That would be me (partially ;-)
> > > > 
> > > > Looking at linux-foundation.org, I guess that means adding a
> > > > TXT record with
> > > > 
> > > >     "v=spf1 include:_spf.kernel.org include:_spf.google.com
> > > > ~all"
> > > > 
> > > > + whatever outgoing servers the users of linux-m68k.org are
> > > > using?
> > > 
> > > That wouldn't be sufficient, because setting SPF by itself won't
> > > really do anything without DKIM signing as well.
> > 
> > Is not it really sufficient to have at least one of them? Because
> > these things are different.
> > 
> > SPF in DNS zone specifies which IP addresses are allowed to send
> > emails from that DNS domain. DKIM is a signature in the email
> > header, signed by the private key and reference to public key is in
> > the email header. Reference can point to any DNS domain. Also in
> > email header can be more DKIM signatures (e.g. if email is going
> > throw more email servers and every one signs email). So basically
> > these techniques are orthogonal to each other.
> 
> That was my understanding as well...
> 
> > I would recommend you to at least try to setup SPF into your DNS
> > zone and see if it improves situation or not. In the worst case you
> > would have to revert setup back.
> 
> I could do that, after obtaining a list of all outgoing email servers
> used by all linux-m68k.org email users...
> E.g. I use Gmail, and my ISP's SMTP relay for sending patches
> (I did set up an app-specific password for using Gmail's SMTP relays,
> but last time (long ago) I tried, Gmail always replaced the address
> in the From: line by the default address configured in Gmail,
> breaking other addresses and any "+<sponsor>" additions).

Technically if you're going to do SPF like that, you can also do DKIM,
you'd just have to distribute the DKIM key to everyone who uses the
server (or more likely, give each one their own DKIM key and label
which means you can revoke if one leaks).  Each sender would have to
run something like their own opendkim instance, which adds complexity
on the transmitting end, but it is possible.

But I have to say, all this is much easier if your mail domain has its
own system for both sending and receiving.  They're not usually that
expensive (tens of dollars a month) and there are lots of people on
this list who still run their own email servers, so there's a wealth of
technical expertise here to help you.

James

Re: b4 modifying Cc-tags

[Pali Rohár]

On Wednesday 03 January 2024 08:19:15 James Bottomley wrote:
> On Wed, 2024-01-03 at 13:26 +0100, Geert Uytterhoeven wrote:
> > Hi Pali,
> > 
> > On Wed, Jan 3, 2024 at 1:44 AM Pali Rohár <pali@kernel.org> wrote:
> > > On Tuesday 02 January 2024 15:49:45 Konstantin Ryabitsev wrote:
> > > > On Tue, Jan 02, 2024 at 06:03:44PM +0100, Geert Uytterhoeven
> > > > wrote:
> > > > > > Overall, I would suggest that whoever is responsible for
> > > > > > linux-m68korg sets up all the bits required by the modern
> > > > > > email delivery stack (DKIM, SPF, DMARC).
> > > > > 
> > > > > That would be me (partially ;-)
> > > > > 
> > > > > Looking at linux-foundation.org, I guess that means adding a
> > > > > TXT record with
> > > > > 
> > > > >     "v=spf1 include:_spf.kernel.org include:_spf.google.com
> > > > > ~all"
> > > > > 
> > > > > + whatever outgoing servers the users of linux-m68k.org are
> > > > > using?
> > > > 
> > > > That wouldn't be sufficient, because setting SPF by itself won't
> > > > really do anything without DKIM signing as well.
> > > 
> > > Is not it really sufficient to have at least one of them? Because
> > > these things are different.
> > > 
> > > SPF in DNS zone specifies which IP addresses are allowed to send
> > > emails from that DNS domain. DKIM is a signature in the email
> > > header, signed by the private key and reference to public key is in
> > > the email header. Reference can point to any DNS domain. Also in
> > > email header can be more DKIM signatures (e.g. if email is going
> > > throw more email servers and every one signs email). So basically
> > > these techniques are orthogonal to each other.
> > 
> > That was my understanding as well...
> > 
> > > I would recommend you to at least try to setup SPF into your DNS
> > > zone and see if it improves situation or not. In the worst case you
> > > would have to revert setup back.
> > 
> > I could do that, after obtaining a list of all outgoing email servers
> > used by all linux-m68k.org email users...
> > E.g. I use Gmail, and my ISP's SMTP relay for sending patches
> > (I did set up an app-specific password for using Gmail's SMTP relays,
> > but last time (long ago) I tried, Gmail always replaced the address
> > in the From: line by the default address configured in Gmail,
> > breaking other addresses and any "+<sponsor>" additions).

Have not you tried to register/link also additional account with that
"+<sponsor>" suffix into your gmail account? I would expect that gmail
allows to set only registered addressed into From: header and maybe
additional +suffix needs additional register/link.

> 
> Technically if you're going to do SPF like that, you can also do DKIM,
> you'd just have to distribute the DKIM key to everyone who uses the
> server (or more likely, give each one their own DKIM key and label
> which means you can revoke if one leaks).  Each sender would have to
> run something like their own opendkim instance, which adds complexity
> on the transmitting end, but it is possible.

Interesting idea. It is truth that you can have more more DKIM keys in
DNS zone (every key has its own record) but I have never heard that
every user would have its own key, and do signing during sending email.
For me it sounds like totally crazy idea. But when thinking about it,
maybe it would not be such hard to create filter which reads email from
stdin, DKIM-signs it and writes to stdout. Then it would be possible to
combine it together with sendmail or msmtp binaries and git send-email
or any other tool would work without issue. Also creating DKIM signature
should not be such hard, so the filter application/script can be written
in Perl or Python. IIRC git-send-email is written in Perl, so it can be
extended to also append DKIM signature and no need for external daemon
like opendkim? Private key can be read from config file, like smtp
password. :-)

> But I have to say, all this is much easier if your mail domain has its
> own system for both sending and receiving.  They're not usually that
> expensive (tens of dollars a month) and there are lots of people on
> this list who still run their own email servers, so there's a wealth of
> technical expertise here to help you.
> 
> James
> 
> 
> 

Re: b4 modifying Cc-tags

[Pali Rohár]

On Tuesday 02 January 2024 21:25:53 Linus Torvalds wrote:
> On Tue, 2 Jan 2024 at 21:03, Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > > Konstantin, is that c=relaxed/simple intentional?
> >
> > It is, the important "relaxed" is the first one (header content). Nothing
> > should be doing any whitespace normalization on the body content other than
> > trimming any trailing whitespace characters, which is what "simple" does
> > already.
> 
> Hmm. I have distinct memories of seeing people claim that some MS
> mailserver would change tabs into spaces, and that you wanted to use
> c=relaxed/relaxed for that reason, but I can't find it now, so maybe
> that is just some memory failure for me.
> 
>                     Linus
> 

Technically, SMTP server can re-wrap long lines also in the body of the
email during processing it. I do not remember if RFCs permits changes of
tabs to spaces, but who knows that CRLF-based standard is allowed :)

I guess that recent SMTP software would not have "line too big" issue
and would not do rewrapping. But maybe that MS Exchange (or something
else) was doing it...

Anyway, SMTP protocol supports binary transfer of the email but this
(older) extension is not supported by Postfix yet (as one of the
commonly used SMTP server). When intermediate server is going to
transfer such email to Postfix SMTP server, it has no other option than
just reformat it, and broke DKIM signature. Maybe not so common... But
still I would be careful about changes with bytes <= 0x20.

Re: b4 modifying Cc-tags

[Geert Uytterhoeven]

Hi Pali,

On Thu, Jan 4, 2024 at 1:41 AM Pali Rohár <pali@kernel.org> wrote:
> On Wednesday 03 January 2024 08:19:15 James Bottomley wrote:
> > On Wed, 2024-01-03 at 13:26 +0100, Geert Uytterhoeven wrote:
> > > On Wed, Jan 3, 2024 at 1:44 AM Pali Rohár <pali@kernel.org> wrote:
> > > > I would recommend you to at least try to setup SPF into your DNS
> > > > zone and see if it improves situation or not. In the worst case you
> > > > would have to revert setup back.
> > >
> > > I could do that, after obtaining a list of all outgoing email servers
> > > used by all linux-m68k.org email users...
> > > E.g. I use Gmail, and my ISP's SMTP relay for sending patches
> > > (I did set up an app-specific password for using Gmail's SMTP relays,
> > > but last time (long ago) I tried, Gmail always replaced the address
> > > in the From: line by the default address configured in Gmail,
> > > breaking other addresses and any "+<sponsor>" additions).
>
> Have not you tried to register/link also additional account with that
> "+<sponsor>" suffix into your gmail account? I would expect that gmail
> allows to set only registered addressed into From: header and maybe
> additional +suffix needs additional register/link.

IIRC I tried that (don't remember if it succeeded, or if it failed
because the base address was already registered).
Anyway, that won't help much, as the address in the From: line was
always replaced by the default sending address, so sending a patch
series from a different address would mean changing the default in
the web interface first, i.e. lots of manual work.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: b4 modifying Cc-tags

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 1727 bytes --]

Hello Pali,

On 04.01.24 01:41, Pali Rohár wrote:
> On Wednesday 03 January 2024 08:19:15 James Bottomley wrote:
>> Technically if you're going to do SPF like that, you can also do DKIM,
>> you'd just have to distribute the DKIM key to everyone who uses the
>> server (or more likely, give each one their own DKIM key and label
>> which means you can revoke if one leaks).  Each sender would have to
>> run something like their own opendkim instance, which adds complexity
>> on the transmitting end, but it is possible.
> 
> Interesting idea. It is truth that you can have more more DKIM keys in
> DNS zone (every key has its own record) but I have never heard that
> every user would have its own key, and do signing during sending email.
> For me it sounds like totally crazy idea. But when thinking about it,
> maybe it would not be such hard to create filter which reads email from
> stdin, DKIM-signs it and writes to stdout. Then it would be possible to
> combine it together with sendmail or msmtp binaries and git send-email
> or any other tool would work without issue. Also creating DKIM signature
> should not be such hard, so the filter application/script can be written
> in Perl or Python. IIRC git-send-email is written in Perl, so it can be
> extended to also append DKIM signature and no need for external daemon
> like opendkim? Private key can be read from config file, like smtp
> password. :-)

Debian has a setup that includes that idea. I don't use is personally, 
but it seems to work. See 
https://anarc.at/blog/2020-04-14-opendkim-debian/ for a user who does 
make use of it.

However debian also provides a relay which is probably easier to use.

Best regards
Uwe

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: b4 modifying Cc-tags

[Luck, Tony]

> I guess that recent SMTP software would not have "line too big" issue
> and would not do rewrapping. But maybe that MS Exchange (or something
> else) was doing it...

MS Exchange from ~2012 used to swap tabs for spaces, and wrapped long lines
(where "long" was somewhere just over 100). MSFT dropped support
for that version a few years ago. Newer versions of exchange don't do this (so
I can apply patches that have been through Exchange).

-Tony

Re: b4 modifying Cc-tags

[Pali Rohár]

On Thursday 04 January 2024 13:45:58 Uwe Kleine-König wrote:
> Hello Pali,
> 
> On 04.01.24 01:41, Pali Rohár wrote:
> > On Wednesday 03 January 2024 08:19:15 James Bottomley wrote:
> > > Technically if you're going to do SPF like that, you can also do DKIM,
> > > you'd just have to distribute the DKIM key to everyone who uses the
> > > server (or more likely, give each one their own DKIM key and label
> > > which means you can revoke if one leaks).  Each sender would have to
> > > run something like their own opendkim instance, which adds complexity
> > > on the transmitting end, but it is possible.
> > 
> > Interesting idea. It is truth that you can have more more DKIM keys in
> > DNS zone (every key has its own record) but I have never heard that
> > every user would have its own key, and do signing during sending email.
> > For me it sounds like totally crazy idea. But when thinking about it,
> > maybe it would not be such hard to create filter which reads email from
> > stdin, DKIM-signs it and writes to stdout. Then it would be possible to
> > combine it together with sendmail or msmtp binaries and git send-email
> > or any other tool would work without issue. Also creating DKIM signature
> > should not be such hard, so the filter application/script can be written
> > in Perl or Python. IIRC git-send-email is written in Perl, so it can be
> > extended to also append DKIM signature and no need for external daemon
> > like opendkim? Private key can be read from config file, like smtp
> > password. :-)
> 
> Debian has a setup that includes that idea. I don't use is personally, but
> it seems to work. See https://anarc.at/blog/2020-04-14-opendkim-debian/ for
> a user who does make use of it.

Nice to see that somebody already got this idea into production state.

> However debian also provides a relay which is probably easier to use.
> 
> Best regards
> Uwe