Re: master ce63f91025: Add textsec functions for verifying email addresses

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 18 Jan 2022 21:30:39 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > +(defun textsec-name-suspicious-p (name)
> > +  "Say whether NAME looks suspicious.
> > +NAME is (for instance) the free-text name from an email address.
> > +
> > +If it suspicious, nil is returned.  If it is, a string explaining
> > +the problem is returned."
> > +  (cond
> > +   ((not (equal name (ucs-normalize-NFC-string name)))
> > +    (format "`%s' is not in normalized format `%s'"
> > +            name (ucs-normalize-NFC-string name)))
> > +   ((seq-find (lambda (char)
> > +                (and (member char bidi-control-characters)
> > +                     (not (member char
> > +                                  '( ?\N{left-to-right mark}
> > +                                     ?\N{right-to-left mark}
> > +                                     ?\N{arabic letter mark})))))
> > +              name)
> > +    (format "The string contains bidirectional control characters"))
> > +   ((textsec-suspicious-nonspacing-p name))))
> 
> I thought the consensus from the last discussion about this subject was
> to use `bidi-find-overridden-directionality' for this kind of thing, to
> avoid false positives with legitimate use of bidirectional control
> characters.

Yes, using the Unicode security guidelines would produce unnecessary
false positives.  Which could be OK for paranoid minds, I guess, who
are afraid of any bidi controls, even if they don't actually affect
the display order.  Like in this example:

     "אבגד ⁧שונה⁩ מרגיל"

I do hope we will eventually offer separate functions to do that with
fewer false positives (or a way of customizing these textsec functions
to do that).