Drupal 7 port of SMTP module

Ok I have had some success :-) Module installs and show up in admin Configuration and I been able to send a test mail to a gmail account.

Not all is ok yet though as I get this warning:
Warning: implode(): Invalid arguments passed in DefaultMailSystem->format() (line 24 of /var/www/site1/htdocs/modules/system/system.mail.inc).

I haven't looked into it yet but probably one of the many changes in D7 I missed.

This is a very important module to get into D7, even as a 7.x-1.x-dev before it's officially released, so I wonder if maintainers still are hanging around here?

/y

Picture gets a bit clearer, the test mail wasn't actually sent by the smtp module but by D7's DefaultMailSystem and the mail was empty due to the error.

I think what really needs to be done here is to trash this mail wrapper stuff and implement it as a custom mail backend based on this new MailSystemInterface in D7

Not really sure how it best would be done as there isn't yet much documentation but I will see if I can come up with something. At least from a theoretic view this ought to allow for an implementation where a defaul account is set up but also offer an API to other modules to set their own sender so mail can origine from different "departments" like support@example.com, info@example.com, news@example.com etc.

Here is a small diff fixing some issues in current smtp 7.x-1.x-dev, including

Warning: implode(): Invalid arguments passed in DefaultMailSystem->format() (line 24 of /var/www/htdocs/modules/system/system.mail.inc).

caused by the test message not being assigned as an array.

I also have attached a zip with the relevant files from the phpmailer library version 5.1, patched an ready just to drop in smtp module directory. I also would like to raise the question why not include the library with the module? It's quite some time since it had an update and question is if it will have more so it's not really a maintenance hog. I'm not 100% sure but I don't think there is any conflict in license to do so? If not, I can host a download of the patched lib to make things simple for drupalistas, and those old v2 patch files could be dropped.

It's not extensively tested but appear to work on my D7 test site, so far at least.

A new updated diff that also include the small fixes from
#938888: Update path entry on hook_menu() implementation
and
#888856: E-mail from name: is not taking name with spaces

the latter being a D6 bug but it also apply to the D7 version.

@sluckz - If I get you right everything seem to be fine, except that no test message actually is send or received, when using SSL?

Indeed, I never tested it with SSL/TSL but will do so now and see what I get.

@sluckz - How do you configure it with gmail? I have gmail but wasn't aware you could actually use their smtp to send emails externally using your gmail address.

I have now tested it successfully on my server sending to gmail with both ssl and tsl, so if there is a problem sending "from" gmail using their smtp it must either be something specific related to that situation or with your server. But if you tell me how you tried with gmail I can try to debug that.

smtp replaces the use of php mail() so an empty file is no surprise although I'm not sure why it should spit out even that as mail() shouldn't be called at all! Have you tested an made sure it works in the first place without the smtp module? Can you provide an url to a page with phpinfo() on your server, it might be a php configuration problem. Send it to me via contact form as you probably don't want it public.

I will do some checking on gmail.

Ok I think I have figured it out, although not a solution. Indeed, the module doesn't make use of the phpmailer smtp library at all but still uses mail(), and the reason it works for me is that I have a backup for that in use by another web application. I didn't notice this until I changed to test with gmail and the mail "mysteriously" still was sent from my server successfully, ha!

Not sure why but I have 1 idea I will test or it possibly is hidden in the depth of D7 changes.

Problem identified, it's

'function smtp_drupal_mail_wrapper' that never gets called because D7 no longer contain this hook and implements a MailSystemInterface instead, so I guess this have to be done differently now. Remind you all, I'm not the maintainer of this module so it would be nice if the maintainer could step forward and put the cards on the table about where he is with this.

This module need to be working when D7 is launched and I fear we are not far off there as RC1 probably will be here within no time. Also as this module in current state is non-functional I set this issue to critical and assign it to myself. I'm not sure if I'm up to the task as my php is a bit rusty and haven't been following D7 all the way but I will at least give it a try. Assistance from more experienced drupal devs are welcomed!

Ok I think I have figured out how this must be done so am at it.

I have done a rewrite of the module, making use of the new drupal_mail_system and have had success both with sending through my own smtp server and gmail smtp. So I think there is hope for getting a working module in time for the D7 release.

I will however not release the code I have here now as it includes a db update and I don't want to screw it up for anyone too eager to test something that probably isn't ready yet. Optimal would of course be if the module maintainer could show some interest so this could be an official fix.

Among other things I think a decision needs to be taken regarding phpmailer. As it's LGPL there is nothing preventing us from taking the parts we need, apply our modifications and re-releasing it as GPL and possibly a part of the smtp module. As the library hardly is going to change significantly, if at all, I think this is a good model to go for?

@franz - Just like to underline that I haven't in any way aimed to take over this project or so, nor complained , I just made a note about it being good if the maintainer joined the discussion ;-) I didn't feel a need to "call on you", yet. With that said and as the question was brought up anyhow, I could imagine to be co-maintainer focusing specially on the D7 version as it will be the one I will use myself rather exclusively. If that seem feasible to you? I already have CVS access as I maintain the Blog Information module, which probably will "die" as there are better alternatives now.

As for phpmailer, I will contribute to that other discussion and in any case I will submit a patch, probably later today, one I have done some more testing and possible adjustments.

