The SMTP module should use or support the Mail System module

Yup, that's a conflict.

I'll have to write a patch to the smtp module that lets us co-exist.

In D7 it won't be an issue, because the co-existence is built-in, but in D6 coexistence of mail-sending modules requires cooperation among the module authors.

Patch. Needs testing, but works for me (TM)

This is against the 7.x-1.x version of SMTP to create a new 6.x-2.x version.

Patch against 7.x-1.x version to use MailSystem in 7.x.

@lanchan -- Don't get too excited. The patch isn't approved, yet, and there are a *lot* of open issues in the SMTP queue.

No, you don't need to install Autoload. Not yet, anyway.

Sorry I haven't been around lately supporting smtp, been extremely busy in real life, not sure were Franz is either. I want to point out though that smtp-7.x already is using MailSystem. I will try to have a look this and make it work with other mail modules sometime during the next week but patches are always welcomed of course;-)

The solution here though need to be crafted in harmony with other mail modules as optionally smtp should simply offer the send service with option other modules like HTML and MimeMail call on, probably as an API. Of course this function "should" really have been in core long ago.

@yettyn -- In order to do accomplish what you are requesting, the Mail System API could be extended as follows:

mailsystem_set(array($key => array('format' => $format_class, 'mail' => $mail_class)))

Use $format_class::format() for formatting $key messages, and $mail_class::mail() for sending them.

In order to implement this change, the Mail System module would dynamically generate a MailSystemInterface implementation class whose format() method invokes $format_class::format() and whose mail() method invokes $mail_class::mail().

I think this is very doable.

Assigning to the Mail System queue. Will re-assign here once the API changes are complete.

I will probably bump the major version number for this.

I was a bit confused there for a minute as when I said that smtp already use mailSystem, I meant the new drupal mailsystem framework, but I see now that you actually have created a whole new module just a month ago or so and... with ambition to take over the role of smtp or?

I wouldn't object as the reason I signed up to be a co-maintainer for smtp in the first place was to push for a working smtp solution in D7 as I needed to bring a few D6 sites with smtp to D7. I'm only in on the D7 version and have no access to the project page as such and none of the other smtp guys have been seen around much... just as myself haven't been on d.o. much lately due to real life obligations.

I'm all in for one working email solution though, the basic is already in core but lack support for smtp, but before I say anything more I need to look at your module and see how it scale. Again, I first thought we where talking about the core mail system ;-)

Btw I see now clearer what problem your module addresses, something I also noted before and pointed out in a issue somewhere as a bug in the implementation of drupal_mail_system but never got any response to, more than I think sun agreed with me. Then real life kicked in....

Either your note or one like it provided my original incentive for writing the Mail System module. If I understand correctly, the preferred strategy for getting new features added to Drupal core is to first develop them as a contrib module, then submit a patch to core once all the bugs are fixed. My hope, therefore, is to develop this contrib module to the point where it would be accepted as an addition to d8 core. Even afterwards, I plan to maintain this module as a d6/d7 backport, to make life easier for developers like myself who maintain parallel d6/d7/d8 module branches.

The API changes have been made in the 8.x-2.0 release. I'll be rolling 7.x and 6.x versions shortly.

The following patches are all against the 7.x-1.x branch of the SMTP Authentication Support module, to create synchronized 6.x, 7.x, and 8.x versions, using the Mail System module for support.

Unassigning myself -- I've done all I can for this. Now it's up to the module maintainers.

Also see #1135262: drupal_mail() should support using different MailSystemInterface classes for format() and mail()

Assigning to myself, for review and commit.

Sorry but I don't see any reason to why SMTP should depend on MailSystem, please explain here what would be the benefits of this dependence.

Marking as "work as designed" for now.

Sorry but I don't see any reason to why SMTP should depend on MailSystem, please explain here what would be the benefits of this dependence.

As I stated in the other issue:

Mail system 6.x-2.x allows using one MailSystemInterface class to format() and another to mail(). For instance, it would allow using MimeMailSystem for formatting, and SmtpMailSystem for sending.

However, the unpatched Mime Mail 6.x and SMTP Authentication Support 6.x modules cannot use this feature.

Also please see the original problem report way up at the top of the page.

In 6.x, both Mail System and SMTP Authentication Support set the smtp_library variable and define drupal_mail_wrapper(). Only one module can do that, so SMTP Authentication Support 6.x is incompatible with Mail System and also with any other 6..x module that sets smtp_library and defines drupal_mail_wrapper().

Since only one module can define drupal_mail_wrapper(), I think it should be a module designed to cooperate with other mail-sending modules, rather than one designed to exclude other mail-sending modules.

I would rather add a dependency; others would rather duplicate the same code in different modules. Apparently we cannot agree on this.

I really do wish Wundo, and other module authors like him, all the best.

It saddens me somewhat that, after breaking up my module into several pieces so that they would be useful on their own, and after taking
several hours of my time to compose patches to show other module authors how we can work together instead of in competition, my efforts appear to have been wasted.

Perhaps if I were more diplomatic and tactful that would not be the case, but I am who I am.

Duplicate issue #1139188: Conflict with SMTP module

Well I think it's premature to close this one, even if I partly agree with wondu, the arguments put forward by pillarsdotnet also carry merit. I think there need to be a distinction between D6 and D7 though. I'm not involved in D6 but my opinion is this is something for D7 really, where I am involved. I don't think it's worth it, to do such a fundamental change to D6.

However, I really don't have any (or much) time right now so revert/reopen this issue but as postponed and will grab it when my work schedule opens up.

Also, nothing personal wondu, but I don't see the point in assigning an issue to oneself in the same moment as closing it, and as your comment doesn't reveal any intent to actually work on the issue, I set it back to Unassigned. I'll assign it to myself when I have time to work on it, unless someone else pick it up before.

@pillarsdotnet, you have done nothing wrong mate, so hang in there and don't get too emotional about it ;-)

P.S.
The Title may need to be redefined but I wont bother with that now

See documentation page: Using HTML Mail together with SMTP Authentication Support

So, with #1199966: The Content-Type header is incorrectly parsed in SmtpMailSystem::mail() function. committed, is there still a need for something here?

Closing very old (dead) issues, if you think this is still relevant please re-open.

I think this is still valid and useful, specially as with the mailsystem module enabled, the smtp enable/disable setting is not useful as mailsystem will still use the SMTP sender if you configure to it.

@hanoii, Thanks for the feedback, feel free to submit patches.

I'm not looking for a hard dependency on any other modules, but I'd love patches that allow us to integrate.

Bumping this back to Major -- so when I found out the smtp_on flag isn't properly shutting off its access, it seems like we shouldn't be circumventing the mailsystem on our own, it doesn't play nicely with other mail modules.

Not sure what was happening 2 years ago, but it looks like the mailsystem module has about as many downloads as the smtp module. It makes sense now with composer to rely on it as a dependency. I think it'll add some resiliency to the issues folks are having with not being able to actually turn this module off.

Doing this in Drupal 8 proved to be much easier. The MailSystem module just provides a wrapper service definition to the core MailSystem. All we have to do is disable SMTP from taking over everything and then you can use the Mail System variable to select SMTP instead.

As soon as #3135595: SmtpConnect() error but email sends successfully is committed I can get this one in.