shinerweb

On Swift, you have the option of setting which Post types are cached.

Post SMTP stores the emails in the Post table I believe as a post of type “POST SMTP”.

If you are also using the pre-build cache option, but have specified ALL post types, then Swift will create a cached version of all Post types.

Even if you ran the auto-configure option, you can then go in and fine tune Swift’s settings. You can tell Swift to only cache Page and Post types, which will ignore other non user readable post types (i.e. WordPress user created menus are also stored within the Post table so Swift will create a cached page for those as well). Depending on any other plugins you might have (WooCommerce for example), you may have other page types which are real pages and would need caching).

I’m pretty sure if you exclude the POST_SMPT post type from the pre-cache options, you’ll stop any issues for the types of link you are seeing.

If SendGrid is showing them as being sent, then they must be leaving Post SMTP correctly.

That suggests the problem is with the receiving mail account blocking/refusing or junking the received emails.

Have you double checked your DKIM/SPF, Rev DNS, Domain Host and From: fields are all correct?

Can you post the results of the diagnostic test?

I’d double check your settings for the account you are using to send mail.
Are there any further error messages in the transcript that point to which account?

Sheesh, 10 Log entries and it was over 1.5GB worth of log data !!!
Do you think there were more than 10 entries in the tables?
Or do you think one or more entries was that large, it was taking up that much space?

Switching logging on and changing the number of log entries to a lower number should normally result in the logs being trimmed.

However, I’m wondering if someone had previously set the log size to something extraordinarily large at which point, displaying the log would actually fail.
If the log size was then set to a much lower number, I’m wondering if the ‘delete’ function is failing given that it’s trying to delete over 1.5Gb of entries. (i.e. either the SQL or PHP statement is timing out, depending on the server settings).

Given the plugin already attempts to clean up the saved mail logs, it wouldn’t be a trivial task to delete that much data in one go.
You’d have to set up multiple batches, using a recurring WP cron-job to delete them gradually over time, cancelling the cron job on completion.

I suspect if you had logging enabled, you’d see either PHP timeouts, or SQL Server gone away errors whilst you had that 1.5GB+ of log data. Each time POST SMTP would have tried to clear it out, it should have died.

You managed to clear it via PhpMyAdmin which has less restrictions.. usually…

Do you remember if the emails were logged over a long period, or did the site send out a mass of emails in a very short space of time? (i.e. from a hack attempt/spamming attack etc).

I’m going to try and set up a local server to try and replicate what happened on your site and see what was happening… 1.5+GB of logs !!! That’s huge !!

@yehudah I can confirm this behaviour.

When the phpMailer is being used, the content type is being set to Content-Type: text/html; charset=UTF-8

The Password is in the source of the email, but the formatting of it prevents it being displayed by the HTML viewer (at least in Gmail viewer, haven’t check any other mail clients).

When you set Post SMTP to use SMTP, the content type is Content-Type: text/plain; charset=UTF-8 so the field is now displayed correctly.

@tegid – Hopefully @yehudah will look into this for you. It’s a busy time of the year at the moment where he lives, but he will eventually get back to you.

I would remove the Reply-To setting on Post-SMTP and make sure that you set the From: and in the Additional: sections on the mail tab in Contact Form 7 (CF7).

It’s most likely that you haven’t set the Reply To: within CF7 or your Post SMTP setting is overriding what you do have in CF7.

But double check that your form is actually setting the values.

The Reply To: field in Post SMTP is there for the occasions where your form or site logic can’t fill out that value itself. So in your instance, you just need to set the Reply To: within CF7 itself

Whilst you have found a plugin to handle notifications separately, it’s not necessarily the job of POST SMTP to determine where and what emails are sent.

The main job of POST SMTP is to provide a different mail transport other than the in-built PHP Mailer function. i.e. it’s there to just send emails.
POST SMTP does not care who created the email, it just sends whatever it is told to send.

For example:

WordPress Core decides who gets notifications about the core (updates, comments etc).

A contact form should have the necessary options to allow you to route notifications to the form submitter and to a site administrator.

A shopping cart should have the necessary options to allow to route sales notifications to the purchaser and to various other admins.

POST SMTP does not need to know about what settings the Core uses, nor does it need to know anything about Contact forms, shopping carts etc. It simply takes what ever would have been sent to the php_mailer function and re-routes it to whatever mail method you have decided to use.

So in your set-up with WooCommerce, it is the WooCommerce that should format the sales based emails and determine when and what emails are sent. You can set up different ‘funnels’ based on certain actions within WooCommerce. POST SMTP doesn’t have a clue about what WooCommerce is doing other than it receives a mail to send and sends it to addresses that were supplied by WooCommerce.
If sales emails are going to website-admin@yoursite.com instead of going to sales-team@yoursite.com, that is down to WooCommerce not being set up correctly, rather than POST SMTP (or any other SMTP type plugin)
You don’t need a separate plugin to add the behaviour you want, you need to correctly configure WooCommerce.

POST SMTP does have the ability to override certain fields and prevent plugins from changing them, but in most site set-ups, it will be the job of WP Core and any plugins or filters defined by the site that determines what and where emails are sent.

In a perfect website, you should think along these lines. You install POST SMTP, set it up to send emails and then forget it was ever there. That’s how it should work.

The advantage of POST SMTP however is that it has extra features such as a fall-back method in case your primary sending method fails. The ability to not only your own SMTP servers, but dedicated mail providers (mailgun, gSuite GMAIL etc). It also provides the ability to log all outgoing emails to allow you to debug problems and even re-send a failed message (or one that the user somehow deleted or their own mail provider didn’t deliver).

Delete the log field that is causing that error. I’m sure @yehudah made reference to it in the changelog or a blog post but I don’t have that to hand at the moment.

Found it: https://postmansmtp.com/post-smtp-2-0-6-bug-fixes/

Basically, delete the lines upon which the error occurs.
The latest version (2.0.6) does not create log entries that causes the Implode error.

However, if you are seeing brand new log entries that are still causing the Implode error, report to @yehudah immediately from the contact page on this website (https://postmansmtp.com/contact).

Please bear in mind that it is Holiday season for @yehudah in his country at the moment and he might be slower in responding. Whilst he may not be able to respond as quick, that doesn’t mean he won’t be looking into the problems. He’s a single developer working on this plugin.

Regards

Chris