Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swift_MailTransport deprecated #866

Closed
babeuloula opened this issue Jan 27, 2017 · 46 comments

Comments

Projects
None yet
@babeuloula
Copy link

commented Jan 27, 2017

Hello,

The constructor Swift_MailTransport is deprected

$transport = \Swift_MailTransport::newInstance();

But on your documentation (http://swiftmailer.org/docs/sending.html) you use this constructor.

What is the good way ?

Thanks

@barryvdh

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2017

The entire mail transport is deprecated. Use sendmail or smtp.

@babeuloula

This comment has been minimized.

Copy link
Author

commented Jan 27, 2017

And how I can send any mail if on my server sendmail is not installed ?

@barryvdh

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2017

If I understand correctly, mail() in PHP is just a thin wrapper for sendmail in Linux, so you probably have it installed. On windows, it's usually a wrapper for SMTP.

@crazyscience

This comment has been minimized.

Copy link

commented Feb 1, 2017

The Mail transport is not deprecated. It just plain doesn't function at this point.

@blakethepatton

This comment has been minimized.

Copy link

commented Feb 1, 2017

I just spent several hours with my Laravel install trying to get it to send emails and got no debug messages. I only got some debug info that led me here when I was using artisan tinker. Does anyone know the last version of swiftmailer that actually worked with php's mail() function?

@barryvdh

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2017

What kind of info?

@blakethepatton

This comment has been minimized.

Copy link

commented Feb 1, 2017

My build info:

  • Laravel 5.2
  • Swiftmailer v5.4.5

With the mail driver set to mail I ran:

\Mail::send('path.to.view', [], function($message){
  $message->from("blakethepatton@example.org"); //using my own domain here
  $message->to("blakethepatton@example.com", "blakethepatton"); 
  $message->subject("Test Email"); 
});

And saw:

PHP error:  The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead. in /home/vagrant/project-files/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/MailTransport.php on line 45
sh: 1: /usr/sbin/sendmail: not found
=> 0 

Which led me here. I'd just like to reiterate that even with php errors enabled (set in .env) I saw no exceptions thrown when running my controllers and attempting to send emails.


To anyone else stumbling on this at a later point in time having the same issue as me, I found that Swiftmailer v5.4.1 seems to work perfectly. I'm not sure if any newer versions work, that's just the version that I know works based off of another Laravel install that I have that can actually send emails.

@barryvdh

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2017

Are you running emails via queue? That would explain not getting the warnings.
That version is unsafe if you allow input on the from address.
Can't you disable deprecated messages? Or use sendmail or smtp, even better?

@blakethepatton

This comment has been minimized.

Copy link

commented Feb 1, 2017

I'm not queueing emails and I am hard coding the from address in my code.

As for the deprecated message, it only shows up in tinker. From what I recall Sendmail was also unsuccessful, and SMTP is not allowed in the project .

Additionally, isn't the mail driver just supposed to use php's mail() function? I don't understand why this would be failing when I can send messages from the mail function when I am able to run mail(with parameters) just fine.

@crazyscience

This comment has been minimized.

Copy link

commented Feb 2, 2017

+1 what @blakethepatton is describing is more or less the same situation that we came across as well, which means that many Laravel installations are only one composer update away from silently failing to send transactional emails. I'm more curious why CI didn't pick up this issue and fail the build before it managed to get pushed to production.

@barryvdh

This comment has been minimized.

Copy link
Contributor

commented Feb 3, 2017

So is it because of the deprecated message? Perhaps submit a PR to just have it deprecated in the docs and remove the trigger_error

xabbuh added a commit to symfony/symfony-docs that referenced this issue Mar 3, 2017

minor #7522 [Email] Add caution related to deprecate mail transport (…
…dominikhajduk)

This PR was merged into the 2.7 branch.

Discussion
----------

[Email] Add caution related to deprecate mail transport

For current stable Symfony standard edition `swiftmailer/swiftmailer` version v5.4.6 is used. Since this one `mail` transport is deprecated. I think it's worth to mentioning this deprecation.

swiftmailer/swiftmailer#866

>User Deprecated: The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will  be removed in 6.0. Use the Sendmail or SMTP transport instead.

Commits
-------

7138f84 Add caution related to deprecate mail transport
@cyphix333

This comment has been minimized.

Copy link

commented Mar 24, 2017