Sorry this took some time but I got caught up in some other matters, but here is the promissed patch. It's quite extensive as I have reorganized things a bit and moved the admin stuff out of smtp.module into smtp.admin.inc and also the mail send stuff was moved into smtp.mail.inc creating the new needed class implementing the required interface.

The patch also includes the patched phpmailer 5.1 files and removal of the old phpmailer patch files.

Further more, I have also added a checkbox setting 'Allow to send e-mails formated as Html', which is off by default to not alter the DefaultMailSystem behaviour. This setting is more or less a necessity as druplas new mail system forces together the formating and transport in the same class, which is going to complicate things regarding compatibility with other mail modules. Anyway...

I don't consider this as a final version, as I want to have it, but it's a good start as this code actually works, in contrast to current dev version but certainly more can be done to improve it further. This version has also been tested to work with gmail.com using SSL

Regarding the phpmailer library, in this patch I have kept it as it was before but personally I think it would be a better idea to modify and make it a part of the module, re-releasing it as GPL. That way some unnecessary cruft could be removed and this module could work "out of the box". My justification for this is that the library haven't had an update for about a year and if it will have further updates it's very unlikely they will concern the parts we are interested in. Then for D8 it appears something else is coming anyway #363787: Plugins: Swappable subsystems for core

As the diff is rather comprehensive and may appear confusing to some, I have also attached a zip with a full version of what the diff would produce if applied on current smtp-7.x-1.x-dev of Oct-25. It makes it easier if you want to try this. However, as this isn't an official version I strongly urge anyone testing it to take a backup of your database so you can roll back if needed and I don't know if the current smtp maintainers want it like this.

Ops! One little issue, I had forgot to update the datestamp in the info file to avoid update module saying the version is out of date. New zip attached fixing this but I won't upload a new diff file.

@franz, I forgot to say that the patch is not directly against the CVS Repo, instead I import everything in vendor braches in my subversion repo where I also keep my sites, so the patch is created with the svn diff command, between my modified version and the imported dev version of 25 Oct, well you probably figure out something like that when looking at it but though I should tell anyway.

@franz - thanx, been of the grid for a few days busy with other things, but it all sounds great. I will find some time for it shortly.

Changing this back to critical because currently the dev version actually doesn't work. But I have my cvs stuff back up working again so hope to have this fixed over the weekend. Also setting back to "needs work" as here is no real patch yet ;-)

Ok here comes a pretty extensive patch that integrates wanted and customized parts from the PHPMailer lib, re-licensing to GPLv2 (Original was LGPLv2.1). I decided for a patch to be reviewed instead of committing it directly (as said in #30 by franz) because it differs in the way that I have done full (re-licensed) integration of the phpmailer code rather than keep the library in a sub dir.

Although fully working I do consider this as "work in progress" because;

1.) some cruft has been cleaned out, mostly as a part of removing the Language code and make use the language system already in Drupal, among other things involving t() and updating smtp.pot and .po files, but there are probably more to do.

2.) there are still some code not used, like the DKIM feature, but could be nice to make use of as a further development of this module.

3.) Although I highly respect the work done by the original developers, some code is ugly and old fashion and I don't like that... but that's the beauty of open source, you can find something good and make it better - to the avail of all ;-)

Also finally regarding the re-licensing, although I have read around quite a bit I am not absolutely sure about what should be left in of the old information and what to add, except removal of the reference to LGPL, so any feedback on that is welcomed. I'm absolutely convinced though the right thing to do is to include the mail handler and transport code as a part of the module and to use the favourably licensed PHPMailer library as a base is the right way to go. Also, I cannot see reason to frown at this by the community or consider it not qualified to be stored in the contrib CVS, but it's also a reason I didn't want to commit this directly without a review.

As a side note, and I will open up a specific issue about this, the new drupal mail system has flaw or shortcoming imho, that sort of invites to conflicts between mail modules and this need to be adressed in one way or the other. As for the D7 ready modules I know HTMLMail is in conflict and incompatible with this one. But this is not the issue to go into depth about that. Enjoy.

tag and flag

Hmm they should have been, but I see they aren't, probably me being unaccustomed to CVS... have to go out a few hours but will look at it when back and probably upload a zip/tarball with all complete for reviews.

Hm somehow the added files don't want to make it into my patch, probably have something to do with never been committed. Anyhow, I'm attaching the full module as it stands now in a zip file, using the same date stamp as latest dev version. This is a complete drop in after removing old dev version, including the phpmailer subdir.

If it all looks ok I can commit it later tonight, only thing unsure about really is how much of original release info to leave in the re-licensed phpmailer files. I don't think it's worse than it could be adjusted later as well, keeping in mind current dev version actually is broken the sooner getting this committed the better I think as it also would create a better base for further feedback.

Please review the content of the zip file, it's the complete module as modified. CVS is just short of brains and I don't want to fiddle with the patch stuff including added but not yet committed files... I have it all set so I can commit this and then I will change over and get to know git for further action.

I think this is fine to commit but I wont do so until someone else changes the status to RTBC.

ok will commit this asap, just need to clear my head from some other stuff, and put on some coffee he ;

Yooh! Committed the whole batch so there should be a new functional dev release out by mid day, available in your favourite browser. For any follow ups or issues open new bugs.

Just for the records, 12 D7 installations of SMTP module as of today, lets see where it at Christmas!