Hi all,
Since we're throwing ideas out for v.next, I'd like to investigate the possibility of using http://www.swiftmailer.org library for mail sending duties. Their claims of being able to handle large attachments in only 8M of memory sound pretty good :-)
Current PEAR libraries consume an disproportionate amount of memory which impacts large/busy installations.
Any thoughts?
Dali
Dalibor Andzakovic | e: dalibor.andzakovic@swerve.co.nz | p: +64 9 914 3557 | m: +64 21 618 009 I don't wanna grow up...
List info: http://lists.roundcube.net/dev/
Dalibor Andzakovic написа:
Hi all,
Since we're throwing ideas out for v.next, I'd like to investigate the possibility of using http://www.swiftmailer.org library for mail sending duties. Their claims of being able to handle large attachments in only 8M of memory sound pretty good :-)
Current PEAR libraries consume an disproportionate amount of memory which impacts large/busy installations.
Any thoughts?
+1
Have used this one on several sites for basic contact forms, has always worked flawlessly.
Kind regards, Doichin _______________________________________________ List info: http://lists.roundcube.net/dev/
NetOne - Doichin Dokov wrote:
Since we're throwing ideas out for v.next, I'd like to investigate the possibility of using http://www.swiftmailer.org library for mail sending duties. Their claims of being able to handle large attachments in only 8M of memory sound pretty good :-)
I'm becoming devils advocate on this mailing list :)
BUT why should a PHP app take care of sending mails if you have Sendmail on the computer? That's why it is usually installed there - to send mails and as far as I know sending mails using Sendmail works perfectly fine. The Linux approach is that each app does one thing and it does it perfect with a lot of options. To me it seems Roundcube is moving to a direction where it tries to do everything on its own, becoming like... uh.... Word?
IMHO Roundcube should focus on the User Interface, becoming the Thunderbird for the Web, and not try to become a full mail suite like i.e. Zimbra.
Mike
Michael Baierl http://mbaierl.com/
MBA? Married But Available!
List info: http://lists.roundcube.net/dev/
On Thu, Mar 13, 2008 at 08:51:51AM +0100, Michael Baierl wrote:
BUT why should a PHP app take care of sending mails if you have Sendmail on the computer? That's why it is usually installed there - to send mails and as far as I know sending mails using Sendmail works perfectly fine.
Sendmail is hell to configure. Other MTAs can be better, but it's still too much to configure if you just want to get the mail out to some smarthost.
The Linux approach is that each app does one thing and it does it perfect with a lot of options. To me it seems Roundcube is moving to a direction where it tries to do everything on its own, becoming like... uh.... Word?
IMHO Roundcube should focus on the User Interface, becoming the Thunderbird for the Web, and not try to become a full mail suite like i.e. Zimbra.
Mutt has had this stubborn approach for years, but I believe they have mended their ways by including SMTP support. This philosophy worked in the old days, but it's dated. You can no longer count on there being a mainframe in your building!
Andreas wrote:
Sendmail is hell to configure. Other MTAs can be better, but it's still too much to configure if you just want to get the mail out to some smarthost.
When writng "Sendmail" I meant all other MTAs that exist like Exim or Procmail.
Mike
On Thu, Mar 13, 2008 at 11:39 AM, Michael Baierl mail@mbaierl.com wrote:
Andreas wrote:
Sendmail is hell to configure. Other MTAs can be better, but it's still too much to configure if you just want to get the mail out to some smarthost.
When writng "Sendmail" I meant all other MTAs that exist like Exim or Procmail.
Optionally the class should support direct sendmail (and it probably does). Because sometimes people have more than one server. I also find that emails forged through mail()/sendmail never look as legit as smtp-based.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
There's already a working patch in the trac for this. I'm using it on my installation and it works pretty well:
http://trac.roundcube.net/ticket/1484660
Cheers, Corrado _______________________________________________ List info: http://lists.roundcube.net/dev/
Michael Baierl wrote:
NetOne - Doichin Dokov wrote:
Since we're throwing ideas out for v.next, I'd like to investigate the possibility of using http://www.swiftmailer.org library for mail sending duties. Their claims of being able to handle large attachments in only 8M of memory sound pretty good :-)
I'm becoming devils advocate on this mailing list :)
BUT why should a PHP app take care of sending mails if you have Sendmail on the computer? That's why it is usually installed there - to send mails and as far as I know sending mails using Sendmail works perfectly fine.
because the server running roundcube is not nececerally running a full featured sendmail compatible environment with access to the _real_ mailservers?
The Linux approach is that each app does one thing and it does it perfect with a lot of options. To me it seems Roundcube is moving to a direction where it tries to do everything on its own, becoming like... uh.... Word?
yes, but linux tools use basic system libs. the linux distributions we know combine all those tools to a working environment.
same with roundcube. use classes/other applications/plugins which do their well defined job and integrate it to something bigger.
IMHO Roundcube should focus on the User Interface, becoming the Thunderbird for the Web, and not try to become a full mail suite like i.e. Zimbra.
yes - and getting and sending (!) email via an arbitrary mailserver is part of a decent mail application.
moreover, i agree with till on the "mail() sent mail looks forged" argument.
cheers, raoul
On Mar 13, 2008, at 5:39 AM, Michael Baierl wrote:
When writng "Sendmail" I meant all other MTAs that exist like Exim or Procmail.
I think you meant Postfix, not procmail. procmail is a LDA, not a MTA. The whole MTA-LDA-MUA thing is confusing for users, even small mis- steps like this add to that problem.
Personally, I think RC should be a web-based MUA, not the entire e- mail chain.
For those that need a refresher on e-mail, there is http://www.tldp.org/HOWTO/Mail-Administrator-HOWTO-3.html
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
chasd wrote:
On Mar 13, 2008, at 5:39 AM, Michael Baierl wrote:
When writng "Sendmail" I meant all other MTAs that exist like Exim or Procmail.
I think you meant Postfix, not procmail.
Yeah, that's what I meant but did not type, as I'm configured procmail right before writing that mail...
Personally, I think RC should be a web-based MUA, not the entire e- mail chain.
Yep.
Mike
Michael Baierl http://mbaierl.com/
Drag me, drop me, use me like an object. _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, Mar 13, 2008 at 4:35 PM, chasd chasd@silveroaks.com wrote:
On Mar 13, 2008, at 5:39 AM, Michael Baierl wrote:
When writng "Sendmail" I meant all other MTAs that exist like Exim or Procmail.
I think you meant Postfix, not procmail. procmail is a LDA, not a MTA. The whole MTA-LDA-MUA thing is confusing for users, even small mis- steps like this add to that problem.
Personally, I think RC should be a web-based MUA, not the entire e- mail chain.
By no means do we have the resources to provide anything but an MUA. It's already hard as is. Don't expect us to release a mailserver any time soon. ;-)))
For those that need a refresher on e-mail, there is http://www.tldp.org/HOWTO/Mail-Administrator-HOWTO-3.html
Good thing, good bookmark. :-)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
By no means do we have the resources to provide anything but an MUA. It's already hard as is. Don't expect us to release a mailserver any time soon. ;-)))
Just to add my opinion:
I think doing SMTP ourselves is the _only_ way to be sure to:
a. Be confident an e-mail is delivered _somewhere_ b. Show proper (usefull) error message in case of failure
Robin _______________________________________________ List info: http://lists.roundcube.net/dev/
Michael Baierl (Thursday, 2008-03-13):
BUT why should a PHP app take care of sending mails if you have Sendmail on the computer? That's why it is usually installed there - to send mails and as far as I know sending mails using Sendmail works perfectly fine.
And don't forget about extremely light sendmail drop-ins that do just one thing: get the mail to the next mail hub (aka 'smarthost', wherever that word comes from ;) ). Example: ssmtp (ftp://ftp.debian.org/debian/pool/main/s/ssmtp/). Installed and configured on any Linux system within two minutes.
In my humble opinion: don't waste a minute on SMTP handling.
Patrick.
On Thu, Mar 13, 2008 at 5:18 PM, Patrick Nagel mail@patrick-nagel.net wrote:
Michael Baierl (Thursday, 2008-03-13):
BUT why should a PHP app take care of sending mails if you have Sendmail on the computer? That's why it is usually installed there - to send mails and as far as I know sending mails using Sendmail works perfectly fine.
And don't forget about extremely light sendmail drop-ins that do just one thing: get the mail to the next mail hub (aka 'smarthost', wherever that word comes from ;) ). Example: ssmtp (ftp://ftp.debian.org/debian/pool/main/s/ssmtp/). Installed and configured on any Linux system within two minutes.
In my humble opinion: don't waste a minute on SMTP handling.
That's really not an option to discuss right now.
We'll always support mail(), "sendmail" (wrapper, or real deal) and SMTP through one library or another.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till (Friday, 2008-03-14):
In my humble opinion: don't waste a minute on SMTP handling.
That's really not an option to discuss right now.
We'll always support mail(), "sendmail" (wrapper, or real deal) and SMTP through one library or another.
Till
I didn't mean 'drop SMTP support' - I just meant SMTP handling is working already, so why spend any more time on it? In most cases it's not even necessary for a web application to speak SMTP at all, so lets see it as a bonus that it's in RoundCube already.
The argument 'sendmail is hard to configure' is of no importance because nobody needs to use sendmail.
Patrick.
47D85D49.1020907@net1.cc 47D8DD17.1000104@mbaierl.com Message-ID: e2b4b189f5ab92f06b2d0f9cc856c998@ihug.co.nz X-Sender: roundcube-maint@ihug.co.nz Received: from [203.109.131.1] (lo0.akl-newton-corpfw1.ihug.net) (login=martin.kealey@ihug.co.nz) by webmail.ihug.co.nz (running ihug Webmail/0.1b) via TCP with HTTP/1.1 id e2b4b189f5ab92f06b2d0f9cc856c998@ihug.co.nz; Fri, 14 Mar 2008 15:54:41 +1300 User-Agent: ihug Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit
On Thu, 13 Mar 2008 08:51:51 +0100, Michael Baierl mail@mbaierl.com wrote:
BUT why should a PHP app take care of sending mails if you have Sendmail on the computer?
This whole discussion has gone off on a tangent because of this comment.
What causes the memory consumption isn't whether we use SMTP or a command line access to a "sendmail" program.
The problems is that none of the "sendmail" type programs, nor any SMTP server, implements "build a MIME-encapsulated message given a list of attachements".
Quite simply, the MTA's responsibility stops with RFC2821, while RFC2822 is the MUA's job; ie, *our* job.
The problem is that the existing functions need to be fed the entire message as an in-memory string, so if you attach a 20 MB file to your message, you need make a single string of about 27 MB. And due to the way memory is managed by PHP, that can translate into a core image in excess of 200 MB. (Think about passing that string from one function to the next, several times, before it gets to "mail()" or equivalent.)
THIS is our problem: before we switched to RoundCube we used to let our users send 20 MB attachments in webmail, but now we don't have 200 MB for every user, so they're complaining about the "downgrade".
-Martin
List info: http://lists.roundcube.net/dev/
Corrado Fiore wrote:
There's already a working patch in the trac for this. I'm using it on my installation and it works pretty well:
Nice work. Unfortunately we deal with PEAR classes and those changes should go into the official PREAR release.
If Swift Mailer can do the same as the Mail_mime class does (BTW: this is what consumes memory, not the SMTP delivery) we should really consider to use Swift. Also it's LGPL and not PHP licensed.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
2008/3/14, Thomas Bruederli roundcube@gmail.com:
Unfortunately we deal with PEAR classes and those changes should go into the official PREAR release.
If Swift Mailer can do the same as the Mail_mime class does [...] we should really consider to use Swift. Also it's LGPL and not PHP licensed.
If you didn't yet, you may wish to check out also PHP Mailer: http://sourceforge.net/projects/phpmailer
(Please forgive if I repeated something already said elsewhere :-)
Regards, Corrado _______________________________________________ List info: http://lists.roundcube.net/dev/
I wouldn't want to use 5 different blends since we need to adjust our IMAP backend too. Zend Framework or ez Components offer pretty good code as well.
E.g.: http://ezcomponents.org/docs/tutorials/Mail http://framework.zend.com/manual/en/zend.mail.html
They also support reading mbox files (in case your RoundCube and mailstore are "closer") and come already with a driver based architecture, code is follows established coding guidelines and standards and is also documented etc.. Let alone the license (BSD) allows us to do anything and is generally more liberal than (any) GPL. Etc. pp. - things to consider.
I'd welcome using ez components. Less issues to un-glue the mail component from the rest and they also have a pear channel etc. which rids us of all dependency issues.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Zend framework has same memory use issues as Pear mime class. Apart from that it's a pretty nice framework. I'll have a look through ez Components. I like the idea of reading mailstores directly, but we'd need to support both mbox and maildir...
dali
-----Original Message----- From: till [mailto:klimpong@gmail.com] Sent: Sunday, 16 March 2008 09:37 To: Corrado Fiore Cc: dev@lists.roundcube.net Subject: Re: [RCD] Changes to SMTP handling
I wouldn't want to use 5 different blends since we need to adjust our IMAP backend too. Zend Framework or ez Components offer pretty good code as well.
E.g.: http://ezcomponents.org/docs/tutorials/Mail http://framework.zend.com/manual/en/zend.mail.html
They also support reading mbox files (in case your RoundCube and mailstore are "closer") and come already with a driver based architecture, code is follows established coding guidelines and standards and is also documented etc.. Let alone the license (BSD) allows us to do anything and is generally more liberal than (any) GPL. Etc. pp. - things to consider.
I'd welcome using ez components. Less issues to un-glue the mail component from the rest and they also have a pear channel etc. which rids us of all dependency issues.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
On Mon, Mar 17, 2008 at 10:33 PM, Dalibor Andzakovic Dalibor.Andzakovic@swerve.co.nz wrote:
Zend framework has same memory use issues as Pear mime class. Apart from that it's a pretty nice framework. I'll have a look through ez Components. I like the idea of reading mailstores directly, but we'd need to support both mbox and maildir...
No we don't. ;-) At least not right away.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Dalibor Andzakovic wrote:
I like the idea of reading mailstores directly, but we'd need to support both mbox and maildir...
Do you really want Apache to have access to the mail directories of all users? Wooh, this defeats all security settings and concepts of Linux...
Best regards,
Mike
Michael Baierl wrote:
Dalibor Andzakovic wrote:
I like the idea of reading mailstores directly, but we'd need to support both mbox and maildir...
Do you really want Apache to have access to the mail directories of all users? Wooh, this defeats all security settings and concepts of Linux...
another thing i can think of: mbox could be used for caching. but as i never really used mbox (i have allmost always been on maildir) i don't know about the performance impact vs. sql based caching.
cheers, raoul
On Tue, Mar 18, 2008 at 10:26 AM, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
Michael Baierl wrote:
Dalibor Andzakovic wrote:
I like the idea of reading mailstores directly, but we'd need to support both mbox and maildir...
Do you really want Apache to have access to the mail directories of all users? Wooh, this defeats all security settings and concepts of Linux...
another thing i can think of: mbox could be used for caching. but as i never really used mbox (i have allmost always been on maildir) i don't know about the performance impact vs. sql based caching.
IMO ezComponents would be a great start. Allows us to have a variety of backends. People can use them or not. We could also extend it easily for example to offer DBmail support or something similar. _______________________________________________ List info: http://lists.roundcube.net/dev/
-
Andreas -
chasd -
Corrado Fiore -
Dalibor Andzakovic -
Martin Kealey -
Michael Baierl -
NetOne - Doichin Dokov -
Patrick Nagel -
Raoul Bhatia [IPAX] -
Robin Elfrink -
Thomas Bruederli -
till