[
https://issues.apache.org/jira/browse/MAILET-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519722
]
Danny Angus commented on MAILET-9:
----------------------------------
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.
> [API Design] Reconsider MailAddress
> -----------------------------------
>
> Key: MAILET-9
> URL: https://issues.apache.org/jira/browse/MAILET-9
> Project: Mailet API
> Issue Type: Task
> Reporter: Robert Burrell Donkin
>
> 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.
