On Thu, Nov 08, 2007 at 07:41:02AM +0100, Christian Voelker wrote: > Am 06.11.2007 um 20:17 schrieb Douglas Ramiro: > > Hello Everybody. I'm in trouble with emails. I configured my dspace > > with a smtp server that dont use SSL. It works fine. But at my > > institute, the email server use SSL and dspace dont send email. > > What can I do? > I cant see how this makes any trouble. As I understand it, > smtp servers dont communicate over TLS between each other > but provide this method only for sending from the MUA to > protect your credentials in case you have to authenticate > to the server.
Two MTAs certainly *can* use either SSMTP or STARTTLS to communicate via an encrypted channel. Whether there is any pair of MTAs configured so that they *do* is another question. Any SMTP that I set up, MTA or MUA, will offer or attempt STARTTLS, but I know it isn't universal practice. If the MTA that Mr. Ramiro must use is configured to demand SSL then he must supply SSL. To do this, one must either configure JavaMail to offer SSL, or do what I do: install an MTA under one's own control on Tomcat's host and set it up to offer SSL when forwarding to the institutional email hub. There doesn't seem to be a way to tell JavaMail to request SSL using dspace.cfg parameters. It would be necessary to set mail.smtp.starttls.enable = true in the Properties passed to Session.getInstance() or Session.getDefaultInstance(), but we'd need support from DSpace to do that. So it appears that this method is not usable with DSpace 1.4.1, which is the latest I have running. It would be good for someone to file a feature-request for this, or even a patch. Then one would need to set up a certificate store for the account used to run the servlet container, so that JavaMail can validate the MTA's certificate. On the other hand, setting up an MTA without creating problems such as an open SMTP relay requires great care and much reading. If you don't already know how to set up an MTA then I would suggest getting help with the specific MTA you choose. Further problems you may encounter: o It is possible that the institutional MTA requires a "client certificate" to prove that it is talking with a known partner. I've never seen this done, but it could be done. If so, you will need to work with that MTA's administrators to provide what it is expecting. o One reason to require SSL is that the MTA also requires AUTH PLAIN or AUTH LOGIN authentication. These methods send the credentials in plaintext, meaning that valuable passwords are exposed on the network. Encryption by SSL protects the passwords. So you may find that you have a functioning SSL connection but now you need to supply credentials. Again you may need to negotiate this with the MTA's admin.s. Some MTAs will refuse plaintext AUTH mechanisms over an unencrypted connection but will accept other AUTH mechanisms without encryption. JavaMail can do AUTH DIGEST-MD5, so if that is acceptable to the institutional MTA without encryption, and you don't have any other requirement for encryption, then this may be sufficient. Finally, you might be able to negotiate the use of unencrypted SMTP from your specific host as an exception to the general rule. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpbLzcdPnCD5.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
