SMTP header
I am going around in circles trying to get emails to be received by google account in this scenario:
security spy(Apple Host) -> my SMPT relay(Linux) -> gmail
regular mail from Apple Host works. What I am suspecting is that gmail doesn't like one of more of the headers in the email envelope which Security Spy is writing. My prime suspect looks like this:
Received: from bensoftware.com (darwin.rainbow-futures.com [192.168.1.244]) by brunel.rainbow-futures.com (Postfix) with ESMTP id 4E4801C0739 for ; Wed, 27 Jun 2018 11:14:35 +0100 (BST)
The "bensoftware.com" is just wrong - it should be the local name of host (darwin.rainbow-futures.com). But I don't see anyway to change it.
security spy(Apple Host) -> my SMPT relay(Linux) -> gmail
regular mail from Apple Host works. What I am suspecting is that gmail doesn't like one of more of the headers in the email envelope which Security Spy is writing. My prime suspect looks like this:
Received: from bensoftware.com (darwin.rainbow-futures.com [192.168.1.244]) by brunel.rainbow-futures.com (Postfix) with ESMTP id 4E4801C0739 for ; Wed, 27 Jun 2018 11:14:35 +0100 (BST)
The "bensoftware.com" is just wrong - it should be the local name of host (darwin.rainbow-futures.com). But I don't see anyway to change it.
Comments
The way that SecuritySpy can be aware of a FQDN that points to the sender is if you have set up a DDNS name in SecuritySpy under Web. This features gives you a domain name in the form yourname.viewcam.me. So, if you have set this up, then SecuritySpy will use this DDNS address as the HELO name sent to the SMTP server.
However, if you haven't set this up, SecuritySpy doesn't know of a valid FQDN that points to itself (indeed, normally there isn't one in this case). So, by default, SecuritySpy will use bensoftware.com - this is technically not valid, as it does not point to the IP address of sender of the email, but it works just fine in most cases, as most servers just check for the presence of a FQDN without checking its validity.
So, I suggest that you set up the DDNS feature in SecuritySpy and then try sending an email - hopefully this will resolve the problem. However I have never before seen this particular thing causing problems with any SMTP server, so it's possible that the problem lies elsewhere. Please report back and let us know how you get on with this issue.
gethostbyaddr will give a valid FQDN for the local host, which it gets ....
Received: from bensoftware.com (darwin.rainbow-futures.com [192.168.1.244])
by darwin.rainbow-futures.com (Postfix) with ESMTP id 389359A5F2C9
darwin.rainbow-futures.com is the FQDN. and there is wildcard A record and MX records for rainbow-futures.com out there on the moors.
I believe gmail is suspecting a masquerade is afoot, so is dumping the forwarded email. as all other mail from other sources on the same host gets through OK.
I set up DDNS as suggested, so now the header says .....
Received: from darwin.viewcam.me (darwin.rainbow-futures.com [192.168.1.244])
... which, as I suspected, doesn't get thru either as the content of the fisrt HELO with my email relay smacks of skullduggery, and google, being masters of skullduggery themselves are probably rejecting it. I have changed the first SMPT hop to be the localhost with a postfix daemon and looked at rewriting this in cleanup, but would prefer it if the sender produced a compliant header/HELO.
SecuritySpy does support sending emails via the Gmail SMTP server. And it also has its own built-in relay service, which obviates the need for any SMTP setup. Is there any reason why you don't want to use either of these approaches?
One solution, which other email clients seem to do, is to use the address literal of the LAN IP as the HELO name (e.g. [192.168.1.244]). This is a valid approach according to the relevant RFC. Do you think this would work for your SMTP server?
I'm not sure what the best way forward is for this in SecuritySpy - SMTP almost always works under the current scheme, and I'm wary of making any changes that will potentially break support for other users. I suppose we could add this as an option, but this complicates the SMTP setup and may confuse users.
Turns out that postfix header cleanup is pretty easy. So I'm rewriting the header before pushing to the external relay where it is forwarded to google accounts - all looks good, but google still don't like it, so I've escalated to the google spam team, as there is nothing wrong with the headers now - must be the payload they don't like. Surely your other users send motion detection photos to gmail accounts.