FYI, here's a summary (AIUI) to clarify:
- RFCs 821/822 have been obsoleted by RFCs 2821/2822 which in turn have
been obsoleted by RFCs 5321/5322 - might as well aim for the current
spec, no?
- MailAddress is used for SMTP envelope addresses (MAIL FROM/RCPT TO or
forward-path/reverse-path), defined in RFC xx21, whereas the xx22 RFCs
define addresses as they appear in mail headers, with somewhat different
syntax.
- JavaMail's InternetAddress class is an RFC 822 address implementation.
- The current Mailet API's MailAddress is an attempted RFC 821 address
implementation, with a contract-breaking equals method, a few
non-RFC-821 compliance bugs, and not too efficient code. I uploaded a
patch to test and fix some of the bugs, for the time being, in
https://issues.apache.org/jira/browse/MAILET-28. We are currently
discussing fixing the equals bug too.
- The 2.3.2 codebase contains 2 usages of the broken equals method as
far as I can tell, which appear to be broken regardless of the suggested
change. They can/should be fixed independently, and pave the way for
changing the equals method itself. Dunno about 3.0/trunk/external usages
- if the same usages are carried over or there are additional ones, they
should be fixed as well. A simple "fing usages" in Eclipse or other IDE
can help find these in a couple of minutes (I'm only working with 2.3.2
for now).
- I'm planning on implementing an RFC 5321-compliant address parser,
which I will likely need for one of my projects anyway. If it is agreed
that it's the right move and will be accepted, I can use it to replace
the existing MailAddress implementation.
sorry if I'm too elaborate :-)
Amichai
Stefano Bagnara wrote:
I've not read the whole thread and evaluations, but I just want to
point you to a bookmark of mine:
http://www.boxbe.com/freebox.html
---
EmailAddress.java
The only more-or-less-2822-compliant Java-based email address
extracter/verifier with some header verification as well. Reasonably,
Javamail's InternetAddress class does not have a very robust parser,
and often "fails" silently (technically not a failure, but not
suitable for those that need to extract addresses accurately and
predictably). This class can reliably extract the pertinent
information from any well-formed address, as well as perform several
other useful functions relating to addresses and email headers.
---
I know it is based on regex, so I'm not sure how it performs, but it
is a single well commented class under the apache license.
Stefano
2009/9/16 Robert Burrell Donkin <[email protected]>:
On Tue, Sep 15, 2009 at 8:20 PM, Markus Wiederkehr
<[email protected]> wrote:
On Sat, Aug 8, 2009 at 7:50 PM, Norman Maurer <[email protected]> wrote:
Well, I think we should alter it. I never understood why james support
case sensitive email addresses at all..
AIUI the local-part of a mailbox is case sensitive whereas the domain
is not (see RFC 5321 section 2.4.).
This is how Mime4j's class Mailbox implements hashCode and equals, anyway.
yes (i remember now :-)
IIRC the Mailbox version in Mime4J is the preferred solution so we
should probably use that
In any case hashCode and equals have to be consistent with each other of course.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
