Hi,
I've noticed that if I add a single quote in the from field in the accounts.conf file it gets correctly rendered.
In the other hand, if I add double quotes they are not rendered and they simply disappear.
It looks like the rest of the string stays the same.
I've also tried to put multiple double quotes in a row, but still they all disappear.
Is there a work around this?
Thanks,
Fale
--
Fabio Alessandro "Fale" Locati
https://fale.io
On Tue Aug 20, 2024 at 1:10 PM EDT, Fabio Alessandro 'Fale' Locati wrote:
> Hi,>> I've noticed that if I add a single quote in the from field in the accounts.conf file it gets correctly rendered.> In the other hand, if I add double quotes they are not rendered and they simply disappear.> It looks like the rest of the string stays the same.> I've also tried to put multiple double quotes in a row, but still they all disappear.>> Is there a work around this?
I spent a few minutes digging into this. It looks like the go-message
library we are using strips one level of double quotes, so A "B" C
becomes A B C. However, by adding escaped quotes within the quotes, we
can get go-message to turn A "\"B\"" C into A "B" C. But then aerc
further formats this value in the AddressForHumans function
(lib/format/format.go), turning A "B" C into "A 'B' C".
So currently I don't think there's a way to get double quotes into the
From field. If we wanted to change that, we'd have to change how we
format addresses. Based on my brief reading of RFC 5322, I believe that
means we'd need to wrap the name in double quotes and then
backslash-escape the double quotes within it, i.e. "A \"B\" C". This
value is kind of ugly, and clients like aerc that just render the header
value as-is would see the ugly version whereas other clients might
theoretically render it a bit nicer as A "B" C.
On Wed Aug 21, 2024 at 12:13 PM CEST, Jason 'JC' Cox wrote:
> On Tue Aug 20, 2024 at 1:10 PM EDT, Fabio Alessandro 'Fale' Locati wrote:> > Hi,> >> > I've noticed that if I add a single quote in the from field in the accounts.conf file it gets correctly rendered.> > In the other hand, if I add double quotes they are not rendered and they simply disappear.> > It looks like the rest of the string stays the same.> > I've also tried to put multiple double quotes in a row, but still they all disappear.> >> > Is there a work around this?>> I spent a few minutes digging into this. It looks like the go-message> library we are using strips one level of double quotes, so A "B" C> becomes A B C. However, by adding escaped quotes within the quotes, we> can get go-message to turn A "\"B\"" C into A "B" C. But then aerc> further formats this value in the AddressForHumans function> (lib/format/format.go), turning A "B" C into "A 'B' C".>> So currently I don't think there's a way to get double quotes into the> From field. If we wanted to change that, we'd have to change how we> format addresses. Based on my brief reading of RFC 5322, I believe that> means we'd need to wrap the name in double quotes and then> backslash-escape the double quotes within it, i.e. "A \"B\" C". This> value is kind of ugly, and clients like aerc that just render the header> value as-is would see the ugly version whereas other clients might> theoretically render it a bit nicer as A "B" C.
Thanks a lot for your analysis :).
If I understand correctly, you are referring to the UI "From" field.
That's also a problem, but I consider it a less problematic issue.
Personally I would already be happy if my recipients receive the email with a "From:" field without backscapes.
Would this be easier than the displaying of it?
Thanks,
Fale
--
Fabio Alessandro "Fale" Locati
https://fale.io
On Mon Sep 9, 2024 at 5:52 AM EDT, Fabio Alessandro 'Fale' Locati wrote:
> If I understand correctly, you are referring to the UI "From" field.> That's also a problem, but I consider it a less problematic issue.> Personally I would already be happy if my recipients receive the email with a "From:" field without backscapes.> Would this be easier than the displaying of it?
I'm referring to both the UI field and what's actually sent in the
message headers. When composing a message, the contents of the From
field in the aerc UI are used as-is in the headers, at least in my
example. And when viewing a received message, the From field in the aerc
UI shows the value from the headers.
So I think the bottom line here is that we'd have to modify the behavior
of the AddressForHumans function to replace double quotes with
backslash-escaped double quotes rather than with single quotes in order
to get the behavior you're after. Personally I think that's a good idea
-- we should mess with what the user entered as little as possible. They
can always enter single quotes if that's what they want.
I am using the
aliases = a@b.com
directive in my aerc-accounts config.
It works with the same domain, but with other domains, it does not pass dkim.
I found out it was due to RFC5321.MailFrom domain being the wrong one. If I
change my from to
from = "Nicolas Goy" <a@b.com>
then it passes dmarc.
It would be nice if when using alias, the envelope from was also changed to the
alias domain.
--
Nicolas Goy
Developer and Engineer
Goyman SA
Hi Alessandro,
On Mon Sep 9, 2024 at 11:52 AM CEST, Fabio Alessandro 'Fale' Locati
wrote:
> Personally I would already be happy if my recipients receive the email > with a "From:" field without backscapes.
I think this isn't universally possible. I'm not an email expert, but
reading RFC 5322's ABNF rules for the From field, together with
additional comments, it seems that double quotes ('"') can't be easily
added in a way which get shown on all email clients. Here is the
relevant ABNF (I've left out the "-obs" rules to reduce the size of the
quoted parts, since they are obsolete anyway):
from = "From:" mailbox-list CRLF
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
display-name = phrase
phrase = 1*word / obs-phrase
word = atom / quoted-string
atom = [CFWS] 1*atext [CFWS]
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
qcontent = qtext / quoted-pair
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
The RFC also says:
> Semantically, neither the optional CFWS outside of the quote > characters nor the quote characters themselves are part of the > quoted-string; the quoted-string is what is contained between the two > quote characters. As stated earlier, the "\" in any quoted-pair and > the CRLF in any FWS/CFWS that appears within the quoted-string are > semantically "invisible" and therefore not part of the quoted-string > either.
This means that you have two valid From header forms where "Fale" is
double-quoted:
1. From: Fabio Alessandro "Fale" Locati
2. From: Fabio Alessandro "\"Fale\"" Locati
According to the quoted comments about the ABNF rules, the "semantic"
values of the From fields above are, respectively:
1. Fabio Alessandro Fale Locati
2. Fabio Alessandro "Fale" Locati
This means that an email client which shows the From field verbatim,
like aerc, will display backslashes when using the second From form,
while a client which displays only the "semantic" value of the field
will have no quotes if you choose the first form.
In short: just use single quotes.
Hope this makes sense! Bye :)
Hi Nicolas,
On Wed Sep 11, 2024 at 5:24 PM EDT, Nicolas Goy wrote:
> It would be nice if when using alias, the envelope from was also changed to the> alias domain.
I accomplish this by using msmtp rather than aerc's built-in smtp. (See
aerc-sendmail(5)). The --read-envelope-from argument to msmtp will make
it do what you want.
It does seem like using the alias for the envelope from address would be
a nice feature/option for the built-in smtp as well, though.
Jason
On Thu Sep 12, 2024 at 5:45 PM CEST, Jason Cox wrote:
> Hi Nicolas,>> On Wed Sep 11, 2024 at 5:24 PM EDT, Nicolas Goy wrote:> > It would be nice if when using alias, the envelope from was also changed to the> > alias domain.>> I accomplish this by using msmtp rather than aerc's built-in smtp. (See> aerc-sendmail(5)). The --read-envelope-from argument to msmtp will make> it do what you want.
Yes that is a possible workaround for now.
>> It does seem like using the alias for the envelope from address would be> a nice feature/option for the built-in smtp as well, though.
That would be simpler yes.
--
Nicolas Goy
Developer and Engineer
Goyman SA