[wp-trac] [WordPress Trac] #21570: is_email_address_unsafe() is too aggressive

[WordPress Trac]

#21570: is_email_address_unsafe() is too aggressive
----------------------------------------+------------------
 Reporter:  mdawaffe                    |       Owner:
     Type:  defect (bug)                |      Status:  new
 Priority:  normal                      |   Milestone:  3.5
Component:  Users                       |     Version:  3.0
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |
----------------------------------------+------------------
Changes (by westi):

 * milestone:  Awaiting Review => 3.5


Comment:

 Replying to [comment:4 mdawaffe]:
 > The form input is labelled "Banned Email Domains" and says "If you want
 to ban domains from site registrations. One domain per line.", so asking
 people to enter "@bar.com" is weird unless we change those strings.  Plus,
 the option is named "banned_email_domains" :)
 >
 > One "recent" change is [13447], which prevents the use of regular
 expressions, so the {{{preg_match()}}} should be removed unless we want to
 support crazy filters on {{{pre_option_banned_email_domains}}}.  That
 changeset isn't too relevant to this ticket except that it prevents a
 possible solution: adding {{{/\bfoo\.com/}}} to the list of Banned Email
 Domains.
 >
 > I don't think that many people are including a ".bar.com" (as opposed to
 a "bar.com") entry since ".bar.com" does not block a registration from
 "mike at bar.com", for example.
 >
 > With the current code, a "bar.com" entry has the following behavior:
 > * mike at bar.com: blocked = expected
 > * mike at foo.bar.com: blocked = expected
 > * mike at foo-bar.com: blocked = not expected
 >
 > And a ".bar.com" entry does:
 > * mike at bar.com: not blocked = expected? I don't know, see above.
 > * mike at foo.bar.com: blocked = expected
 > * mike at foo-bar.com: not blocked = expected
 >
 > With my patch, the "bar.com" entry does:
 > * mike at bar.com: blocked = expected
 > * mike at foo.bar.com: blocked = expected
 > * mike at foo-bar.com: not blocked = expected
 >
 > And the ".bar.com" entry does:
 > * mike at bar.com: not blocked = expected? I don't know, see above.
 > * mike at foo.bar.com: blocked = expected
 > * mike at foo-bar.com: not blocked = expected

 These test cases look sane to me - we need to get them coded into the
 unit-tests.

 I think not allowing for {{{.ru}}} type blocks is fine as that doesn't
 meet with what I would expect someone to use or the intent of the field
 itself.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21570#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software