Hacking Laravel Mail Handling

Second (unexpected) part of the previously mentioned adventure.

My application has been deployed successfully before the summer, than, as always, in the month of August everyone forgot about the emergency. Which emergency back just in September.

I had now to notify ~3000 users about their new credentials on the new platform, but an issue raised:

  • the SMTP server provided by Register.it (always the same, the second most shitty hosting provider in Italy after Aruba) dropped nine connection over ten, despite any kind or time interval I put between different tries. In three days, I reached only a few users
  • technical staff managing the target domain was not able to understand the meaning of "add a TXT record on DNS to publish a DKIM key" (they had even some trouble in just adding a plain A record), so it was not possible to authorize an external SMTP server
  • the only method I had to successfully send mails was calling a PHP mail() from the web space hosting the website of the customer

So, the solution has been to publish on that web space a simple PHP script reading from $_POST the parameters to pass to mail(), and hack the internal MailServiceProvider of Laravel to deliver my messages to it.

Unfortunately, Laravel's Service Providers are not all the same: Cache and Session are designed to be easily extended and customized with new drivers, but not the Mail system. I've got inspiration by this and this classes found on GitHub, and I've been able to hijack the whole mail handling path substituting the original MailServiceProvider with a custom EmergencyMailServiceProvider.

Yet another "shitty hack or die hard" moment.

Show Comments