On 4 Jul 2016, at 21:57, Alex wrote:
Hi,
On Mon, Jul 4, 2016 at 9:00 PM, Bill Cole
<sausers-20150...@billmail.scconsult.com> wrote:
On 3 Jul 2016, at 14:48, Alex wrote:
On 2016-07-03 20:18, Alex wrote:
whitelist_from *@pm.sprintpcs.com
[...]
From: Sprint User <5556142...@pm.sprint.com>
One of these things is not like the other... Not that it actually
matters.
This is also substantially confused by the fact that your pastebin
version
is both mangled by whatever is "quarantining" the message and
apparently
manually munged for privacy. That is probably confusing some of the
people
offering "help" becuase it isn't obvious what is substituted for what
and
how various oddities arose in that odd message...
Outside of using "example" in place of our domain, and changing the
phone number without affecting its format, no other changes were made.
I figured that out after doing my own testing and seeing that most of
what looked strange about your example was Sprint's. I had not looked at
the details of their breakage for a while and some of it is new.
There are SO MANY wrong things about this. At the top of the list:
Sprint is
adding fraudulent Resent-* headers. This breaks ANY rational attempt
to
whitelist in SpamAssassin, which unfortunately trusts the Resent-From
header
above all others to the point of ignoring all others entirely. If I
manually
remove the Resent-From header, SA sees both the RFC5321.MailFrom and
RFC5322.From values as part of "all '*From' addrs" but with
Resent-From it
only sees the local alias to which the SMS was sent.
In my initial message, I mentioned these were being quarantined, which
I thought was enough to make it clear I was pulling them from my
quarantine.
That was quite clear to me. Quarantine mechanisms vary greatly so it is
never exactly clear what a quarantine process has done and what is
original. Your quarantine seems to have changed the envelope sender to
the null sender, but it also preserv the original and other information
in X-* headers so that doesn't matter.
It was discovered in a later post that these Resent-From
headers were added during this quarantine process. I'm very sorry for
the confusion.
Here's the issue: I don't believe that to be the case, although it is
what I thought at first as well when looking at your sample.
However, since the message I sent myself as a test from my Sprint phone
to my personal mail server had analogous Resent-* headers with
Resent-Date matching the first Sprint timestamp, and I don't use any
sort of quarantine or other gadgetry that would ever add Resent-*
headers, it is clearly a quirk of Sprint.
Sprint is adding headers that cannot be accidental which describe a
resending event that never happened at the point where the message
entered the Internet email system through their machines. Without the
Resent-From header SpamAssassin could whitelist based on the envelope
sender (RFC5321.MailFrom) or even the From header (RFC5322.From) but
Sprint's inexplicable addition of the header make them impossible to
whitelist in any sane manner.
After removing the Resent-From headers, I'm able to successfully test
the whitelisting of the quarantined messages against my local
whitelist_from_rcvd entries.
Sprint is definitely broken, and I hate having to whitelist them. It
is really just the KAM_LAZY_DOMAIN_SECURITY from the KAM.cf rules
that's causing it to be quarantined. I suppose I could also write a
meta that subtracts the same points if it's been relayed through
sprintpcs, etc. I'm discussing this rule separately with Joe/Kevin for
this reason.
Thanks for your thorough help, as always.
I fear my first message was too verbose to be clear, so I'll put it more
directly:
Whitelisting of Sprint's messages based on any type of sender address
cannot work. That's entirely the fault of Sprint's weird addition of a
fake Resent-From header and a non-intuitive quirk of SpamAssassin that
makes Resent-From much too powerful.
