See also:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7292#c2

FWIW Horde's "with HTTPS" received header emulates a handover from an SMTP client sending an invalid HELO.   There's probably nothing in the RFCs to stop them doing that, since there isn't actually a HELO, but it's not a very sensible thing to do. An IP address should be in "[]" to distinguish it from a hostname.

The IP address IS in "[]":
1.2.3.4 ([1.2.3.4])

The first IP is really suppose to be without [], it's real clients IP, the HELO/EHLO is in brackets.

How is bug 7292 related to this?

(In reply to azurit from comment #2)
> The IP address IS in "[]":
> 1.2.3.4 ([1.2.3.4])
> 
> The first IP is really suppose to be without [], it's real clients IP, the
> HELO/EHLO is in brackets.

There is no HELO/EHLO for HTTP. The point of the [] is to distinguish the IP address [1.2.3.4] from the hostname  1.2.3.4 on a theoretically possible tld of 4. 
 
> How is bug 7292 related to this?

The strong overlap and similarities with other rules is something that anyone looking into this might want to take account of.

Did you read my comment? There ARE []s, please chcek the format of Received headers. Evereything with that header is ok and fully RFC compatible. Problem is in SpamAssassin rules.

There are [] where SA would expect to find the IP address, but not where it would normally find the HELO. In SMTP this is the one that's mandated by the RFC and  set by the sender, and so the only one that matters.

Since the protocol is HTTPS the HELO is meaningless and SA should not use it. On the other hand creating a received header that superficially looks like an RFC violation that's common in spam, is not a sensible thing to do.

I am 99.9% sure we have custom parsing for other solutions.  Just write one for this case :-)

RW: No, you are simply wrong, HELO/EHLO string si supposed to be in brackets "()", which it is:
1.2.3.4 ([1.2.3.4])

The format is:
clients_IP (HELO/EHLO hostname)
clients_IP ([HELO/EHLO IP address])

This is the same format as Postfix is using for all Received headers. That header is ok and no matter that is was generated by Horde and not by MTA.

(In reply to azurit from comment #7)
> RW: No, you are simply wrong, HELO/EHLO string si supposed to be in brackets
> "()", which it is:
> 1.2.3.4 ([1.2.3.4])
> 
> The format is:
> clients_IP (HELO/EHLO hostname)
> clients_IP ([HELO/EHLO IP address])
> 
> This is the same format as Postfix is using for all Received headers. That
> header is ok and no matter that is was generated by Horde and not by MTA.



This is an actual postfix header:

Received: from a7-11.smtp-out.eu-west-1.amazonses.com (a7-11.smtp-out.eu-west-1.amazonses.com [54.240.7.11])
 (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 by mx4.messagingengine.com (Postfix) with ESMTPS
 for <XXXXXXXXXXXXXXX>; Thu, 26 Jan 2017 16:28:24 -0500 (EST)

(In reply to Kevin A. McGrail from comment #6)
> I am 99.9% sure we have custom parsing for other solutions.  Just write one
> for this case :-)

The trouble is that  "with HTTPS" could catch POP3/IMAP retrievers. Fetchmail has explicit support,  but for getmail, and some of the proprietary retrievers used by service providers, SA relies on the retriever header being unparsable to find the trusted/internal network automatically.

See also https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6420

(In reply to RW from comment #9)
> (In reply to Kevin A. McGrail from comment #6)
> > I am 99.9% sure we have custom parsing for other solutions.  Just write one
> > for this case :-)
> 
> The trouble is that  "with HTTPS" could catch POP3/IMAP retrievers.

I don't know what I was think there, clearly it can't.