EDIT: 3rd beta of OpenEMM 2012 available at SourceForge

Use this forum to report bugs and to check for bugfixes and new releases of OpenEMM

Moderator: moderator

maschoff
Site Admin
Posts: 2401
Joined: Thu Aug 03, 2006 10:20 am
Location: Munich, Germany
Contact:

EDIT: 3rd beta of OpenEMM 2012 available at SourceForge

Post by maschoff » Thu Sep 27, 2012 7:55 pm

The 3rd (and last) beta version of OpenEMM 2012 is now available at SourceForge:

https://sourceforge.net/projects/openem ... velopment/

Please check out this new release and use this thread to report any bugs or glitches so that we can fix them asap.

Please note that we do not offer online updates for beta versions. Starting the online update process would install version 2011 of OpenEMM, because this is the latest GA version (General Availability).
OpenEMM Maintainer

Shuro
Posts: 20
Joined: Mon Oct 26, 2009 1:26 pm
Location: Germany, Pr. Oldendorf

Re: First beta version of OpenEMM 2012 available at SourceFo

Post by Shuro » Fri Sep 28, 2012 8:30 am

Where can i find the Changelog?
Or most important question: finally without sendmail and with postfix support?

maschoff
Site Admin
Posts: 2401
Joined: Thu Aug 03, 2006 10:20 am
Location: Munich, Germany
Contact:

Re: First beta version of OpenEMM 2012 available at SourceFo

Post by maschoff » Fri Sep 28, 2012 8:42 am

The changelog is in directory USR-SHARE.

Since Sendmail works fine we did not see a need to switch to Postfix. What are your arguments to abandon Sendmail and use Postfix instead?
OpenEMM Maintainer

Shuro
Posts: 20
Joined: Mon Oct 26, 2009 1:26 pm
Location: Germany, Pr. Oldendorf

Re: First beta version of OpenEMM 2012 available at SourceFo

Post by Shuro » Fri Sep 28, 2012 9:22 am

Thanks for the info.

Some disadvantages of sendmail:
- very complexity configuration
- had many significant vulnerabilities over the years
- bloatware, sendmail has a much larger code base than other MTAs such as qmail and Postfix, and a larger RAM footprint too
- Last Upate: 17. May 2011
- postfix and qmail are much more popular (you've seen it at Mailserver-Konferenz, or?

Which is the problem with other MTAs? Didn't see the problem here.

maschoff
Site Admin
Posts: 2401
Joined: Thu Aug 03, 2006 10:20 am
Location: Munich, Germany
Contact:

Re: First beta version of OpenEMM 2012 available at SourceFo

Post by maschoff » Fri Sep 28, 2012 9:28 am

If you do not see a problem maybe you can help us porting the Sendmail depending backend code to Postfix? ;-)

In our opinion, Sendmail is difficult to replace in OpenEMM by other MTAs because

1. spool files can easily be generated directly (the process is documented) - therefore, OpenEMM can assign spool file names so that OpenEMM has sufficient ID information encoded to use the names for bounce management during mail transmission

2. bounce management is based on a well documented plugin interface of Sendmail (milter) and permits combining the realibility of Sendmail with the flexibility of OpenEMM functions (I know Postfix support milter, but we have not really tried it, yet).
OpenEMM Maintainer

Shuro
Posts: 20
Joined: Mon Oct 26, 2009 1:26 pm
Location: Germany, Pr. Oldendorf

Re: First beta version of OpenEMM 2012 available at SourceFo

Post by Shuro » Fri Sep 28, 2012 10:57 am

maschoff wrote:If you do not see a problem maybe you can help us porting the Sendmail depending backend code to Postfix? ;-)
I can try it, but my java knowledge is quite...bad.
maschoff wrote:1. spool files can easily be generated directly (the process is documented) - therefore, OpenEMM can assign spool file names so that OpenEMM has sufficient ID information encoded to use the names for bounce management during mail transmission
Where is it documented? Seems my google is broken or something like that, cannot find the documentation. I think manipulating the spool directly is not the best idea, but I know thats an easy way for you. For mass mails you should use the smtp protocol to submit the mailings.
maschoff wrote:2. bounce management is based on a well documented plugin interface of Sendmail (milter) and permits combining the realibility of Sendmail with the flexibility of OpenEMM functions (I know Postfix support milter, but we have not really tried it, yet).
If you send mailings via smtp, this is no problem, even the statistics on the admin-backend about already sent mails would be right. ;)
Of course the user see how fast their newsletter goes really out. But Grouping by domains should make it quite fast, possible multiple sender processes, per domain, beginning with most common domains like gmail or web.de.

edit: additional, smtp is cross-MTA-compatible, even sendmail is still possible ^^

Anton
Posts: 46
Joined: Sun Jun 24, 2012 9:58 pm

Re: First beta version of OpenEMM 2012 available at SourceFo

Post by Anton » Tue Oct 02, 2012 6:23 pm

Shuro wrote: I think manipulating the spool directly is not the best idea, but I know thats an easy way for you. For mass mails you should use the smtp protocol to submit the mailings.
Umm. The best idea is the one that works best. The SMTP protocol is a horrible POS that was created 30 years ago and is good for very little. If you want real SMTP performance+stability (for millions of emails per hour on a single machine, for example) you are not going to be using off-the-shelf FOSS SMTPs, you are either going to heavily modify one (I started on James but it was going to be too much work), or you are going to go with proprietary software (Port25, MessageLabs, etc.). We replaced 8 (yes, EIGHT) postfix servers with 1 (yes, ONE) PowerMTA virtual machine on one of our setups and got much better speed.
Particularly if you are going to keep your disks with sane caching mechanisms (ie, you flush with reasonable frequency), then using simple SMTP and having one email per SMTP transaction (which is obligatory for proper bulk email broadcasts using straight SMTP), will mean you send pathetic numbers of emails or you spend insane amounts on disk sub-systems.
Writing spool files is an elegant and highly performant solution compared with straight SMTP.
While it complicates bounce management somewhat (they all become async or you need to write custom code), you can also run via the basic, included python SMTP and run it as a "smart relay" (check the docs). This way you can relay to any other type of SMTP you want - postfix, qmail, PowerMTA, IIS/Exchange or whatever you want...
I personally don't think any time should be wasted on converting to Postfix (or other) when the current system works well and there are quite easy alternatives if you really want performance or to use a particular flavour of SMTP.
A

ps. THANKS FOR THE BETA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Post Reply