You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mailet-api@james.apache.org by "Stefano Bagnara (JIRA)" <ma...@james.apache.org> on 2011/01/20 13:34:45 UTC

[jira] Commented: (MAILET-9) [API Design] Reconsider MailAddress

    [ https://issues.apache.org/jira/browse/MAILET-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984155#action_12984155 ] 

Stefano Bagnara commented on MAILET-9:
--------------------------------------

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

> [API Design] Reconsider MailAddress
> -----------------------------------
>
>                 Key: MAILET-9
>                 URL: https://issues.apache.org/jira/browse/MAILET-9
>             Project: Mailet
>          Issue Type: Task
>    Affects Versions: 2.4
>            Reporter: Robert Burrell Donkin
>             Fix For: 3.0
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.