I'm very disappointed with this move, I know the mail() isn't the best option out there and you should use smtp ideally, but when you're creating commercial software that uses swiftmailer then you don't really make the choice what to use; mail() is a far easier thing to use out of the box than sendmail or smtp, both of which aren't as portable as the mail() function is.

I never use sendmail myself, usually mail() or smtp; but from what I know users are required to enter a path for sendmail (if the auto-detection doesn't work!?) and obviously smtp requires the input of several details.

Whilst mail() is inferior to the other two, it is far more user-friendly than them and works right out of the box.

@babeuloula

This comment has been minimized.

Copy link
Author

commented Mar 24, 2017

+1 cyphix333

@crazyscience

This comment has been minimized.

Copy link

commented Mar 24, 2017

👍 @cyphix333

Not to mention that PHP's mail() function has the infrastructure-specific SMTP or mail settings already configured by the system administrator in the machines php.ini. PHP hasn't deprecated mail(), why would SwiftMailer?

@Rotzbua

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2017

@crazyscience The documentation of mail() has many cautions and notes which tells you, that you shouldnt use mail() in a productive environment. If you use swiftmail you want to do it the good way to send mails and in this case mail() is a bad decision.
https://secure.php.net/manual/en/function.mail.php

@babeuloula

This comment has been minimized.

Copy link
Author

commented Mar 25, 2017

Ok but some hosting does not allow to use sendmail. And for SMTP we need username and password. For some application, we did not have authentication

@cyphix333

This comment has been minimized.

Copy link

commented Mar 25, 2017

@Rotzbua I and I think others are not saying you should use mail(); I specifically noted that it is inferior to sendmail and smtp in my post; however it works straight out of the box as stated and is portable.

No, you shouldn't use mail() if it can be avoided, but to remove it altogether is wrong.

If you have your own site and are using SwiftMailer, most of the time it probably won't be an issue as you can set it up to use sendmail or smtp (assuming your host allows it); however if you're using it within software then your best bet would be to default the mailing system to use mail() and then recommend to the user they change to using one of the better options, if they can.

@Rotzbua

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2017

I think the implementation of Swift_MailTransport which use mail do not work really well. I already reported a bug #876 and maybe there are more. They do not want to support it anymore.
It is a design and architectural decision which they made and the arguments against mail are ok.

To be serous:

  • I suggest removal in next major release, 6.x was first mentioned in 2014...
  • Just stay on a old release where mail was included -> fixed
  • Copy old Swift_MailTransport class, put it in a repo, add composer file, add repo to your composer -> fixed
@blakethepatton

This comment has been minimized.

Copy link

commented Mar 25, 2017

@Rotzbua those solutions are all well and good for the few people are aware that mail() is getting removed from swiftmailer, but what about the other thousands of developers who are completely unaware of this?

Also I'm curious what issues they're facing that makes php's mail() something to abandon. I have yet to experience issues with it being able to send messages. Sure you don't get as many customizations but while it's limited, it still works great for the people who still have to use it.

I'd suggest that there be limited support for mail and have it be noted in the documentation rather than completely remove it. Removal will make it so that, as crazyscience said, "many Laravel installations are only one composer update away from silently failing to send transactional emails"

@sstok

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2017

Please see the original pull requests:
#850
#846

The MailTransporter was deprecated because of security reasons! Using an older version of the library because it doesn't give this deprecation is both dangerous and ignorant! Plus it breaks one of foundations of secure software development: http://fabien.potencier.org/don-t-use-php-libraries-with-known-security-issues.html

The problem with the mail() function is rather complex: the php mail() function on Windows uses a build-in Sendmail binary that uses the configured smtp server (without authentication) perfectly doable.

However on a posix (Linux/Unix/macOS) system it uses the local sendmail binary, and this is were things get complicated:

When you pass additional arguments for sendmail (the from) PHP will escape the arguments (incorrectly). To fix this Swiftmailer escapes the arguments prior to passing them to the mail() function, however PHP repeats this escaping. And presto, we have double escaping bug.

Add to this the fact that an e-mail address can formatted as a command, and your exploit is complete. Only using SMTP or Sendmail (directly) ensures there is no magic going on that breaks any of the protections.

Keeping this transporter will only cause more problems in the future, it's already heavily limited for all features (compared to SMTP and sendmail) while both already available, mail() only abstract's this (that's all!).

Sendmail or smtp is already available when you use the mail() function, so saying it's not possible plain wrong. It's possible however your was so kind to block popen/proc_open making it impossible to use this... ask them to enable this, because disabling this only stops the simplest of exploits and can be easily bypassed.

About the "missing" deprecation message, this is intentional. You need to use a custom error handler (like the Symfony Debug component) to show these messages, as triggering them always would break your application.

"many Laravel installations are only one composer update away from silently failing to send transactional emails"

This transporter is deprecated but will not be removed until the next major version. If your Composer constraints allow to install a new major version, this indicates a bigger problem. Secondly, I do hope you run a test after an update right? There is always a change a regression.

makasim pushed a commit to formapro-forks/swiftmailer that referenced this issue Jul 26, 2017

Merge pull request swiftmailer#866 from p-golovin/patch-1
Remove substitution for not defined variables

makasim pushed a commit to formapro-forks/swiftmailer that referenced this issue Jul 26, 2017

@unlike777

This comment has been minimized.

Copy link

commented Oct 26, 2017

Please return mail transport driver! Leave the choice for developers!

@msva

This comment has been minimized.

Copy link

commented Dec 8, 2017

@sstok

ask them to enable this, because disabling this only stops the simplest of exploits and can be easily bypassed.
can be easily bypassed

Can you be a bit more specific about that, please?

For example, I've php_admin_value[disable_functions] = dl,exec,passthru,shell_exec,system,proc_open,popen,parse_ini_file,show_source,gzinflate in php-fpm's pool config. How can it be bypassed?

P.S. and, yes, having that settings makes swiftmailer unusable without mail() transport and a will to configure SMTP auth on localhost.

@dicrtarasov

This comment has been minimized.

Copy link

commented Feb 19, 2018

Many, many and many hosting companies disabling proc_* function for secrutity reason and allow just one way to sedmail mail is usng PHP mail function. So, SwiftMaler is not more usable in many sites hosting provider. Good job! :)))

