Prefer to post the full headers off list, but as pointed out, that
header was inserted probably by the last relay (Spam Experts) as
indicating where it received it from, but injected at the bottom of the
headers as it was supposed to, as it is not a real 'trace' header.
This results in a duplicate external relay, which can and is confusing.
This is part of a larger audit on External Relay recording by SA, and
determining edge cases of email that can 'confuse' the recording of this
information.
Bill, feel free to reach out to me offlist for more information.
-- Michael --
On 2024-04-03 07:16, Bill Cole wrote:
On 2024-04-02 at 19:02:35 UTC-0400 (Tue, 2 Apr 2024 16:02:35 -0700)
Michael Peddemors <[email protected]>
is rumored to have said:
Noticed that the External Relays includes what looks to be an
erroneous entry..
Notice the last entry.. looking at the email headers, the only
conclusion that I can make is that somehow X-Originating-IP gets
treated as an external relay, and I don't think that should be..
I have a vague deep memory of this issue being discussed in depth in the
past on the Users list. I believe the use of X-Originating-IP to
identify an external relay is correct, although it is of minimal
utility. I.e. it could easily be an attempt to mask the real origin.
OTOH, because that header is not part of any sort of standard, it is
never clear what exactly it means unless you have specific knowledge of
how the writer of that header defines it.
Of course many headers can be forged, but notice in this case that
header was injected by the second external relay.. there were no
relays before the relay involved in accepting the email.
What role did 169.239.218.51 play in the transport? It is not clear to
me from your description or included SA relay records...
Comments? (Let me know if I am not clear, I can always include raw
headers if needed, but I think my point is obvious)
Clear as mud.
Should that have created a record in the External Relay array?
Probably. A full explanation of the mail path as you know it and the
headers which SA used to generate these would help here.
Note that the VERACITY of relay records not written by trusted systems
is known to be unverifiable and cannot be trusted
[ ip=169.239.218.195 rdns=se-filter03-195.tld-mx.com
helo=se-filter03-195.tld-mx.com by=REDACCTED ident= envfrom= intl=0
id= auth= msa=0 ]
[ ip=169.239.218.51 rdns=cp51.domains.co.za helo=cp51.domains.co.za
by=se-filter03.tld-mx.com ident= [email protected] intl=0
id=1rOAd4-007W0q-6X auth= msa=0 ]
[ ip=216.73.163.102 rdns= helo=WIN-9UDRVPAB9FG by=cp51.domains.co.za
ident= [email protected] intl=0 id=1rO6N0-0002Xr-0i
auth=esmtpsa msa=0 ]
[ ip=169.239.218.51 rdns= helo= by= ident= envfrom= intl=0 id= auth=
msa=0 ] (from X-Originating-IP)
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
