[Done 1.6.0] Not a bug report

[mprough]

When setting up new stores, or making a bunch of changes like shipping, payments etc the volume of emails is setting off the spam alert in mail programs such as gmail. My concern is that these types of monitored platforms, who keep their own spam lists, will lower the trust score of the IP/mailserver and eventually could end up blacklisted.

I would like to propose a aggregated email after X amount of time or dropping the emails for logging instead to avoid this.

~Melanie

[DrByte]

I'm not seeing any get flagged as spam.

If you look at the source of those emails in gmail, has gmail actually stated in the email headers *why* they've flagged them as spam? If they're giving "reasons why", then there might be something more that can be done to minimize the likelihood of triggering it.

I know that there can be a bit of "volume" if I'm making a ton of separate config changes repeatedly while tweaking. But never saw it flagged as spam.
Are you seeing 5 such emails? or 25? or 250?

[mprough]

For example.... setting the sort order for 3 shipping modules sent a barrage of emails 5 in total, 3 to spam and the first 2 to the inbox. I would be happy to send you headers... but not to post plz.

[mprough]

Why is this message in Spam? It's similar to messages that were detected by our spam filters. Learn more

[DrByte]

Sure, please PM me with the headers from those, all 5 please.

[DrByte]

What's the Admin->Configuration->Email Options->Email Transport Method set to?
If it's not set to SMTPAUTH, I'd be interested in seeing how switching to SMTPAUTH affects these symptoms.

[mprough]

PHP mail

[mprough]

We cannot use SMTP auth because the protocol cannot match the security requirements on the server for PCI ..... and for PCI mail passwords must be changed every 90 days as well, which would set off a landslide of brutes when they cannot connect

[DrByte]

Okay.

Well, unauthenticated messages sent from the server as a generic user (ie: "nobody" or "www" or "apache", etc) do quite often trip spam flags; whereas SMTP Authenticated messages don't trigger those issues.

I gather from your last post that you don't have the ability to perform a temporary test of this to rule out this particular factor in relation to the symptoms you're reporting.

[mprough]

Well, unauthenticated messages sent from the server as a generic user (ie: "nobody" or "www" or "apache", etc) do quite often trip spam flags; whereas SMTP Authenticated messages don't trigger those issues.

We are actually setup for the protocol, nobody yes, but unknown no. Apache will not send mail as nobody unless it actually originates from the hosted account.

I gather from your last post that you don't have the ability to perform a temporary test of this to rule out this particular factor in relation to the symptoms you're reporting.

Not really. I could hack the protocol a bit to get SMTP auth to connect and test, but the sheer fact that then client's Zen Cart's could brute block when they passwords need changed makes it's not a viable option.