Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.4
    • Fix Version/s: 3.0
    • Component/s: None
    • Labels:
      None

      Description

      MailAddress represents an internet mail address. It is a concrete class including good, standards compliant code for parsing addresses. The strength of this design is that it enforces standards. This is also the weakness of the design. Occasionally, a looser algorithm capable of dealing with non-RFC822 mail would be preferable.

      Consider factoring as a logical interface (implemented as either an empty abstract class - my preference - or an Interface) capable of alternative implementations. The current class would become StandardMailAddress. Consider adding a marker flag for those addresses which are not RFC822 compliant.

        Activity

        Hide
        Danny Angus added a comment -

        By extending InternetAddress and overriding the validate() method we could achieve optional compliance, however there would need to be a corresponding change in products which use MailAddress because they would now need to make decisions based on the compliance level.
        We could allow certain well documented non compliant patterns to be accepted with a validate(OPTIONS) method. But I think that would be non-trivial to understand the decisions admins would need to make because in theory compliance is the baseline, and deciding what non-compliant behaviour is acceptable or unacceptable is a bit iffy.

        Show
        Danny Angus added a comment - By extending InternetAddress and overriding the validate() method we could achieve optional compliance, however there would need to be a corresponding change in products which use MailAddress because they would now need to make decisions based on the compliance level. We could allow certain well documented non compliant patterns to be accepted with a validate(OPTIONS) method. But I think that would be non-trivial to understand the decisions admins would need to make because in theory compliance is the baseline, and deciding what non-compliant behaviour is acceptable or unacceptable is a bit iffy.
        Hide
        Robert Burrell Donkin added a comment -

        Leave till 3.0

        Show
        Robert Burrell Donkin added a comment - Leave till 3.0
        Hide
        Stefano Bagnara added a comment -

        Considering this... do we have a list of addresses that are not valid for mailets but are used by some mail server as valid email addresses?

        I have a poor memory but I remember an italian provider assigning email with a local part ending with ".", e.g: local.@libero.it (I repeat I'm not sure this was the real case, but it was something similar).

        I think we should not allow "any" string to be an address so we have to define how we need to relax the address validation.

        Some rfc valid email addresses (not sure how we currently deal with them)
        http://tools.ietf.org/html/rfc3696#section-3
        --------------
        "Abc@def"@example.com
        "Fred Bloggs"@example.com
        "Joe
        Blow"@example.com
        "Abc@def"@example.com
        customer/department=shipping@example.com
        $A12345@example.com
        !def!xyz%abc@example.com
        _somename@example.com
        -----------

        Also, if we change the address stuff maybe we should take the opportunity to support new internationalization standards too:
        http://tools.ietf.org/html/rfc4952
        http://tools.ietf.org/html/rfc5335

        Show
        Stefano Bagnara added a comment - Considering this... do we have a list of addresses that are not valid for mailets but are used by some mail server as valid email addresses? I have a poor memory but I remember an italian provider assigning email with a local part ending with ".", e.g: local.@libero.it (I repeat I'm not sure this was the real case, but it was something similar). I think we should not allow "any" string to be an address so we have to define how we need to relax the address validation. Some rfc valid email addresses (not sure how we currently deal with them) http://tools.ietf.org/html/rfc3696#section-3 -------------- "Abc@def"@example.com "Fred Bloggs"@example.com "Joe Blow"@example.com "Abc@def"@example.com customer/department=shipping@example.com $A12345@example.com !def!xyz%abc@example.com _somename@example.com ----------- Also, if we change the address stuff maybe we should take the opportunity to support new internationalization standards too: http://tools.ietf.org/html/rfc4952 http://tools.ietf.org/html/rfc5335
        Hide
        Peter Poier added a comment -

        One problem that I encountered with the MailAddress class. If I have some InternetAddress object internetAddress and give it a Personal Name:

        InternetAddress.setPersonal("personalName")

        If I now create a MailAddress object of it:

        MailAddress mailAddress = new MailAddress(internetAddress);

        and then convert the mailAddress back to an InternetAddress object:

        InternetAddress internetAddress2= mailAddress.toInternetAddress();

        The Personal name is lost, i.e.:

        internetAddress2.getPersonal() is empty.

        Show
        Peter Poier added a comment - One problem that I encountered with the MailAddress class. If I have some InternetAddress object internetAddress and give it a Personal Name: InternetAddress.setPersonal("personalName") If I now create a MailAddress object of it: MailAddress mailAddress = new MailAddress(internetAddress); and then convert the mailAddress back to an InternetAddress object: InternetAddress internetAddress2= mailAddress.toInternetAddress(); The Personal name is lost, i.e.: internetAddress2.getPersonal() is empty.

          People

          • Assignee:
            Unassigned
            Reporter:
            Robert Burrell Donkin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development