I still have some concerns about adding email addresses without permission,

Well again, the only email addresses added in the current version of the PR were those for same core devs who already chose to include them the headers of their other PEPs, and which are all already listed in the Authors Index, so it is only making things consistent between PEPs. Also, I'd initially thought from PEP 12 that the email address was a required element and had the checks enforce that for new PEPs, which is why I'd initially made the change, but I'd then realized after cross-referencing PEP 1 that it wasn't, and updated the checks accordingly.

Much the same is true of user at example.com -> [email protected]—its already obfuscated automatically, having it in the source makes authors (like myself at time) think they had to do it manually, and it modestly complicates the processing and checks, but likewise I quickly realized a relatively small simplification of the code was not worth the potential for more trouble for authors, so I ensured the checks and processing code allow it.

In both cases, there is little benefit conforming the existing source headers when neither is actually required; its just that likewise, it would also be a fair amount of work for no clear benefit to reverting them either, since the emails are already listed and obfuscated. But as it seems its the one thing that's blocking this PR, I guess I'll just bite the bullet and spend the time doing it.

All done—this PR now does not add any existing emails, nor does it conform them to the standard address format. Also fixed what would be a conflict with #2531 , clarified the check feedback a bit further, and a couple other minor refinements.

Actually, I noticed there's actually a significant problem as it stands allowing manual obfuscation—glancing at the _mask_email() source code as part of the trailing comma oversight you noted on #2531 and I then fixed in #2467 , I notice that the automatic obfuscation is actually a fair bit more effective than just replacing @ with a literal at; rather, it actually uses the raw HTML entity codes for some of the characters, significantly raising the bar for scrapers.

However, since emails with manual obfuscation applied don't get converted into reference nodes, the automatic obfuscation logic doesn't work, so these emails actually are substantially less obfuscated than they would otherwise be (which PEP authors are almost certainly unaware of, and wasn't even to me until I dug deep into the code and actually tested it). Picking on myself here, from PEP 0, compare these two:

<tr class="[row-odd]()"><td>Gerlach, C.A.M.</td>
<td>cam.gerlach at gerlach.cam</td>
</tr>

versus, e.g.

<tr class="[row-even]()"><td>van Rossum, Guido (GvR)</td>
<td>guido&#32;&#97;t&#32;python.org</td>
</tr>

I attempted to add support for also properly masking manually obfuscated emails, but after some testing realized it would require some pretty significant code changes due to how things are currently structured, as well as some hacky and potentially unreliable heuristics. Furthermore, I realized this also makes the not showing the email addresses all, or only as abbreviations, as discussed in #2514 more complicated, since whether or not the email is actually processed as an email changes the doctree structure and node types.

Therefore, I conclude it would be best to re-revert the part of the previous change to conform the small minority of emails that were manually obfuscated to use standard email syntax and restore the linter check for such, so they are correctly processed and masked by the header transform code (and anything else that needs to mask/obfuscate/elide them), in order to ensure that the various automatic measures to protect authors' emails work consistently.

Actually, upon giving this more thought, making the author-emails abbrs instead of literal text as discussed in #2514 still requires doing fairly involved string-munging anyway due to having to parse and transform the older Email (author) format, so while it does make things a little more complicated, its not that much worse than parsing a while different syntax.

As such, I suggest we just go ahead and merge this PR as-is with the manual obfuscation still untouched, and then I can address properly masking manually "obfuscated" emails along with formatting them consistently as abbrs in a followup PR. It would also be pretty easy to improve the obfuscation further by choosing different Unicode lookalike characters for the spaces and letters, which coupled with being embedded in the abbr and using raw character codes should make it virtually impossible for spam harvesting, far more so than the common and well known replacement of @ with at.

Since it seems I've satisfied the immediate concerns that were raised and the two PEP editors that previously reviewed have ✔️ ed, this PEP has been open for a while and it seems there aren't any further objections, and it is blocking some further discussed and agreed changes (abbr for emails, making Content-Type optional, etc.,), I'll go ahead and finally merge this now.