On Fri, Jun 26, 2015, at 02:01 PM, RW wrote:
> The received headers are parsed top to bottom; once an untrusted server
> is identified the chain of trust is broken and nothing below that can
> be trusted. Spammers can and do forge headers.
Got it.
Which leads back to the question you raised ...
On Fri, Jun 26, 2015, at 01:23 PM, RW wrote:
> They shouldn't be trusted unless there is a chain of trust. They don't
> matter anyway since they are from the original relay before the email
> was forwarded.
I thought that 'chain of trust' was established by their inclusion in the
internal_netwo
On my local server, I have SA running from within postfix+amavisd
My TRUST PATH works for 'sent-directly-to-me' mail. For 'forwarded-to-me'
mail, it incorrectly IDs my own internal IPs as untrusted relays.
How do I teach SA to correctly NOT id my own servers as untrusted?
Details ...
If I sen
for convenience, postfix & SA TLD-blocking snippets together:
in postfix
/etc/postfix/main.cf
...
smtpd_sender_restrictions =
...
+ check_sender_access pcre:/etc/postfix/reject_TLDs.pcre
permit_mynetworks
amavisd seems to be involved in this issue; not sure whether it's the 'culprit'
or the 'victim'.
A 'ham' mail received through postfix+amavisd+spamassassin arrives with headers
...
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Level:
X-Spam-Status: No, score
> > UNPARSEABLE_RELAY still hits. I've not yet determined what the actual
> > problem with the parsing is.
>
> It's a shortcoming/bug in the SpamAssassin ad-hoc parser.
>
> Please open a Bugzilla ticket and provide a sample of
> your Received header field (which is perfectly valid
> according to
Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly
prevents it from triggering the shortcircuit.
However, it still fires -- incorrectly & intermittently, albeit now with a "-1"
score attached.
The LHLO/LMTP header still is added at the backend, and UNPARSEABLE_RELAY s
> Are the 196.28.80.29, 196.28.80.61, and 196.28.66.13 in your
> trusted X.X.X.X/29 ? If they are, then hitting ALL_TRUSTED is expected.
No, the X.X.X.X/29 is a different server -- one of my own, not in a 186. block,
and definitely not in ZA.
> > Jun 18 22:38:19.967 [19747] dbg: check:
> > tes
I'm running
postfix 3.0.1
amavisd-new-2.10.1 (20141025)
SpamAssassin version 3.4.1
on linux/64.
amavisd/spamassasin is invoked as a postfix prequeue proxy filter.
Spam is getting scanned and scored. Usually correctly.
Intermittenly, I get an email that gets SHORTCIRCU
