Does the camera system allow for SMTP authentication?

 

If so, can you change to SMTP PORT to 587?  I ask only because COMCAST, and many other backbone providers now prohibit clients, including CCTV systems, from sending on port 587 - they filter all of the NO-MAIL SERVER SMTP traffic out and block it.

 

Here's a link to their announcement about their implementation of port 25 for clients, see: https://portal.chicagonettech.com/kb/a165/xfinity-comcast-blocks-all-traffic-on-port-25-alternate-port-465-and-port-587.aspx

 

 

 

Well they claim to have authentication via user name (email address) and password.

It's our server rejecting it. cctv@example.com is sending to cctv@example.com purportedly using the correct authentication and then getting 'authentication is required for relay' from our server. We allow port 25.

 

Port 25 may be blocked, for SMTP CLIENTS, between their camera system and you.  Even if you're not blocking, one of the networks between you and them may be blocking it.

 

If you are capable of running TLS over port 587, I would also engage that - so that the data is not transmitted in plain text.

With regard to TLS, this is our next big project - but that's for another day. Tx for your help and suggestions. I think I need to see how these are set up at their end otherwise I might just be chasing my own tail.
 

This is not a criticism of your security schedule but it should be given the HIGHEST priority!

 

We got a five-year, enterprise, wildcard, 4096 bit, SHA2 certificate, which we can install on as many servers as we want, so long a the domain matches "chicagonettech.com" for about $270.00 last December. from Comodo.  Took less than 12 hours to apply, download, and install, along with the 3 supporting certificates

 

We're seeing tons of "man-in-the-middle" attacks to capture usernames and passwords on non-secured connections.

 

We're now totally locked down, no more plain text anything, and only had a problem with one customer who balked.  He left over the new security, and we picked up 12 more new clients because of our enforcement.

 

It only takes one compromised account to gain access to the data for millions of user accounts;

Well, you are right to stress the importance. Our problem is lack of understanding of the implication of making the move and so much other stuff takes precedence as usual in small organisations but I'm working on it, trying to understand how best to make the change.

We have a cert which is already associated with the SM log in, which enforces https. It is already associated with the correct port bindings (I just haven't switched to them yet) and validates OK and we have, of course, your very detailed articles of how to go about implementing for our 1000+ email accounts for 100+ customers. I know this thread has now gone off at a tangent but not that much of a tangent. Apologies in advance for the long reply here.

Problem 1.

We know that many customers have local SMTP mail client settings of mail.theirdomain.com rather than mail.ourdomain.com - we need to trawl through these and get them to change so they can use TLS ports (if my understanding is correct) otherwise they will get a certification domain error.

Problem 2

We can't reasonably expect all our customers' mail users (many of whom are not very skilled at making changes to mail configs) to all switch overnight. This is the crux of our lack of understanding and maybe you can enlighten me. But I am not sure what happens if we suddenly switch all the port bindings to TLS ports - if we still allow Auth login - will it work for everyone regardless of their settings until we gradually work our way through persuading and cajoling them to use SSL/TLS and when we are confident everyone has migrated - we disable Auth login?

It would be nice to have a workflow diagram of how to make the switch - not just technically but logistically, taking into account the above considerations. There may be others. You can understand our trepidation in doing anything which stops mail working for customers because this is the most important thing for them, more important than their websites being up 100% of the time.

 

There is a final complication but I think it will be ok. We have a customer who white labels our mail server so his customers login to SM using mail.hisdomain.com and their SMTP server is the same. The certificate includes that domain so I think it will be valid but I'm not sure which settings such as hostnames need to be set up - not sure about multiple hostnames at all. There may be other settings and it may be that this just will not work at all. That domain is NOT set up in IIS (ours is, however), instead, it is just a DNS A record pointing to the mail server IP. We have no custom branding specifically to avoid his customers seeing our company logo etc. They are oblivious of us - in theory - and that's how he wants it to remain.

So there you have it. I understand completely if you feel I am pushing my luck picking your brains here but I think it's a subject which seems to be poorly explained by ST. I'm prepared to to do midnight testing to answer some of the questions above myself but it would certainly help move things along if you can advise on this and we can move up a notch in security.