Bug with mail.ParseAddressList()

[euskadi31]

Hello,

The mail.ParseAddressList function can't parse this address: "[email protected] <[email protected]>", which is sent to me by ProtonMail. I have no idea if this is a valid format or not, but since this is production data used by a well-known service, I'm thinking it would be good to support this format.

Here's a PoC and the current result:

package main

import (
	"github.com/davecgh/go-spew/spew"
	"github.com/emersion/go-message/mail"
)

func main() {
	{
		// The address is extracted from .eml file sent by ProtonMail to Yahoo
		al, err := mail.ParseAddressList("[email protected] <[email protected]>")
		spew.Dump(al, err)
	}

	{
		// The address is extracted from .eml file received by Yahoo from ProtonMail
		al, err := mail.ParseAddressList(`"[email protected]" <[email protected]>`)
		spew.Dump(al, err)
	}
}

Result :

➜  poc/ go run main.go 
([]*mail.Address) <nil>
(*errors.errorString)(0x140000101a0)(mail: expected comma)
([]*mail.Address) (len=1 cap=1) {
 (*mail.Address)(0x140000a41c0)("[email protected]" <[email protected]>)
}
(interface {}) <nil>

[emersion]

AFAIU ProtonMail's format is invalid per the RFC.

[euskadi31]

I suspect so, but how should we handle this case?

Of course, I'll try to notify ProtonMail that it produces an address that doesn't conform to the standard.

I'm using this go-message library to delegate the parsing of the email. If this library can't parse the content (which unfortunately isn't compliant), that means I'll have to handle this case upstream, doing the parsing manually or with my own code, which would be a shame, and therefore the go-message library wouldn't be of much use in this case.

Given that we don't control the format of the email received, I'd like to believe that it's up to the go-message library to be robust and tolerant of these issues, right?

What do you think?

[euskadi31]

ProtonMail Support Email :

Hello Axel,   Thank you very much for bringing this issue to our attention.   According to RFC 5322, double quotes are not always required in every scenario. However, you are right that in some cases, Proton does not seem to fully follow RFC 5322 by adding the double quotes.   We will conduct further tests this week and escalate this matter to our backend team for review. We really appreciate your input.   Please note that this may be considered as part of our long-term improvement plans, so we currently do not have an estimated timeline for a fix.   Best regards, Ezra Mail Delivery Team Proton Mail

[emersion]

Thanks for reaching out to ProtonMail.

Historically I've been rejecting patches to accept non-standard emails, because accepting these just normalizes non-standard behavior and I'd become part of the problem. There are also some security concerns (e.g. SMTP smuggling). For emails specifically, since old emails remain basically forever, I've added a few quirks for non-standard behavior.

We just use Go's standard library for parsing address lists, so probably one would need to send a patch there if they wanted to fix it.