@cyphix333

This comment has been minimized.

Copy link

commented Feb 20, 2018

Yep, they kind of seemed to have tunnel vision with this without looking at the overall implications.

@Rotzbua

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2018

I have two paid webspaces, both are low cost <1€ and have no restrictions (php 7.0 and 7.2). Both use plesk.
Restricting proc_* functions is more a mature setting and not required on good configured webspaces with proper user and right management.
But maybe I missed something.. Can anybody give a real example where restricting proc_* functions is required?

@dicrtarasov

This comment has been minimized.

Copy link

commented Feb 20, 2018

There are some exploits for Debian 8, 9, which give root priviliges. So, China hackers use any function call to run it. So, all process execution function disabled.

@cyphix333

This comment has been minimized.

Copy link

commented Feb 20, 2018

Not to mention they haven't considered people that use Swift within downloadable software; such as, sure, if you're using it yourself and you have control over your system then yes, your best bet is to use SMTP. However if you have utilized Swift in a piece of large-scale software that is going to be used by many people, then:

  1. Many aren't technical enough to even stumble into the settings to set up SMTP or make a decision based around this (so defaulting it to the mail protocol seems like the easiest plan of action here) and;
  2. Many users as have pointed out may have no choice, their hosting providers may not allow the usage of SMTP or proc_* functions; and yes, I know there are ones that don't allow proc_* functions.

...so again, a very short-sighted decision made here.

@Rotzbua

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2018

There a lot of shitty or one-man-show webhosting services in the web. Not allowing any alternative way to send mails is a show stopper, especially the documentation itself do not recoment to use mail() for more than a simple text mail. (https://secure.php.net/manual/en/function.mail.php) So you have to search a good hoster..

Don't forgett that swiftmailer is part of the symfony which means this guys make professional software and this environments do not use mail(), so they do not want to invest time to maintain code which is basically used by people who will never pay any cent to them.

I'm wondering that still nobody created a addon for mail()-transport yet...

@babeuloula

This comment has been minimized.

Copy link
Author

commented Feb 20, 2018

Ok but sometimes, it's my client who buy the webhosting and I can't tell to him : Oh your hosting was a shitty hosting. You need a better hosting, but in fact it's just for send email ...

@dicrtarasov

This comment has been minimized.

Copy link

commented Feb 20, 2018

So, lets go to implement our own mail transport, away from SwiftMailer to close this thread. Not a big deal to stop spending time for not so smat software :)

@babeuloula

This comment has been minimized.

Copy link
Author

commented Feb 20, 2018

Why I go to implement my own mail transport then SwiftMailer have been propose a better mail transport ?!

@dicrtarasov

This comment has been minimized.

Copy link

commented Feb 20, 2018

