Mautic not sending mail

Anyone run into this error since upgrading to 3.02?

{“exception”:"[object] (Swift_IoException(code: 0): Unable to open file for reading [{tracking_pixel}] at /var/www/(mautic path) /vendor/swiftmailer/swiftmailer/lib/classes/Swift/ByteStream/FileByteStream.php:131)"}

Worked perfectly a while ago on 3.01 …

It won’t send through a campaign event or even through the send mail button in the contact admin section…

What am I missing here? Permissions are all okay.

**EDIT: **
I reverted back to 3.01 and everything works again. The only thing I can think about is that this time I tried upgrading through the dashboard and it seemed to work. I will try upgrading manually this time, in order to see if that has something to do with the issue I experienced in 3.02 …

**EDIT: **

I updated manually to 3.02 and the error is back.

I have that too.

{below has been redacted xxxxxx}

[2020-08-24 00:10:03] mautic.ERROR: [MAIL ERROR] Unable to open file for reading [{tracking_pixel}] Log data: ++ Starting Swift_Transport_EsmtpTransport << 220 smtp-relay.gmail.com ESMTP s6sm1279485ooj.20 - gsmtp >> EHLO xxxxxx.xxxxxxxx.com << 250-smtp-relay.gmail.com at your service, [2600:3c04::f03c:92ff:fe39:c67e] 250-SIZE 157286400 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 >> STARTTLS << 220 2.0.0 Ready to start TLS >> EHLO xxxxxx.xxxxxxxx.com << 250-smtp-relay.gmail.com at your service, [2600:3c04::f03c:92ff:fe39:c67e] 250-SIZE 157286400 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 >> AUTH LOGIN << 334 VXNlcm5hbWU6 >> bWFya2V0aW5nQHRvcm9udG9oZWFkc2hvdC5jb20= << 334 UGFzc3dvcmQ6 >> aGVhZHNob3RzIGFyZSB0aGUgYmVzdCAxIQ== << 235 2.7.0 Accepted ++ Swift_Transport_EsmtpTransport started >> MAIL FROM: >> RCPT TO: >> DATA << 250 2.1.0 OK s6sm1279485ooj.20 - gsmtp << 250 2.1.5 OK s6sm1279485ooj.20 - gsmtp << 354 Go ahead s6sm1279485ooj.20 - gsmtp (send); xxxxx@rogers.com {"exception":"[object] (Swift_IoException(code: 0): Unable to open file for reading [{tracking_pixel}] at /home/mautic/webapps/Mautic/vendor/swiftmailer/swiftmailer/lib/classes/Swift/ByteStream/FileByteStream.php:131)"} []

Question: How do we go about a reversion? I do have backups but they don’t go back far enough before the update to 3.0.2.

SO this ,as it turns out is an even bigger issue for me than I had first understood.

It appears that even form action emails are not getting sent but it also DOES NOT generate an error message in notifications or the logs.

Unlike others that have identified either corrupt attachments or encrypted images. I have none of the aforementioned items. These are straight up basic emails with non-encrypted images hosted on the mautic URL.

I have cleared the cache folder which did not solve the problem. What it did do was clear out emails that were set to be sent out but didn’t because of the error.

New contacts coming into my program are getting stuck at the send email stage and no email is getting sent because of this issue.

I am getting simple emails with no images inserted. I have a Send Email To User action in a campaign that I have been getting emails for. But later in the same campaign is a Send Email action that is always failing.

That email was based off of the Aurora template and has been slightly modified.

All test emails sent from the email builder are sent successfully. This seems to be limited specifically to automated sent emails.

While emails not getting sent is a concern. The bigger concern to me right now is the form actions email not getting sent. I have a contact form on my site and if the action does not send the form details that were submitted, I have no idea that a client tried to reach out to me.

It’s a BIG problem.

Seems your tracking pixel is not generated. All htaccess / permissions ok?

So this is a known issue and a bug fix is in the works.

The workaround is disabling base64 image encoding. It’s in the email configuration page. Just search the page for ‘64’ and it’ll pop up. I haven’t looked into the ramifications of disabling this or what it does do that’s beneficial when enabled but it solves my issue for now.

I’m not aware if this has been addressed in 3.1.0.