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 ( []) by (Postfix) with ESMTP id 4E4801C0739 for ; Wed, 27 Jun 2018 11:14:35 +0100 (BST)⁩

    The "" is just wrong - it should be the local name of host ( But I don't see anyway to change it.
  • What you are referring to is the "HELO" name, which is supposed to identify the sender. This must be a FQDN (Fully Qualified Domain Name).

    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 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 - 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.
  • Thanks for the quick response.

    gethostbyaddr will give a valid FQDN for the local host, which it gets ....

    Received: from ( [])
    by (Postfix) with ESMTP id 389359A5F2C9 is the FQDN. and there is wildcard A record and MX records for 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 ( [])

    ... 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.
  • OK I can see what you mean. The approach with the DDNS name is valid if the connection to the SMTP server is over the Internet (which is the case for 99% of users), but in your case the SMTP server is on the local network, so the IP of the sender (which is the LAN IP) won't match the IP obtained by DNS lookup of the DDNS name (which is the WAN IP address).

    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. []). 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.
  • Hold that thought for a while. I'll do some more work this end.....

    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.
  • Let me know what you find out - yes there are many users who send motion notification emails to gmail accounts, and we are not aware of any particular problem with them being caught by spam filters.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!