Sudden duplicate authorize.net transactions? (Single order, double CC charges)

[DrByte]

This change in v155 causes the email errors to be logged instead of dumped to the screen:
https://github.com/zencart/zencart/c...f65f681370b9a0

Might be useful for keeping tabs on frequency of such issues.

[Patrick Vincent]

I will definitely do that. Thank you.

Also, to append more info, I got word from another of the tech support reps at IMH who dug a bit deeper than the others. He said he found in the logs that a foreign mail server had rejected our SSL encryption level when trying to send a copy of the order to the customer. (Due to PCI compliance we disabled some of the lower encryption levels recently).

He also explained that after the initial ssl transmission failed, the server then creates a new unencrypted connection to send mail (both issues visible in the log snippet he sent).

That makes sense with the behavior in the contact form. The SMTP error was displayed, but an email was still sent. It doesn't explain 100% of the situation, but if the script were failing due the line highlighted below, it at least explains part of it.

Log snippet from their support staff:
(my domains/my IP/my server/customer email address modified as a precaution)

2016-06-14 08:54:19 [20909] 1bCnqv-0005RF-Oe H=myserver.inmotionhosting.com (zencarthostedsite.com) [MY.SER.VER.IP]:53339 I=[MY.SER.VER.IP]:25 Warning: "SpamAssassin as cpaneleximscanner detected OUTGOING smtp message as NOT spam (-1.0)"
2016-06-14 08:54:19 [20909] 1bCnqv-0005RF-Oe <= [email protected] H=myserver.inmotionhosting.com (zencarthostedsite.com) [MY.SER.VER.IP]:53339 I=[MY.SER.VER.IP]:25 P=esmtpa A=dovecot_login:mycpanelusername S=31793 M8S=0 [email protected] T="Order Confirmation No: 6153" from <[email protected]> for [email protected]
2016-06-14 08:54:19 [20919] cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1bCnqv-0005RF-Oe
2016-06-14 08:54:19 [20919] 1bCnqv-0005RF-Oe SMTP connection outbound 1465908859 1bCnqv-0005RF-Oe privatedomain.com [email protected]
2016-06-14 08:54:19 [20922] 1bCnqv-0005RF-Oe H=smtpin.ptd.net [207.44.97.35] TLS error on connection (SSL_connect): error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
2016-06-14 08:54:19 [20922] 1bCnqv-0005RF-Oe TLS session failure: delivering unencrypted to smtpin.ptd.net [207.44.97.35] (not in hosts_require_tls)
2016-06-14 08:54:20 [20919] 1bCnqv-0005RF-Oe => [email protected] F=<[email protected]> P=<[email protected]> R=dkim_lookuphost T=dkim_remote_smtp S=32871 H=smtpin.ptd.net [207.44.97.35]:25 I=[MY.SER.VER.IP]:53182 C="250 2.0.0 Ok: queued as ED5CA6A3B0E" QT=23s DT=1s
2016-06-14 08:54:20 [20919] 1bCnqv-0005RF-Oe Completed QT=23s

[DrByte]

Ya, definitely useful to know about.

You could consider outsourcing your email delivery to be handled by another service, and let them decide how they want to handle ensuring your emails to such destinations are completed successfully.

[Patrick Vincent]

I brought up the idea of using mandrill with the senior management earlier this morning. I really agree, that might be the best route.

[DrByte]

Mailgun might be a more affordable starting point, until you ascertain volume.

[Patrick Vincent]

Understood. I have to offer some pricing plans to the powers that be, so that's good to know. Thank you.