This is consistent with what dispatch.sr.ht does and allows users to
have a badge for commits only (and not for patches sent on the mailing
list).
---

No changes in v2, resent for CI.

 gitsrht-update-hook/submitter.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gitsrht-update-hook/submitter.go b/gitsrht-update-hook/submitter.go
index 6a42c35b8b4c..f13652e2e610 100644
--- a/gitsrht-update-hook/submitter.go
+++ b/gitsrht-update-hook/submitter.go
[message trimmed]

This is consistent with what dispatch.sr.ht does and allows users to
have a badge for commits only (and not for patches sent on the mailing
list).
---
 gitsrht-update-hook/submitter.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gitsrht-update-hook/submitter.go b/gitsrht-update-hook/submitter.go
index 6a42c35b8b4c..f13652e2e610 100644
--- a/gitsrht-update-hook/submitter.go
+++ b/gitsrht-update-hook/submitter.go
@@ -271,7 +271,7 @@ func SubmitBuild(submitter BuildSubmitter) ([]BuildSubmission, error) {
 			Tags     []string `json:"tags"`
 		}{
[message trimmed]

Pushed, thanks!

Both pushed, thanks!

It turns out functions parsing messages create legacy email.Message
objects instead of using the more recent email.EmailMessage class. The
old class has a bunch of design issues, e.g. makes it complicated to
handle continuation lines in header fields. To use the new class, users
need to opt-in by explicitly specifying a policy.

Change the mailbox.mbox call to opt-in for email.EmailMessage.

Additionally, switch from the legacy get_payload function to
get_content, which better handles encodings and charsets. Remove the
previous attempt at dealing with continuation lines with make_header and
decode_header. Rename local `email` variables to `msg` to avoid
conflicting with the `email` module name.
[message trimmed]

> I'm not sure this resolves the more fundamental problem, which is that
> parseDate seems to be written with the intent never to prevent a
> Envelope from being returned out of parseEnvelope. I say this because it
> always returns a time.Time, even if it encounters errors. However,
> parseEnvelope ignores this and will not return an Envelope if any errors
> are encountered with parsing dates.
>
> This makes the flawless execution of parseDate essential for the message
> to be displayed, which feels brittle. It looks like the only way to
> guarantee parseDate never prevents the user from seeing the message is
> to make it so it never returns errors, but making date parsing errors
> visible seems valuable - they just have to not prevent the user from
> opening and reading the message. I hope I'm making at least a little bit
> of sense.

My bad, this is already done above.

Does it fix your issue to just use h.Date()?

On Wednesday, July 8, 2020 3:13 PM, Drew DeVault <sir@cmpwn.com> wrote:

> On Wed Jul 8, 2020 at 7:30 AM EDT, Simon Ser wrote:
>
> > One possible alternative would be go-msgauth's dkim-milter 1, but
> > this would just workaround the musl bug. A musl patch would be nicer
> > and benefit other opendkim users.
>
> Doesn't sign outgoing messages last time I checked.

It does, via the -d/-k/-s flags.

On Monday, July 6, 2020 6:02 PM, Drew DeVault <sir@cmpwn.com> wrote:

> I'm not aware of a better option. It's unmaintained but only because
> it's more or less "done".

One possible alternative would be go-msgauth's dkim-milter [1], but
this would just workaround the musl bug. A musl patch would be nicer
and benefit other opendkim users.

[1]: https://github.com/emersion/go-msgauth/tree/master/cmd/dkim-milter