Defect #36969

EmailAddress regex matches invalid email addresses

Added by salman mp 6 months ago. Updated 5 months ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:


Category:Accounts / authentication
Target version:5.1.0
Resolution: Affected version:


There is a regex in the EmailAddress class, that matches some invalid email address like these:


class EmailAddress < ActiveRecord::Base
  include Redmine::SafeAttributes

  EMAIL_REGEXP = /\A([^@\s]+)@((?:[-a-z0-9]+\.)+(?:(?:xn--[-a-z0-9]+)|(?:[a-z]{2,})))\z/i

May be better to use URI::MailTo::EMAIL_REGEXP instead.

36969.patch Magnifier (1.5 KB) Go MAEDA, 2022-04-18 10:42

36969-v2.patch Magnifier (1.92 KB) Go MAEDA, 2022-04-20 02:43


#1 Updated by Go MAEDA 6 months ago

  • File 36969.patchMagnifier added
  • Category set to Accounts / authentication
  • Target version set to 5.1.0

Setting the target version to 5.1.0.

#2 Updated by Go MAEDA 6 months ago

Added a test to the patch.

#3 Updated by Mischa The Evil 6 months ago

  • Description updated (diff)

This effectively changes EmailAddress::EMAIL_REGEXP from:

as URI::MailTo::EMAIL_REGEXP is defined as such in the Ruby source (
This definition is effectively a Ruby port1 of the JavaScript- and Perl-compatible regex example given in the HTML Living Standard:

Some quick notes on this change:
  • it fixes the cases of the first two email address examples, but $ still matches (and a little search will probably give more edge-cases);
  • the current custom regex includes capture groups while URI::MailTo::EMAIL_REGEXP doesn't (which changes the return value in some cases and thus may break plugins that depend on the current value of EmailAddress::EMAIL_REGEXP) e.g.:
    => #<MatchData "" 1:"test" 2:"">
    => #<MatchData "">
  • given the previous note, this might be something that should be shipped in a major release (6.0.0) instead of a minor release (5.1.0).


#4 Updated by Go MAEDA 5 months ago

Mischa The Evil wrote:

  • given the previous note, this might be something that should be shipped in a major release (6.0.0) instead of a minor release (5.1.0).

I don't think the change should be delivered in 6.0.0 instead of 5.1.0.

In Redmine, the change of version number from 5.0.0 to 5.1.0 is not a minor release but a major release. For example, when the version number changed from 3.0.0 to 3.1.0 or from 4.0.0 to 4.1.0, many new features were added and some plugins stopped working.

If this change cannot be delivered in 5.1.0 due to plugin compatibility, I am afraid that 5.1.0 can only include a few bug fixes and cannot include any new features.

Also available in: Atom PDF