While having an answer i'm writing the most ugly monkey patch ever:

class Mail::Address
  class << self
    def new(value = nil)
      value = value.try(:gsub, ',', ' ')
      super(value)
    end
  end
end

UPDATE Don't do this, it breaks mail gem.

This looks like regular address parsing behavior. Commas , are used to separate addresses. If you want to create address fields that may contain commas (or other special characters), it would be safer to surround the name part with double quotes ".

Mail::Address.new('"Arnold, Roa" <[email protected]>').address
# => "[email protected]"

Mail::Address.new('"Arnold, Roa" <[email protected]>').name
# => "Arnold, Roa"

Very useful... thanks. However unfortunatelly the address is what I receive from Griddler gem comming from mandrill..

Mail::Address is supposed to parse a single address, I think it should not consider commas as a mail separator here.

I got a similar problem with some incoming mails:
We get addresses in header fields that look like this:

Mail::AddressList.new("Doe, John <[email protected]>").addresses.map(&:format)
=> ["Doe", "John <[email protected]>"]

so they are split into multiple addresses, although they are meant to be only one.

Or even worse like this:

Mail::AddressList.new("John Doe, Example INC <[email protected]>")
=> Mail::Field::IncompleteParseError: Mail::AddressList can not parse |John Doe, Example INC <john.doe@example.com>|: Only able to parse up to "John Doe"

that will throw exceptions while parsing.

I know, the name parts should usually be in quotes to prevent this, but unfortunately we cannot control which mail clients everybody uses and how weird some mail clients format addresses.

For the first case I wrote some post-processing code that "stitches" invalid email addresses together again, but in the second case I cannot do much cause of the exception thrown.

Any chances that cases like this can be handled by the parser somehow?

Have the same issue. Did anyone found a workaround?

Since my previous workaround did not help in the second case I described, I now changed the parser and created a pull request: #1365

Are there any plans to merge @Svelix 's solution?