babeuloula, this thread is about that SwiftMailer is NOT proposed required mail transport. Also, better is so abstract meaning.... If you can't implement something, then you can get already implemented by others :)

@babeuloula

This comment has been minimized.

Copy link
Author

commented Feb 20, 2018

My initial question is : Why mail is deprecated in SwiftMailer ?
Some other users need a mail transport. Why SwiftMailer have removed that ?

@dicrtarasov

This comment has been minimized.

Copy link

commented Feb 20, 2018

Replies for this question is above.

@babeuloula

This comment has been minimized.

Copy link
Author

commented Feb 20, 2018

That is not an answer. The mail function in php is still used. Why remove it on SwiftMailer?

@cyphix333

This comment has been minimized.

Copy link

commented Feb 20, 2018

So you have to search a good hoster..

Again, if you're creating software that others will use (or as someone else has pointed out they have clients) then you don't have control over what host they use.

@xabbuh

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2018

@sstok's comment in #866 (comment) pretty much sums up the security implications that led to the deprecation of the transport. I suggest to close here as this decision will probably not be revisited.

If you really need such a transport, you are still free to implement it on your own (you could even just take the existing code, the license allows that). Then it is your responsibility to deal with security issues, but not that of the maintainers of a widely used library who decided not to bear this after considering the consequences.

@fabpot fabpot closed this Feb 21, 2018

@cyphix333

This comment has been minimized.

Copy link

commented Feb 21, 2018

Poor move closing this - if you're going to close it then at least reply to the issues people have brought up in this thread to support the decision you have made, not just close it because "that's the way we're going and tough luck if you don't like it".

@fabpot

This comment has been minimized.

Copy link
Member

commented Feb 21, 2018

@cyphix333 Please, read the thread. I don't see what we can add to what @sstok already said. The MailTransporter was deprecated because of security reasons. We don't want to keep something that will always have security issues.

@msva

This comment has been minimized.

Copy link

commented Feb 21, 2018

Well, I, as sysadmin in the company where developers using this package, disagree that mail() is more insecure than calling to exec-functions of any kind (and, especially, executing of a hardcoded commands, when it is no way to fix assumptions of this package developers)...

And it's a bit overkill to setup a full smtp server with all the proper setup (incl. dns) for each dev/staging container/VM.

@xabbuh

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2018

You are still able to implement the transport yourself (which basically is just copy and pasting some code).

@babeuloula

This comment has been minimized.

Copy link
Author

commented Feb 21, 2018

Ok so, what is the last version number to continue to use SwiftMailer with composer ?

@cyphix333

This comment has been minimized.

Copy link

commented Feb 21, 2018

@fabpot

Please, read the thread. I don't see what we can add to what @sstok already said. The MailTransporter was deprecated because of security reasons. We don't want to keep something that will always have security issues.

I'm quite aware why you deprecated it, but my previous post was addressing the concerns people had.

Namely the ones about that many hosts have disabled proc_* functions and hence many users would not be able to use it on their hosting (such as clients / when you're not choosing the hosting yourself).

...and the issues I bought up about using it in large-scale software, where again, you have no control over what host the user will use and is even worse than a client as you can't really advise them what host to use because a package you use chooses not to use the mail() protocol.

On top of that, another point I made was that many of these same users don't have the technical know how to setup their SMTP settings; you are turning this into something that can be utilised by developers on the front end as well as the back.

@cyphix333

This comment has been minimized.

Copy link

commented Feb 21, 2018

@babeuloula It seems that 5.4.4 was the last version before the mail transport got deprecated and it got removed in 6.0.0.

https://github.com/swiftmailer/swiftmailer/blob/master/CHANGES

@blakethepatton

This comment has been minimized.

Copy link

commented Feb 22, 2018

@cyphix333 5.4.1 for sure didn't give the depricated notice. When I joined this issue I was having issues with 5.4.5 not running the mail() function at all. 5.4.1 is what I've set in my composer.json file specifically because of this issue.

@cyphix333

This comment has been minimized.

Copy link

commented Feb 22, 2018

@blakethepatton @babeuloula My bad; I just checked the changelog again...... 5.4.* doesn't have the mail transport removed, (it gets removed in 6.0.0), but it got deprecated in 5.4.5.

https://github.com/swiftmailer/swiftmailer/blob/master/CHANGES

I think I remember now why I setup my composer.json like that; since it's for my own site I didn't need the mail transport but didn't want to go to 6.0.0 because I don't run PHP 7.

I will update my post above now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.