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

Prefer simpler addresses in headers when possible #178

Open
bandali0 opened this issue Mar 11, 2024 · 2 comments
Open

Prefer simpler addresses in headers when possible #178

bandali0 opened this issue Mar 11, 2024 · 2 comments

Comments

@bandali0
Copy link

It seems that the mail package almost always puts double-quotes around the 'name' part of addresses e.g. in From, To, etc. headers - even for pure ASCII names without commas, etc. - and I believe it also always wraps the address part in < and >:

  • Example Name <name@example.org> ---> "Example Name" <name@example.org>
  • name@example.org ---> <name@example.org>

It would be nice if the package would make these transformations only if necessary, and otherwise keep the simpler forms.

@emersion
Copy link
Owner

emersion commented Mar 11, 2024

In both of these cases, I believe the "transformation" is necessary per the RFC. Nevermind, both are allowed.

Still I don't really understand why more complicated logic to format these is desirable.

@bandali0
Copy link
Author

My reasoning was that if the slightly shorter/cleaner and more visually pleasing forms (very subjective, I know) are permitted by the RFC, then maybe we'd consider keeping them as-is, unless otherwise required. But I agree that always doing something is indeed inherently simpler than only sometimes doing it. I suppose the how much depends on the case at hand, and as the author/expert here you're arguably the best of judge that. 🙂 So if you think it's too much complexity or not worth it, I'd understand, please feel free to close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants