Today, colleagues came across a problem, when using Java mail to collect mail, if the recipient is a list, and the recipient list is separated by semicolons, then the Java mail will be abnormal, not normal parsing, take a look at it, wrote a simple demo, very simple, for example:
Copy Code code as follows:
@Test
public void Testreceivemail () {
try {
String host = "pop3.163.com";
Properties POPs = new properties ();
Pops.put ("Mail.pop3.host", host);
Pops.put ("Mail.pop.auth", "true");
Session session = Session.getdefaultinstance (POPs, NULL);
Store store = Session.getstore ("POP3");
Connecting to a mail server
Store.connect (Host, "Chb_go", "3870359346");
Collect inbox
Folder inbox = Store.getdefaultfolder (). GetFolder ("Inbox");
Just read enough.
Inbox.open (folder.read_only);
Get all Mailing lists
message[] msg = Inbox.getmessages ();
Fetchprofile profile = new Fetchprofile ();
Profile.add (FetchProfile.Item.ENVELOPE);
Inbox.fetch (msg, profile);
for (int i = 0; i < msg.length; i++) {
System.out.println ("===============================================");
System.out.println ("Subject:" +msg[i].getsubject ());
Internetaddress[] toaddress = (internetaddress[]) msg[i].getrecipients (Message.RecipientType.TO);
for (internetaddress adress:toaddress) {
System.out.println (Adress.getaddress ());
}
}
Close an open resource
if (Inbox!= null)
Inbox.close (TRUE);
if (store!= null)
Store.close ();
catch (Nosuchproviderexception e) {
E.printstacktrace ();
catch (Messagingexception e) {
E.printstacktrace ();
catch (Exception e) {
E.printstacktrace ();
}
}
Very simple, you can normally receive mail, the normal display of the recipient list, but when connecting to an internal mail server, and the recipient is a semicolon-delimited message, the recipient does not appear correctly.
Looked up the specification, found that FRC 822: The recipient is required to be separated by commas, it seems that semicolon segmentation is not a standard separator, as follows:
Copy Code code as follows:
Destination = "to" ":" 1#address; Primary
/"Resent-to" ":" 1#address
/"CC" ":" 1#address; Secondary
/"RESENT-CC" ":" 1#address
/"Bcc" ":" #address; Blind Carbon
/"RESENT-BCC" ":" #address
The # syntax represents a list, and the contents of the list are separated by commas, for example:
Copy Code code as follows:
2.7. #RULE: LISTS
A construct "#" is defined, similar to "*", as follows:
<l>#<m>element
Indicating at least <l> in most <m> elements, each separated by one or more commas (","). This makes the usual form of lists very easy; A rule such as ' (Element * (", ' element ') ' can be shown as" 1#element ". Wherever this construct are used, null elements are allowed, but do not contribute to the count of elements. This is, "(element),, (Element)" is permitted, but counts as only two elements. Therefore, where at least one ele-ment are required, at least one non-null element must to be present. Default values are 0 and infinity so ' # (element) allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
JAVA Mail operates in strict accordance with the RFC 822 specification and does not handle semicolons. Most mail servers are strictly RFC 822 compliant, such as Lotus Notes, Gmail (Gmail recipients can not enter a semicolon, or even automatically replaced by a comma, praise); However, you will also find that usually send mail, often separated by semicolons, This is because some of Microsoft's messaging tools, such as Outlook, Outlook Express, or MAPI, are delimited by semicolons, and because Outlook uses a wide range of users, even many people think that semicolon-delimited is the norm, and strongly despise microsoft! There are too many things out of spec!!
If it's bad enough, you really hit the habit of using a semicolon as a separator, and its mail server will not automatically replace semicolons with commas, then we can only be compatible with the program, you can consider revising the Java Mail source code, modify
InternetAddress class of Parse method, where the source code does not show, we simply will be for the processing of semicolons to modify the Sing Woo comma as well (but the semicolon in the FRC 822 also have a definition, so that changes may cause hidden dangers, everyone prudent).
