8000 Swift_MailTransport deprecated · Issue #866 · swiftmailer/swiftmailer · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Nov 17, 2021. It is now read-only.

Swift_MailTransport deprecated #866

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

Swift_MailTransport deprecated #866

babeuloula opened this issue Jan 27, 2017 · 48 comments

Comments

@babeuloula
Copy link

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
Copy link
Contributor

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

@babeuloula
Copy link
Author

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

@barryvdh
Copy link
Contributor

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
Copy link

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

@blakethepatton
Copy link

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
Copy link
Contributor
barryvdh commented Feb 1, 2017

What kind of info?

@blakethepatton
Copy link

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
Copy link
Contributor
barryvdh 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
Copy link

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
Copy link
crazyscience commented Feb 2, 2017 •
edited
Loading

+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
Copy link
Contributor
barryvdh 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

@dominikhajduk dominikhajduk mentioned this issue Feb 22, 2017
Merged
xabbuh added a commit to symfony/symfony-docs that referenced this issue Mar 3, 2017
@xabbuh
minor #7522 [Email] Add caution related to deprecate mail transport (…
2dd28b9 
…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
Copy link

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
Copy link
Author

+1 cyphix333

@crazyscience
Copy link

👍 @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
Copy link
Contributor
Rotzbua 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
Copy link
Author
babeuloula commented Mar 25, 2017 •
edited
Loading

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
Copy link

@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
Copy link
Contributor
Rotzbua 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
Copy link

@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
Copy link
Contributor
sstok 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
@Seldaek
Merge pull request swiftmailer#866 from p-golovin/patch-1
79bf752 
Remove substitution for not defined variables
makasim pushed a commit to formapro-forks/swiftmailer that referenced this issue Jul 26, 2017
@Seldaek
Optimize removal of leftover extra/context placeholders, refs swiftma…
cc8a013 
…iler#866
@unlike777
Copy link

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

@rhukster rhukster mentioned this issue Oct 27, 2017
Closed
This was referenced Nov 23, 2017
Closed
Merged
@msva
Copy link
msva commented Dec 8, 2017 •
edited
Loading

@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
Copy link

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
Copy link

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
Copy link
Member
fabpot 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
Copy link
msva 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
Copy link
Contributor
xabbuh commented Feb 21, 2018

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

@babeuloula
Copy link
Author

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

@cyphix333
Copy link
cyphix333 commented Feb 21, 2018 •
edited
Loading

@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
Copy link
cyphix333 commented Feb 21, 2018 •
edited
Loading

@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
Copy link

@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
Copy link
cyphix333 commented Feb 22, 2018 •
edited
Loading

@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.

@czmole czmole mentioned this issue Jun 2, 2018
Closed
@rfay rfay mentioned this issue Jun 28, 2018
Closed
@brusch brusch mentioned this issue Sep 14, 2018
Closed
@kesselb kesselb mentioned this issue Sep 25, 2018
Closed
@hlohaus hlohaus mentioned this issue Jan 10, 2019
Closed
4 tasks
@kdambekalns kdambekalns mentioned this issue Jan 19, 2019
Merged
@PrplHaz4 PrplHaz4 mentioned this issue Aug 1, 2019
Closed
@patel28
Copy link
patel28 commented Aug 1, 2019

How can I send a mail with a postfix server

@atomiix atomiix mentioned this issue Jul 9, 2020
Merged
@xxorax xxorax mentioned this issue Aug 20, 2020
Closed
@matks matks mentioned this issue Dec 5, 2020
Closed
@sergeychernyshev sergeychernyshev mentioned this issue Mar 7, 2021
Closed
@tbar0970 tbar0970 mentioned this issue Mar 26, 2021
Open
@mvorisek
Copy link

On public hostings, proc_open is disabled.

Is there any way how to make mail() safe, eg. fix the input for it based on PHP version and OS? At least for linux/Windows and the latests 7.4 and 8.x.

@dhensby dhensby mentioned this issue Jul 28, 2021
Closed
@emteknetnz emteknetnz mentioned this issue Aug 2, 2021
Closed
9 tasks
@asmecher asmecher mentioned this issue Aug 11, 2021
Merged
@emteknetnz emteknetnz mentioned this issue Aug 15, 2021
Closed
10 tasks
@asmecher asmecher mentioned this issue Jan 4, 2022
Closed
@matks matks mentioned this issue Jul 18, 2022
Closed
2 tasks
@emteknetnz emteknetnz mentioned this issue Jan 31, 2023
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0