Emails stopped working...

[lagunamm]

Thanks to GRSmith's posts, I just tried creating a new email id in zoho.com, a free email service. It works. Used smtp.zoho.com as SMTP server, TLS for authentication, and 587 for port. It remains to be seen if this works consistently, but my email test succeeded. Holding my breath for now...

Update: So far so good. Have been receiving Zoho emails from all of my Amcrest cameras since my original post.

[sD7a5]

FYI, Google is blocking.
I setup an Outlook.com profile, and they are doing the same after only a day or two.

[tdyollear]

Outlook.com still works for me this morning so I don't think they are blocking. If there are any updates to the gmail protocol, I doubt that I'll see them since my camera hasn't received an update from Amcrest since 2016 as well.

[ITGuy1024]

So I'm not the only one with this issue... I have been banging my head trying to figure this out.

So the TLDR is that Google is blocking the emails and there is no solution other than to use another email provider?

[ITGuy1024]

I used a zoho account like some other people mentioned. Alerts are coming in now.

Not sure what can be done to get Google working again.

[TahirB]

We've found the solution to the issue with Google. We are working on releasing test firmwares for 841, 941, and 1051 that will address the issue. Once the fix is confirmed we will roll out firmware updates for all effected models.

We will post test firmwares to this forum as they are ready. We really appreciate your guys help troubleshooting and the constant feedback.

[shaywood]

Great news. Can't wait for a solution.

[plusfour]

My guess it's Google having one of their periodic "let's change things at random just because we can" episodes. I've switched to Outlook and everything works again. Another one I tried was GMX, who have a pretty solid, consistent interface - Microsoft aren't exactly a model of stability either, but at least they're slightly less arbitrary and random than Google - but I just get the same send failure as for Google.

To the Amcrest folks, it' would be really useful if the UI displayed what went wrong, rather than just "it failed". The current one-size-misfits-all error message makes it more or less impossible to diagnose what the issue is.

[plusfour]

This is what appears to be going on. Attachment #1 is a packet capture of an attempted connection between the camera and one of the many GMail servers. Notice the line highlighted in dark blue: Alert (Level: Fatal, Description: Inappropriate Fallback).

[...]

I suspect that Amcrest needs to upgrade the client (camera) to support TLS V1.3... and not offer any fallback to lower TLS versions when connecting with GMail servers.

You don't need to support TLS 1.3. The problem is that browsers have for many years performed an elaborate fallback dance to deal with broken servers where they fall back to older and older versions of TLS if the initial connection fails. However, an in-path attacker can take advantage of this to force a fallback to insecure version of TLS, so TLS 1.3 introduced anti-fallback mechanism to deal with this. Since the only imaginable use of TLS is for web browsing (note: sarcasm), Google seem to have enabled this anti-fallback protection for web browsers to everything, because TLS is only used for the web and nothing else, and its broken web browsers that need to be dealt with.

As for the inappropriate fallback error, something that the Amcrest TLS implementation is doing is triggering that. The protection mechanism is a complex kludge that overloads existing fields in the TLS handshake, so it could take a bit of experimentation to figure out what the exact issue is.

[plusfour]

Following up to my own post, from looking at the trace the client proposes TLS 1.2, which is fine, and the server responds with an inappropriate fallback error even though there's no fallback. Specifically, if there was a fallback the client should use an RFC 7507 signalling cipher suite (SCSV), however this is the first message and there hasn't been any fallback.

To the OP, can you post the expanded version of the capture, showing all fields, cipher suites, etc? If there's an SCSV suite present then this may be the cause.