bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32639: 25.2; message-mode.el: invalid email address gives strange re


From: Lars Ingebrigtsen
Subject: bug#32639: 25.2; message-mode.el: invalid email address gives strange results
Date: Mon, 13 May 2019 16:53:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Antoine Beaupre <address@hidden> writes:

> Emacs' message mode is not very indulgent on invalid email addresses and
> especially typo which can occur in copy-paste.
>
> For example, I tried to send an email today to "foo <address@hidden>"
> only I screwed up when pasting so my "To:" header was actually:
>
>     To: foo bar <address@hidden
>
> ie. without a trailing bracket. Emacs happily accepts this (arguably)
> invalid email address and expands that to "address@hidden" and "bar
> <address@hidden". The former will fail because $fqdn is obviously not
> the right domain and the latter will fail because "bar <quux" is not a
> valid user at "example.com".

Yeah, Message should refuse to try to send email with invalid To/Cc
addresses, I think.

> I've probed a little into how this could be fixed, but somewhat got lost
> between message.el's `message-fix-before-sending' and
> `mail-extract-address-components'. Presumably there's some part in there
> that could be improved, but I am not sure regular expressions are up to
> standard to parse email addresses, as those are notoriously complicated.

The standards-compliant function to use is:

(mail-header-parse-addresses "foo bar <address@hidden")
=> nil

(mail-header-parse-addresses "foo bar <address@hidden>")
=> (("address@hidden" . "foo bar"))

The problem is that this function doesn't really tell the user anything
about what's wrong with the address -- it's either able to parse it or
not.

Another twist here is that if you have at least one valid address in the
list, it won't tell you that there's anything wrong:

(mail-header-parse-addresses "foo bar <address@hidden>, zot>")
=> (("address@hidden" . "foo bar"))

But I guess we could add a parameter to ietf-drums-parse-addresses to
make it return a more complete result.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





reply via email to

[Prev in Thread] Current Thread [Next in Thread]