I just finished writing a "sendmail" transport for JavaMail. It simply uses System runtime to exec the sendmail executable. Thus, one can use sendmail on a linux box as a transport without actually running a SMTP port.

I was earlier discussing on the James list, "Would it be possible to programmatically access the James API as a MUA/MTA such that it could facilitate the steps required to send a SMTP message using the same strategy as sendmail (resolving MX records, etc)?" As such, a JavaMail SMTP transport could be written which doesn't require a local SMTP server running.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg01755.html

Which didn't get very far in discussion. But, I still think its a viable concept.

To be argumentative as usual. ;-) Is licensing really a viable reason to
reimplement JavaMail functionality? Sun does provide legal means to redistribute the binary's for JavaMail as part of a package/application in their licensing agreement. And if Apache Licensing can't play well with private code like this, it kind of defeats its purpose as a more legitimate open source licensing strategy for commercial needs than GPL?


2. License to Distribute Software. Subject to the terms and
conditions of this Agreement, including, but not limited to Section 3
(Java (TM) Technology Restrictions) of these Supplemental Terms, Sun
grants you a non-exclusive, non-transferable, limited license to
reproduce and distribute the Software in binary code form only,
provided that (i) you distribute the Software complete and unmodified
and only bundled as part of, and for the sole purpose of  running,
your Java applets or applications ("Programs"), (ii) the Programs add
significant and primary functionality to the Software, (iii) you do
not distribute additional software intended to replace any
component(s) of the Software, (iv) you do not remove or alter any
proprietary legends or notices contained in the Software, (v) you
only distribute the Software subject to a license agreement that
protects Sun's interests consistent with the terms contained in this
Agreement, and (vi) you agree to defend and indemnify Sun and its
licensors from and against any damages, costs, liabilities,
settlement amounts and/or expenses (including attorneys' fees)
incurred in connection with any claim, lawsuit or action by any third
party that arises or results from the use or distribution of any and
all Programs and/or Software.

Alternatively, if there is already solid SMTP/POP protocol handling code present in James, and developers want to make that available for other Apache projects to access programmatically (say, to build a "sendmail like" transporter thats platform independent). Then porting that code into [net] does make some sense.


-Mark

Paul Libbrecht wrote:

At least to my taste, the better license is worth it. (we should be
able to compare Sun licenses to Apache ones and in general Apache
surely wins, trouble is someone has to understand Sun licenses deeply
to be able to provide such a comparison).

Also I think the implementations in Commons-Net are much more straightforward (and thus require less set-up) than java-mail. For
example, I don't think it is possible in JavaMail to invoke a pop-store without a backing set of files... (really a guess).


Paul


On 4-Jan-04, at 05:30 Uhr, Henri Yandell wrote:



As the FAQ/Wiki doesn't mention anything on this yet, why would I want to use Commons Net for SMTP when a perfectly standard implementation exists for SMTP in Sun's JavaMail?

Same question for POP.

Is it just the better licence, or does Commons NET do a better job
in some way?

Hen



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to