A: The JavaMail API is a set of abstract APIs that model a mail system. The API provides a platform independent and protocol independent framework to build Java technology based email client applications. The JavaMail API provides facilities for reading and sending email. Service providers implement particular protocols. Several service providers are included with the JavaMail API package; others are available separately. The JavaMail API is implemented as a Java optional package that can be used on JDK 1.4 and later on any operating system. The JavaMail API is also a required part of the.
A: Sun provides a royalty-free reference implementation in binary form that developers may use and ship. The reference implementation includes the core JavaMail packages and IMAP. POP3 and SMTP service providers. The reference implementation may be downloaded.
A: It depends. Many web-based email services provide access only using a browser with HTTP. These services cannot be accessed using JavaMail. If the service also provides POP3 or IMAP access. JavaMail can probably be used to access it. Contact your web email service provider for details. Also see the for an open source provider for JavaMail that provides access to Hotmail. Another helpful tool is MrPostman a proxy server that provides POP3 access to Hotmail and Yahoo! Mail available at
A: IMAP stands for Internet Message Access Protocol. It is a method of accessing electronic mail messages stored on a (possibly shared) mail server. In other words it permits a "client" email program to access remote message stores as if they were local. IMAP is defined by. For more information see
A: We have no current plans to implement any of these providers. However the architecture of the JavaMail APIs provides for being able to easily plug-in third-party service providers. It is our hope that third-parties will embrace the JavaMail APIs by writing providers for other standard and proprietary protocols. See our page for the latest list of such providers.
A: A "local store provider" can be used to store mail messages on a local disk. The JavaMail APIs do not include such a provider but several are available from third parties for different local store formats such as MH and Mbox. See our page for the latest list of such providers.
A: The Sun protocol providers for IMAP. POP3 and SMTP support many features that are not part of the JavaMail API specification. The documentation for these protocol providers is included in the JavaMail javadocs. The package level documentation for each protocol provider package describes the properties that are supported by the protocol proivder. In addition the protocol providers include some classes and methods that applications can use to take advantage of provider-specific features. Note that use of these properties classes and methods renders a program non-portable; it may only work with Sun's implementation of the JavaMail API. See the and package javadocs for details.
A: Yes. The current release of the JavaMail API implementation is completely free and you can include it in your product. This release includes IMAP. POP3 and SMTP providers as well. Please do read the license and ensure that you understand it. (The license is available after clicking the Download button on the page.) The JavaBeans Activation Framework is also free for use under a similar license.
A: In addition to the JavaMail API spec and javadocs (available both from and included in the download bundle) don't forget to check the and files included with the JavaMail API package for additional important information.
The mailing list is another source of information. See for instructions on how to subscribe and a pointer to the archives.
You can reach the JavaMail team directly at. You can use this address to report bugs. Bugs can also be reported at.
The Sun Developer Network maintains a JavaMail forum see the. As you might expect the JavaMail team strongly prefers that you use email to submit questions to one of the addresses above.
A: Unzip the distribution zip file and edit your CLASSPATH environment variable to include the mail jar file that was included with the JavaMail API distribution. You will also need an implementation of the JavaBeans Activation Framework (see below). See the file (also included in the download package) for additional details and examples.
A: No the JavaMail API package does not include any mail servers. To use the JavaMail API package you'll need to have access to an IMAP or POP3 mail server (for reading mail) and/or an SMTP mail server (for sending mail). These mail servers are usually provided by your Internet Service Provider or are a part of your organization's networking infrastructure. If you don't have access to such a mail server see below.
A: is available for Solaris and Windows platforms. The University of Washington IMAP server supports multiple platforms (UNIX. Windows 32bit etc). Get the source code from. There are several free all Java mail servers available including and is a popular (non-Java) SMTP server is a Java library for implementing SMTP server functionality; their web page also references other mail servers. Many other vendors provide mail servers supporting Internet standards. More information can be obtained from and the.
A: We do not provide a mail server for you to use. You must use your own mail server or one provided by your Internet Service Provider or the company you work for. Your network administrator can give you the information necessary to configure JavaMail to work with your mail server.
A: JavaMail does not currently support accessing mail servers through a web proxy server. One of the major reasons for using a proxy server is to allow HTTP requests from within a corporate network to pass through a corporate firewall. The firewall will typically block most access to the Internet but will allow requests from the proxy server to pass through. In addition a mail server inside the corporate network will perform a similar function for email accepting messages via SMTP and forwarding them to their ultimate destination on the Internet and accepting incoming messages and sending them to the appropriate internal mail server.
If your proxy server supports the SOCKS V4 or V5 protocol (. ) and allows anonymous connections you can tell the Java runtime to direct all TCP socket connections to the SOCKS server. See the for the latest documentation of the
This facility can be used to direct the SMTP. IMAP and POP3 communication from JavaMail to the SOCKS proxy server. Note that setting these properties directs all TCP sockets to the SOCKS proxy which may have negative impact on other aspects of your application.
Without such a SOCKS server if you want to use JavaMail to directly access mail servers outside the firewall the firewall will need to be configured to allow such access. JavaMail does not support access through a HTTP proxy web server.
A: Your server is probably using a test certificate or self-signed certificate instead of a certificate signed by a commercial Certificate Authority. You'll need to install the server's certificate into your trust store. The program will help.
The problem is due to a buggy version of the unzip command used to unzip the JavaMail download package on Linux. The unzip command corrupts the mail jar file. Get a newer version of the unzip command or use the JDK's jar command to unzip the package.
A: When using JavaMail in an environment with a SecurityManager. JavaMail will sometimes fail to read the configuration files in the mail jar file. The JavaBeans Activation Framework may have the same problem reading configuration files from the activation jar file. These default configuration files are stored as "resource" files in the META-INF directory in the jar file.
There are a number of debugging techniques that can be used to determine if this is the problem. Setting the Session property "mail debug" to true (or calling
) will cause JavaMail to print debugging messages as it attempts to load each configuration file. A message of the form "DEBUG: can't load default providers file" indicates that this problem might exist. Similarly setting the System property "javax activation debug" to "true" (e g. by running the program using "java -Djavax activation debug=true...") will cause JAF to print debugging messages as it attempts to load each resource file. Finally the JDK can produce helpful debugging output by setting the system property "java security debug" to "access:failure" (e g. by running the program using "java -Djava security debug=access:failure..."). The command
In addition to the permissions necessary to read the configuration files the application (and JavaMail) will also need permission to connect to the mail servers it uses. If the application uses System properties to configure JavaMail (e g. by passing the Properties object returned from
to the Session constructor as many of the JavaMail demo programs do) it will also need permission to use the System Properties object. Alternatively the application can use its own Properties object and be sure to set the "mail from" property or the "mail user" and "mail host" properties (see the InternetAddress getLocalAddress() method).
To allow an application to use JavaMail under a SecurityManager the application. JavaMail and JAF will need permissions such as the following (be sure to replace the host and path names with appropriate values); add these to the security policy file used by the application:
grant { // following two permissions allow // access to default config files permission java io. FilePermission"/path/to/mail jar". "read"; permission java io. FilePermission"/path/to/activation jar". "read"; // following to use SMTP permission java net. SocketPermission"SMTPHOST:25". "connect,resolve"; // following to use IMAP permission java net. SocketPermission"IMAPHOST:143". "connect,resolve"; // following to use POP3 permission java net. SocketPermission"POP3HOST:110". "connect,resolve"; // following needed if System getProperties() is used permission java util. PropertyPermission"*". "read,write";};
If you don't want to give the application read/write permission to System properties but you still want to be able to use System properties to configure the application you can give the application only "read" permission to System properties and use the following approach:
Properties props = (Properties)System getProperties() clone(); props put("mail smtp host". "whatever"); // set as properties as needed Session session = Session getInstance(props null);
directory of your JDK installation. If you're running in a web server or application server it may be providing its own version of mail jar in one of its directories. You should only have one version of mail jar available to your application.
Q: My servlet can find the JavaMail classes but JavaMail complains that it can't find a service provider for "smtp" or "imap" or address type "rfc822".
A: Usually this is because JavaMail can't access the configuration files in mail jar possibly because of a security permission problem; see for more details. Also make sure that you haven't extracted the mail jar contents; you should include the unmodified mail jar file in the server's CLASSPATH.
source code you can see how these command line arguments are used in the JavaMail API. You should first try using msgshow as shown above and once that's working move on to writing and configuring your own program to use Gmail.
java -Dmail smtps host=smtp gmail com -Dmail smtps auth=truesmtpsend -d -S -M smtp gmail com -U user -P passwd -A user@gmail com
A bug in older versions of the smtpsend command causes it to set the incorrect properties when using the -S (SSL) option so we work around that bug by setting them on the command line. The smtpsend program uses the System properties when creating the JavaMail Session so the properties set on the command line will be available to the JavaMail Session.
The smtpsend program will prompt for a subject and message body text. End the message body with ^D on UNIX or ^Z on Windows.
source code to see how the command line arguments are used in the JavaMail API. There is of course more than one way to use the JavaMail API to accomplish the same goal. This should help you understand the essential configuration parameters necessary to use Gmail.
source code you can see how these command line arguments are used in the JavaMail API. You should first try using msgshow as shown above and once that's working move on to writing and configuring your own program to use Yahoo! Mail.
java -Dmail smtps host=smtp mail yahoo com -Dmail smtps auth=true smtpsend -d -S -M smtp mail yahoo com -U user -P passwd -A user@yahoo com
A bug in older versions of the smtpsend command causes it to set the incorrect properties when using the -S (SSL) option so we work around that bug by setting them on the command line. The smtpsend program uses the System properties when creating the JavaMail Session so the properties set on the command line will be available to the JavaMail Session.
The smtpsend program will prompt for a subject and message body text. End the message body with ^D on UNIX or ^Z on Windows.
source code to see how the command line arguments are used in the JavaMail API. There is of course more than one way to use the JavaMail API to accomplish the same goal. This should help you understand the essential configuration parameters necessary to use Yahoo! Mail.
A: There are many example programs included in the including simple command line programs illustrating various aspects of the JavaMail API a Swing-based GUI application a simple servlet-based application and a complete web application using JSP pages and a tag library.
A: A message with attachments is represented as a MIME multipart message where the first part is the main body of the message and the other parts are the attachments. There are numerous examples showing how to construct such a message in the demo programs included in the JavaMail download package. To attach a file use the
method will give you a hint as to whether the body part should be displayed inline or should be considered an attachment (but note that not all mailers provide this information). So to save the contents of a body part in a file use the
method directly to name the file to be saved; doing so could cause you to overwrite files unintentionally including system files.
Note that there are also more complicated cases to be handled as well. For example some mailers send the main body as both plain text and html. This will typically appear as a
parts for secure messages. It's up to you to decide how many of these cases you want to handle in your application before deciding that a message has an attachment. Most applications take a very simple approach to this and handle only a few of the most commonly seen cases.
A: The following approach will handle the most common cases. Handling inproperly formatted messages message with unknown charsets signed or encryped messages can make this much more complex.
private boolean textIsHtml = false; /** * Return the primary text content of the message. */ private String getText(Part p) throws MessagingException. IOException { if (p isMimeType("text/*")) { String s = (String)p getContent(); textIsHtml = p isMimeType("text/html"); return s; } if (p isMimeType("multipart/alternative")) { // prefer html text over plain text Multipart mp = (Multipart)p getContent(); String text = null; for (int i = 0; i < mp getCount(); i++) { Part bp = mp getBodyPart(i); if (bp isMimeType("text/plain")) { if (text == null) text = getText(bp); continue; } else if (bp isMimeType("text/html")) { String s = getText(bp); if (s != null) return s; } else { return getText(bp); } } return text; } else if (p isMimeType("multipart/*")) { Multipart mp = (Multipart)p getContent(); for (int i = 0; i < mp getCount(); i++) { String s = getText(mp getBodyPart(i)); if (s != null) return s; } } return null; }
File file = new File("filename"); DataSource ds = new FileDataSource(file) {public String getContentType() { return "mytype/mysubtype";} }; MimeBodyPart mbp = new MimeBodyPart(); mbp setDataHandler(new DataHandler(ds)); mbp setFileName(file getName()); mbp setDisposition(Part. ATTACHMENT);
A: The JavaMail API includes builtin support for the most common MIME types but to create a message that includes data in a MIME type that JavaMail does not already understand you'll need to supply that data to JavaMail in a byte stream format. The
A: A mail client supporting disconnected operation will allow the user to access messages in a remote message store (e g.. IMAP) cache (parts of) some of those messages locally and break the connection to the server. While in this disconnected state the mail client can access the messages that have been cached possibly deleting them or saving them to other folders. When the mail client next connects to the remote message store the changes made locally will be synchronized with the remote store. Similarly disconnected support may allow the client to "send" messages when there is no connection to the server with the messages being queued until a connection to the server is available. See also.
A: The JavaMail APIs currently have no support for sending or receiving secure email. The architecture of the JavaMail APIs allows such support to be easily added later by us or by third parties. Information on the current Email security standards (S/MIME and PGP) can be found at. Please browse our page for solutions from other vendors.
method generates message text with lines that are neither the canonical MIME representation of the data (i e. using CRLF to terminate lines) nor using the canonical line separator of my platform (e g.. "\n" on UNIX). How do I get either of these representations if I need them?
The FilterOutputStream will need to accept lines with any of the common line terminators and write out lines with only the desired line terminator. The following are examples of such filters converts to the local platform's line terminator and is useful when writing a message to a file converts to the MIME canonical CRLF line terminator and is useful when the canonical MIME format is needed (e g. to compute a digital signature).
A: The JavaMail APIs were not intended to help you implement a mail server. Nonetheless some of the utility classes such as the MIME message parsing classes might be of use to you. In general you'll find that the JavaMail API errs on the side of "simple" instead of "robust". That's appropriate for a mail client but a mail server would likely make different tradeoffs.
Q: Can I use the JavaMail APIs to add new user accounts to my mail server remove user accounts from my mail server or change the passwords for user accounts on my mail server?
A: The JavaMail API does not include any facilities for adding removing or changing user accounts. There are no standards in this area; every mail server handles this differently.
Q: Why doesn't the MimeMessage class implement Serializable so that I can serialize a message to disk and read it back later?
A: The JavaMail API was designed to layer on top of existing email systems using existing message formats. The ability to use Java serialization was neither essential nor useful for such implementations and thus was not considered a goal of the JavaMail API.
The hard part about serializing a Message is retaining the pointers to the Folder. Store and Session. If you only want to save the content of the message and not the object itself the
method of a message gives you everything you need. If you want to create an entire email system based on serialized messages you should be able to subclass Message et al and implement Serializable in your subclass.
Q: I'm having trouble logging into my Microsoft Exchange server even though I'm sure I'm using the correct username and password what could I be doing wrong?
A: When logging in to Exchange you need to use a username that's more than your simple login name. For example if your email address is "J. User@server com" your Windows NT login name is "juser" your NT domain name is "dom" and your Exchange mailbox name is "Joe User" then you would need to use a username of "dom\juser\J. User" when logging in using JavaMail.
A: You don't need to! JavaMail will automatically determine an appropriate encoding to use for your message parts before sending the message and will automatically decode message parts when reading them. The
methods are useful in cases that JavaMail doesn't handle automatically for you. One such case that occurs frequently is encoding of filenames. The base MIME spec does not allow header parameter values (such as the filename parameter) to be encoded in the same way that (e g.) the Subject header may be encoded. This restricts parameter values and thus filenames to ASCII. However some mailers actually do encode non-ASCII filenames using the MIME text encoding. Applications that wish to interoperate with such non-standard mailers can use the
Q: Even though JavaMail does all the encoding and decoding for me. I need to manually control the encoding for some body parts.
A: In the rare case that you need to control the encoding there are several ways to override JavaMail's default behavior. A simple approach is as follows. After creating the entire message call
is a perfectly valid filename not an incorrectly encoded filename. JavaMail does not encoded and decode filenames by default because doing so would violate the MIME spec.
The base MIME spec does not allow for encoding parameters. RFC 2231 defines a new way to include encoded paramters including filenames in MIME headers. It is not compatible with the de facto way that many applications illegally encode filenames. Even though JavaMail supports RFC 2231 that alone does not allow JavaMail to interoperate with these existing programs. As far as I know very few existing programs support RFC 2231.
If you choose to violate the MIME spec in order to interoperate with other programs that also violate the MIME spec. JavaMail gives you all the tools you need to do so. Starting with JavaMail 1.4 setting the System properties "mail mime encodefilename" and "mail mime decodefilename" to "true" will cause JavaMail to encode and decode the filename parameter.
Applications using earlier versions of JavaMail can use the following workaround to encode a filename:
on the Session object in your code. That will cause debug information to be printed to the console including a protocol trace. If you passed the System properties to the Session when you created it you can simply run your program with
If you think that you found a bug in JavaMail send us this trace along with a test case that reproduces the problem the platform you are using the version of the JDK you are using and the name and version of the mail servers (IMAP. SMTP) that you are using.
A: The first thing to do when debugging such problems is to determine whether it's a Java problem or a networking problem. Use telnet to try to connect to the remote system. For example if you're having trouble connecting to the POP3 server named
If you're trying to connect to an SMTP server use 25 instead of 110 for the port number. If you're trying to connect to an IMAP server use 143 for the port number.
If you get a greeting banner you can simply disconnect. If this works your networking name service firewall etc are all set up correctly and your problem is most likely in your Java program.
If it doesn't work you'll need to check your networking configuration or talk to your network administrator for help. Sometimes a firewall installed on your local machine or on your network will prevent you from connecting to the server. If telnet complains that it doesn't know the host name that you're using most likely your name service (e g.. DNS) isn't properly configured to resolve internet host names. None of these problems are JavaMail or Java problems.
Usually when you get a low level SocketException when connecting the problem is due to your networking configuration. Usually it's not a Java problem.
If you've succeeded in connecting with telnet the next thing to do is to turn on Session debugging and get the protocol trace when JavaMail tries to connect to the remote machine as described. This will often include more detailed error messages from the server that will indicate the real source of the problem.
A: Debugging SSL problems and in particular certificate problems can be difficult. The file SSLNOTES txt included in the JavaMail download package includes some useful information. JavaMail uses the JDK's JSSE API to provide SSL support. You can find information about debugging JSSE problems in the.
A: First verify that you indeed have an email account on the IMAP server. Check with your system administrator about it. Turn debug mode on by invoking the method setDebug(true) on the session object in your code. This will cause the IMAP protocol trace to be dumped on your screen. Send us this trace. The trace will be very useful to us for identifying the problem. If you can please send us vendor information about your IMAP server.
Q: I can read messages from my IMAP server with other mail clients but even though I can connect to the server using JavaMail when I use JavaMail to read some messages it fails. Doesn't that mean there's a bug in JavaMail?
A: No not usually. Most other mail clients make very little use of the rich IMAP protocol. They use the IMAP protocol as little more than a variant of the POP3 protocol typically downloading the entire message to the client and parsing it in the client. This allows them to avoid all sorts of parsing and protocol bugs in many IMAP servers but of course it comes at the cost of being less efficient because they don't take advantage of the IMAP protocol's ability to fetch only the parts of the message that are needed. These server bugs often manifest themselves as the following exception on the client:
The best approach when running into server bugs of this sort is to contact the vendor of the server and get them to fix their product. Contact and we'll help you pinpoint the problem so that you can report it to the server vendor. If you can't get a fix from the server vendor the following technique will often allow you to work around these server bugs:
// Get the message object from the folder in the // usual way for example: MimeMessage msg = (MimeMessage)folder getMessage(n); // Use the MimeMessage copy constructor to make a copy // of the entire message which will fetch the entire // message from the server and parse it on the client: MimeMessage cmsg = new MimeMessage(msg); // The cmsg object is disconnected from the server so // setFlags will have no effect (for example). Use // the original msg object for such operations. Use // the cmsg object to access the content of the message.
A: This is due to bugs in the partial fetch implementation of your IMAP server. To workaround this server bug set the "mail imap partialfetch" property to "false". Refer to from the JavaMail package for more information.
can be used to optimize this). The header and bodystructure information once fetched is always cached within the Message object. However the content of a bodypart is not cached. So each time the content is requested by the client (either using
) a new FETCH request is issued to the server. The reason for this is that the content of a message could be potentially large and if we cache this content for a large number of messages there is the possibility that the system may run out of memory soon since the garbage collector cannot free the referenced objects. Clients should be aware of this and must hold on to the retrieved content themselves if needed.
A: Increase the maximum JVM heapsize at startup. Use the "-mx" option if using the standard JVM from Sun. Don't keep references to the "content" of messages not being used. In certain cases you could try streaming the message content (using
is used. Typically such bodyparts internally hold their textual data in some non Unicode charset. JavaMail (through the corresponding DataContentHandler) attempts to convert that data into a Unicode string. The underlying JDK's charset converters are used to do this. If the JDK does not support a particular charset then the UnsupportedEncodingException is thrown. In this case you can use the
String s; if (part isMimeType("text/plain")) {try { s = part getContent();} catch (UnsupportedEncodingException uex) { InputStream is = part getInputStream(); /* * Read the input stream into a byte array. * Choose a charset in some heuristic manner use * that charset in the java lang. String constructor * to convert the byte array into a String. */ s = convert_to_string(is);} catch (Exception ex) { // Handle other exceptions appropriately} }
There are some commonly used charsets that the JDK does not yet support. You can find support for some of these additional charsets in the JCharset package at.
You can also add an alias for an existing charset already supported by the JDK so that it will be known by an additional name. You can create a charset provider for the "bad" charset name that simply redirects to an existing charset provider; see the following code. Create an appropriate CharsetProvider subclass and include it along with the META-INF/services file and the JDK will find it. Obviously you could get significantly more clever and redirect all unknown charsets to "us-ascii" for instance.
==> TestCharsetProvider java <==import java nio charset.*;import java nio charset spi.*;import java util.*;public class TestCharsetProvider extends CharsetProvider { private static final String badCharset = "cp-1252"; private static final String goodCharset = "cp1252"; public Charset charsetForName(String charset) { if (charset equals(badCharset)) return Charset forName(goodCharset); return null; } public Iterator charsets() { return null; }}==> META-INF/services/java nio charset spi. CharsetProvider <==TestCharsetProvider
method on the Message object. This method will return a new object with the headers set appropriately for a reply. You'll need to supply the content of the message yourself. If you have the content of the original message as a String you can use a simple method such as the following to create the prototypical reply text which inserts "> " in front of each line:
String text = (String)msg getContent(); Message reply = msg reply(); String replyText = text replaceAll("(?m)^". "> "); // allow user to edit replyText. // e g. using a Swing GUI or a web form reply setText(replyText);
A: The approach used to forward a message depends on how you want to present the forwarded message. It's straightforward to create a new MimeMessage address it appropriately and attach an existing message as an attachment to the new message. To attach the original message to the new message use code such as:
MimeBodyPart mbp = new MimeBodyPart(); mbp setContent(forwardedMsg. "message/rfc822"); mp addPart(mbp);
If instead you want to create the new message with the text of the original message included in the new message to forward the message "inline" you can use an approach such as the following:
String text = (String)forwardedMsg getContent(); String forwardedText = String format("\n\n-------- Original Message --------\n" +"Subject: %s\nDate: %s\nFrom: %s\nTo: %s\n",forwardedMsg getSubject(),forwardedMsg getSentDate(),forwardedMsg getFrom()[0],formatAddressList( forwardedMsg getRecipients(Message. RecipientType. TO))); // allow user to edit forwardedText. // e g. using a Swing GUI or a web form msg setText(forwardedText);
A: The simplest approach is to send HTML text with image tags that reference images on a public web site. In this approach the images aren't actually included in the message and so won't be visible if the user is not connected to the Internet when they read the message. Note also that some mailers will refuse to display images that are on remote sites.
You'll have to supply the appropriate username and password needed by your mail server. Note that you can change the protocol to "smtps" to make a secure connection over SSL.
property can be used to set the SMTP FROM: attribute. If this property if absent the message's From attribute is used. If multiple threads need to send mail simultaneously and each needs to set the From attribute each thread should use its own Session object with its own Properties object. The
property can then be set on each Properties object for each Session (and thus each thread) independently. Alternatively each thread can use the
in the SMTP HELO command. If that call fails to return any data no name is sent in the HELO command. Check your JDK and name server configuration to ensure that that call returns the correct data. You may also set the "mail smtp localhost" property to the name you want to use for the HELO command.
Q: If I send a message to a bad address why don't I get a SendFailedException or TransportEvent indicating that the address is bad?
A: There is no end-to-end address verification on the Internet. Often a message will need to be forwarded to several mail servers before reaching one that can determine whether or not it can deliver the message. If a failure occurs in one of these later steps the message will typically be returned to the sender as undeliverable. A successful "send" indicates only that the mail server has accepted the message and will try to deliver it.
Q: When a message can't be delivered a failure message is returned. How can I detect these "bounced" messages?
A: While there is an Internet standard for reporting such errors (the multipart/report MIME type see ) it is not widely implemented yet discusses this problem in depth including numerous examples.
In Internet email the existence of a particular mailbox or user name can only be determined by the ultimate server that would deliver the message. The message may pass through several relay servers (that are not able to detect the error) before reaching the end server. Typically when the end server detects such an error it will return a message indicating the reason for the failure to the sender of the original message. There are many Internet standards covering such Delivery Status Notifications but a large number of servers don't support these new standards instead using ad hoc techniques for returning such failure messages. This makes it very difficult to correlate a "bounced" message with the original message that caused the problem. (Note that this problem is completely independent of JavaMail.) JavaMail now includes support for parsing Delivery Status Notifications; see the file in the JavaMail package for details.
There are a number of techniques and heuristics for dealing with this problem - none of them perfect. One technique is Variable Envelope Return Paths described at.
Q: When I construct an InternetAddress object why don't I get an exception if the address is illegal?
A: The InternetAddress class only checks the syntax of the address. As discussed the InternetAddress class is not able to determine whether the address actually exists as a legal address. It is not even possible to verify the host name if the application is running behind a firewall or isn't currently connected to the Internet.
A: This is not a JavaMail problem. This is an error reply from your SMTP mail server. It indicates that your mail server is not configured to allow you to send mail through it. Typically mail servers for an organization will be configured to allow mail from within the organization to be sent to other addresses within the organization or to addresses external to the organization. It will also typically allow mail coming from an address external to an organization to be sent to addresses within the orgnaization. What it will typically
allow is mail coming from an address external to the organization to be sent (relayed) to another address also external to the organization. The configuration of the mail server determines whether such relaying is allowed and which addresses are considered internal vs external. Often mail servers will require you to before they will relay messages.
Q: When I try to send a message to (for example) Yahoo why do I get an error that says "connection refused"?
A: The host you're trying to connect to is most likely not running a mail server. If you're trying to connect to a web mail service such as Yahoo you can't usually use the web host name (e g.. "yahoo com") since this host doesn't run the required mail server. Instead you'll need to learn the name of the host running the required mail server; contact your web mail provider for this information. You can find this information for Yahoo at. Note that some web mail providers don't offer this service instead allowing you to access your mail only through a browser.
If you're not trying to connect to a web mail account but instead are trying to connect to a host on your local network then most likely the host you're trying to connect to is not running a mail server. Sometimes this will occur if you forget to set (for example) the "mail smtp host" property which will cause you to try to connect to "localhost". Most Windows machines do not run a mail server although many UNIX (Solaris. Linux etc.) machines do. Thus attempts to connect to "localhost" on Windows machines will usually fail with a "connection refused" error.
A: In order to prevent their use to send spam some mail servers will require you to have a valid POP3 account and require you to login to that account before they'll let you send mail through that mail server. This is simple to handle in JavaMail. When you know that you're dealing with such a mail server make sure you connect to your POP3 Store on that mail server before sending mail.
A: The POP3 protocol does not allow the client to see new messages delivered to the INBOX while the INBOX is open. The application must close the INBOX and reopen it in order to see any new messages. You will never be notified of new mail using the
A: You can't. POP3 servers only support a single mailbox per user. Most mail readers that use POP3 also maintain a local message store into which they copy incoming messages (from the POP3 INBOX) and allow you to file messages in other folders. See for more information about local store providers.
command to determine the size of the entire message. It then subtracts the two values to determine the size of the message body. If the server reports the size of the entire message incorrectly you may get a negative number. You can set the property "mail pop3 disabletop" to "true" to disable the use of the
Q: My web application uses JavaMail to attach and send a file that the user specifies but my application can't find the file.
A: If the user species the filename in an HTML form in the browser the filename is normally the name of a file on the user's machine not on the server. The file will need to be uploaded to the server before JavaMail can access it. The can help.
A: One of the biggest issues with using JavaMail in applets is the default applet security restrictions. These restrictions only allow applets to connect to the host from which they were loaded. Thus for such applets to use JavaMail the mail server will need to be located on the same machine as the web server from which the applet is loaded. You can find more information on the applet security model at.
A: In general we recommend use of a servlet (or JSP) to collect a mail message and send it using JavaMail. The demo servlet included in the JavaMail download package illustrates this approach. The on the Sun Developer Network illustrates another approach using JavaServer Pages.
Forex Groups - Tips on Trading
Related article:
http://sunjavatraining.blogspot.com/2007/10/java-mail-faq.html
comments | Add comment | Report as Spam
|