HeaderParseError on email address ending with '.'

[madduck]

Bug report

from email.headerregistry import Address
a = Address("Jane Doe", addr_spec="jane_doe@example.org.")
[…]
HeaderParseError: expected atext but found ''

The issue is the trailing dot, which is arguably not great, but it's very valid actually, and the email address provided is the same as the email address without a dot.

Your environment

• CPython versions tested on: 3.11.1-1 on Debian unstable
• Operating system and architecture: Debian unstable, amd64

Linked PRs

• gh-101034: Clarify error for email domain ending with a dot #151972

[ericvsmith]

Does this cause an actual problem, or is it hypothetical?

it would help if you could point to a standard for this.

[madduck]

This is actual though probably very much an edge case.

Domain names are defined in RfC1034, where it says in section 3.1:

Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from
implementation to implementation, and in master files, where they are relative to a single origin domain name. The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing.

So example.org is technically incorrect and only interpreted as example.org. because of the convention.

I only found this bug because I copy-pasted from a source that was using the formally correct syntax, and then the python script fell over. Probably applies to an absolute minority, but also probably not a big issue to fix...

[htsedebenham]

@ambv notes from my research:

• As @madduck says, in RFC 1034 - Domain names - concepts and facilities section 3.1 it states

When a user needs to type a domain name, the length of each label is
omitted and the labels are separated by dots (“.”). Since a complete
domain name ends with the root label, this leads to a printed form which
ends in a dot.

• In RFC 5322 - Internet Message Format section 3.4.1 a grammar is given for addr-spec which is what the grammar in https://github.com/python/cpython/blob/main/Lib/email/_header_value_parser.py is based on. This grammar does not explicitly include the case where an email address ends with “.”, but it does refer back to 1034 with

Note: A liberal syntax for the domain portion of addr-spec is
given here. However, the domain portion contains addressing
information specified by and used in other protocols (e.g.,
[ RFC1034 ], [ RFC1035 ], [ RFC1123 ], [ RFC5321 ]).

How is this implemented in other languages?

• Go reports 2009/11/10 23:00:00 mail: trailing dot in atom when running

package main

import (
	"fmt"
	"log"
	"net/mail"
)

func main() {
	e, err := mail.ParseAddress(“Alice <alice@example.com.>")
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println(e.Name, e.Address)
}

• As far as I could tell Rust does not have email address parsing in its standard library.
• .Net allows trailing dots Reference Source, DotAtomReader

At minimum I think it would be useful to add a more informative error than HeaderParseError: expected atext but found '' as per the Go example, even if the behaviour of not allowing trailing dots remains.

[fsc-eriker]

Vaguely related: #75171

[tonghuaroot]

Answering @ericvsmith's earlier question about which standard applies: RFC 5322's addr-spec domain grammar (dot-atom / obs-domain) requires an atom after every ., so a trailing-dot domain like jane_doe@example.org. isn't a valid addr-spec domain — rejecting it is defensible. (@htsedebenham's research above already covers the RFC 1034 vs RFC 5322 §3.4.1 angle.)

The one real defect is the diagnostic. It still reproduces on current main — HeaderParseError: expected atext but found ''. In email._header_value_parser.get_domain, the obs-domain fallback reaches the final . and calls get_atom(''), which surfaces that bare message instead of anything pointing at the trailing dot — the "more informative error" @htsedebenham asked for.

I've opened #151972 with a small fix that raises a clear error (expected atom after '.' ...) instead; behavior is unchanged (still rejected), with regression tests.

If email should instead accept the FQDN-root trailing dot (the RFC 1034 argument in the thread), that's a behavior change that likely deserves its own issue — happy to file that separately, but it needn't block the diagnostic fix.

[madduck]

Great analysis/position, @tonghuaroot. Thanks!

I do think it would make sense to accept the trailing dot even if it's strictly not according to RFC. Would you file it separately, as you suggest? Or should I?