Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/mail: fails to parse address list with phrase set to addr-spec #3462

Closed
wathiede opened this issue Apr 3, 2012 · 7 comments
Closed

net/mail: fails to parse address list with phrase set to addr-spec #3462

wathiede opened this issue Apr 3, 2012 · 7 comments
Assignees

Comments

@wathiede
Copy link
Member

@wathiede wathiede commented Apr 3, 2012

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Parsing an email with an address like:  joe@example.com <joe@example.com>
2. See http://play.golang.org/p/TiEMfLNfoI

What is the expected output?
I would expect the Name field to be set to joe@example.com and the Address field too.

What do you see instead?
"mail: expected comma"

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g, whatever runs on the playground

Which operating system are you using?
FreeBSD, Linux, Playground

Which version are you using?  (run 'go version')
go1

Please provide any additional information below.
@wathiede
Copy link
Member Author

@wathiede wathiede commented Apr 3, 2012

Comment 1:

In src/pkg/net/mail/message.go line:226 dsymonds suspects that addr-spec has a more
restricted grammar then name-addr, I think this is the edge case that proves his
suspicion.
@dsymonds
Copy link
Member

@dsymonds dsymonds commented Apr 3, 2012

Comment 2:

I'll look into this.

Owner changed to @dsymonds.

@dsymonds
Copy link
Member

@dsymonds dsymonds commented Apr 3, 2012

Comment 3:

Strictly speaking, "joe@example.com <joe@example.com>" is not an RFC
5322-compliant email address. It does not match name-addr because the initial
"joe@example.com" would need to match display-name => phrase => word => atom,
but the @ character is not a valid atom character. The formal rendering of the address
would need to be:
  "joe@example.com" <joe@example.com>
Having said all that, standards compliance is a noble goal, but strict compliance is not
a hard requirement. We could easily make the net/mail parser more liberal in this
regard. Have you encountered email addresses of that form in the wild? Are they common?

Labels changed: added priority-later, packagechange, removed priority-triage.

Status changed to WaitingForReply.

@wathiede
Copy link
Member Author

@wathiede wathiede commented Apr 4, 2012

Comment 4:

I came across this comparing the output of a python script I wrote and the go version
I'm writing that extracts contacts from my sent folder.  I used to use this webmail
client (http://blog.ilohamail.org/), that apparently let those types of addresses slip
by. I'm also seeing some old Mail.app from my Mac and iPhone OS v3 generated mails with
them too.
I can take a look at email I've received from popular mailing lists to see if mailman,
google groups, etc. let that sort of thing through if you feel it needs to be justified
by "more than one guy on the internet".  Your call, I like following standards too; but
I also like parsing my own files :)
@dsymonds
Copy link
Member

@dsymonds dsymonds commented Apr 4, 2012

Comment 5:

Please do. It'd be good to know.
@wathiede
Copy link
Member Author

@wathiede wathiede commented Apr 4, 2012

Comment 6:

It doesn't look like it is that common on the big lists I compared (python-dev
[mailman], django-developers [Google groups], and zfs-discuss [mailman & jive forum
frontend]) this was a couple of years worth of messages per list.
In part that might be a bad test though, most people reply to email lists, so you'd have
less people typing in the email address and their mail client munging it, which I
suspect would be the common case for this issue to show up.  If a client did sprintf("%s
%s", email, email) instead of sprintf("\"%s\" %s", email, email), which some clients do
according to my research.
I'm okay with you closing this bug and me being the oddball case.  The only reason I
noticed this is because python's built in email package was parsing them.  For
posterity's sake, I wrote a small python and go program to extract To and CC fields from
a glob of files.  I put them up here:
https://github.com/wathiede/GoMailBug 
It is interesting to throw those at a big directory of mail files and try to understand
the differences.  Currently, other than the little problem with my sent folder, the only
issue I spotted was related to headers with unusual whitespacing; as that's already
listed as a TODO, it is to be expected.
@dsymonds
Copy link
Member

@dsymonds dsymonds commented Apr 4, 2012

Comment 7:

Thanks, this is a useful data point to have. I think I'll close this bug; we can reopen
it if anyone else runs into this, or it turns out to be common.

Status changed to WontFix.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.