Sender should certainly not be prohibited. It is inserted by many
clients. If any of the List-* headers are duplicate, it is fine.

Escape the message-id from the archived URL for good measure.

Fixes: e907c2b805c2 ("ingress: fix corrupted messages after forwarding")
Signed-off-by: Robin Jarry <robin@jarry.cc>
---
 ingress/post.go | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/ingress/post.go b/ingress/post.go
index 20dd70fbefa5..57c0c2bdc78c 100644
--- a/ingress/post.go
[message trimmed]

Hi Matthew,

Matthew Bystrin, Jan 13, 2025 at 13:23:
> Recently I've discovered that replying to an HTML message with -q option will
> paste all HTML letter in plain text. Though I can copy&paste converted (in my
> case with w3m) message text, I find it a bit annoying.
>
> What I propose is a special flag to pipe a message into a w3m or similar before
> creating a quotation.

You can do that automatically in the quoted_reply template:

https://git.sr.ht/~rjarry/dotfiles/tree/main/item/config/aerc/templates/quoted_reply

When exiting vim with :cq, it exits with an error status which is caught
in the termClosed() callback. This causes the composer tab to be closed
and it is a known and expected behaviour.

A recent fix of the tab strip removal revealed that the composer lock is
still held when calling RemoveTab(). Internally, RemoveTab() hides and
unfocuses the removed tab both operations require the composer lock as
well, causing a complete deadlock of the application.

Unfortunately, we cannot rely on the go defer statement to have
RemoveTab(), called *AFTER* c.Unlock(). Deferred statements are called
in the reverse order they were evaluated.

Use an explicit function array to ensure that the composer is unlocked
[message trimmed]

For some unknown reason, formatting an email after parsing it with
go-message causes issues. Random line breaks are inserted into the body
of the message. I haven't had the time to properly diagnose what is the
root cause.

To avoid that problem, skip the parsing/reformatting of messages before
forwarding them to subscribers. Simply prepend mailing list headers to
the original buffer. Move "reserved" list headers to the "prohibited"
headers to be handled during the validation phase.

Fixes: d162fddce831 ("Reimplement the ingress daemon using go")
Signed-off-by: Robin Jarry <robin@jarry.cc>
---
 go.mod          |  2 +-
[message trimmed]

email.SendRaw() does not retry on error. Use email.EnqueueRaw to forward
messages to subscribers instead.

For messages originating from lists.sr.ht, use email.EnqueueStd that
already deals with message construction and signing.

Fixes: d162fddce831 ("Reimplement the ingress daemon using go")
Signed-off-by: Robin Jarry <robin@jarry.cc>
---
 ingress/backend.go     | 11 +++++------
 ingress/post.go        |  3 +--
 ingress/smtp.go        |  4 ++--
 ingress/subscribe.go   | 24 +++---------------------
 ingress/unsubscribe.go | 24 +++---------------------
[message trimmed]

Hopefully, this is correct now.

I have ran the whole regression test suite
https://git.sr.ht/~rjarry/lists.sr.ht/commit/4742e15537ec and I checked
that patches can still be applied after being forwarded by the ingress
daemon.

Robin Jarry (2):
  ingress: use outgoing email queue
  ingress: fix corrupted messages after forwarding

 go.mod                 |  2 +-
 go.sum                 |  4 +--
 ingress/backend.go     | 11 ++++---

io.Reader objects can only be consumed once. On retry, re-reading from
them will return 0 bytes all the time.

Change NewTask to take in a bytes array instead of a reader. Create
a new reader on each retry.

Also remove SendRaw which has an inherent issue related to retry as
well. message.Entity is virtually a reader that can only be consumed
once.

Update EnqueueRaw to take a bytes array directly and have it call
NewTask() like EnqueueStd does.

Fixes: 78cfc5d87a7d ("email: allow sending raw emails")
[message trimmed]

Robert Günzler, Jan 11, 2025 at 14:50:
> just out of curiosity, i was only familiar with that from lists that accept
> patches for multiple projects (like with a public inbox)
>
> is there any specific reason we use it here?

This is a requirement for builds.sr.ht to trigger builds on the correct
project.

Also, it has the benefit of being clear which project is targeted just
by looking at the subject.

Robert Günzler, Jan 11, 2025 at 14:41:
> after building from master my styleset wasn't applying any rules for
> highlighting list emails in my inbox. for reference here's a excerpt of
> that, in case anyone wants to see why this is important to me :)
>
> 	msglist_default.List-ID,~github\.com.bg = #52433d
> 	msglist_default.List-ID,~github\.com.selected.fg = toggle
> 	msglist_default.List-ID,~github\.com.selected.bg = toggle
>
> 	msglist_default.List-ID,~lists\.sr\.ht.bg = #0f2540
> 	msglist_default.List-ID,~lists\.sr\.ht.selected.fg = toggle
> 	msglist_default.List-ID,~lists\.sr\.ht.selected.bg = toggle
>
> I was contemplating wether it would be easier to maintain if this wasn't

Io SDB, Jan 11 2025:
> Just wanted to inform you guys that on the GitHub mirror About Page
> (not README) 'repository' is misspelled as 'repositoriy'.

Hi thanks for the heads up. This is now fixed.