As the revised post above indicates, we are now tentatively rescheduling this maintenance event for Thu22Sep2016 Midnight-2am MST/PDT (GMT -7) due to unexpected issues we encountered with consistency of data between our legacy transaction log database and the new DB we'd be using on AWS, so we have rolled back to our legacy system until then.



This DB synchronization is the reason for the extended service outage required to finalize this migration; we need to stop all DB changes on our production system, then resync the legacy DB to the new one on AWS for however long that takes, then validate the data matches at both ends before we could open the migrated system on AWS to public access. This time, we found the data did not match, so we need to identify and resolve the reason for that mismatch before we can proceed.



Thanks again to everyone for your patience and understanding, with our apologies for the fruitless disruption in service this time; we promise it will all be worthwhile in the end. :^)

Our Transaction Log server will be unavailable today (Wed21Sep2016) starting from 2pm MST/PDT (GMT -7) in preparation for our rescheduled cut-over to AWS later tonight. This will give us ample time to resync our legacy log DB to the new one on AWS and validate data consistency without needing to take our whole system down, then when we perform the actual cut-over, we'll only need to resync new log entries that have been added since this afternoon, which should minimize the necessary downtime. Thanks for your patience and understanding, with our apologies for the temporary inconvenience.

We have decided to postpone finalizing our migration to AWS for one more day, so this event is now rescheduled for Fri23Sep2016 starting at midnight. Our log server will be back online momentarily, and service was not disrupted at all tonight due to some remaining ambiguities that need to be settled before we can proceed. Thanks again for your patience, with our apologies for any inconvenience this rescheduling may pose for you.

We have now completed the migration of E-junkie services into the Amazon cloud as explained above. While we have done our utmost before and after this morning's cut-over period to prepare, test, and verify that everything should continue to work the same as before, please do not hesitate to contact us if you notice any strange misbehavior of our site, shopping cart, Admin panel, or other services:

https://www.e-junkie.com/ej/contact.htm



PayPal should automatically attempt to resend any IPNs (Instant Payment Notifications) that failed to reach us during the downtime, but if you're seeing payments in PayPal that still aren't showing up in your E-junkie Transaction Log, see step C here for instructions to have PayPal resend any failed IPNs:

1http://www.e-junkie.com/ej/trouble.paypal.order-not-processed.htm1



Thanks again to all of you for your patience, cooperation and understanding while we engaged this major upgrade to E-junkie's infrastructure.

One hiccup we've encountered so far is that AWS will not allow us to send emails with a From: address @ another domain, so from now on we will be sending all thank-you emails as From: "[your Display Name here]" <client@e-junkie.com>, with your actual Display Email in the Reply-to: header instead, so your buyers can still simply reply to their thank-you emails to contact you.



This was eventually going to become inevitable even with our old system anyway, as email providers get more strict about this sort of thing to cut down on spam, phishing, and other such nuisance emails. Operations is looking into resending the handful of early thank-you emails affected by this hiccup right now, but you can also use "Reactivate Expired Links / Resend Email" in your Seller Admin to reissue them yourself.

Most likely I would suspect the issue with email to Comcast is simply a matter of spam filtering and/or delivery delays at their end. We process orders, including sending thank-you emails, immediately when we get confirmation of completed payment, but once the receiving mailserver accepts the message, ultimate delivery to the recipient's actual inbox is beyond our control or insight. Delivery delays of up to an hour or more to major email providers are not uncommon, and this may affect some messages but not others depending on which inbound mailserver each message happens to hit.



That said, I'll refer this to Operations for further investigation. Have you been seeing this issue more or less often since Sept. 23rd, when we finalized migration of our services into the Amazon cloud? Since then, your Transaction Log shows about 3% of your orders have been from buyers @comcast.net; of those Comcast buyers, about 85% were able to complete their download in only 1 or 2 Attempts, and I'm seeing only one Comcast buyer who did not make any Attempts at all on their original link, though you did send them a free replacement link, on which they made 1 Attempt.



I would expect that Amazon SES is already registered for the Comcast Feedback Loop, which should cover that angle as the messages are actually being sent by their servers rather than yours or ours, and they would forward us any feedback regarding mail sent as From: our domain. Note this only pertains to email the recipient deliberately marks as spam, which is unlikely for emails delivering a link they'd paid for, and this feedback is really only used to keep complaint rates down by seeing which kinds of message are most likely to get marked as spam. Speaking of, for this reason and due to automated spam filtering, we recommend keeping your thank-you emails as brief and succinct as possible, avoiding unnecessary link URLs and promotional language that could trigger spam filters or a user's perception of the message as spam.



The Amazon SES Mail Simulator would not be useful to test messages to comcast.net; it only provides specific test addresses @simulator.amazonses.com that messages can be sent to, each of which respond to incoming messages in a predetermined way (e.g., accepts the message, or bounces it as undeliverable, or autoresponds, or marks it as spam, etc.), so the sender can see what happens in each of those scenarios.