If alice@example.com forwards to alice@example.net, then example.net should be aware of that, so that it considers example.com as a valid relay. Otherwise, this happens, and is expected.
The outgoing ip of that chapter (or any such entity forwarding to vrts) should be added to trusted_networks, so that SpamAssassin processes it correctly, see https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustedRelays

Would it be possible to add email headers with an example, with all personal information removed?

@jhathaway there's an example ticket-link, and some copied headers from that ticket, in the vrt-wiki thread: https://vrt-wiki.wikimedia.org/wiki/Administrator_requests#Whitelisting . It looks like you have an account on that wiki, so hopefully that helps? :)

Thanks @Quiddity I'll take a look at those links

There seem to be some general confusion about SPF here.
What Platonides said is almost right: SPF controls which server may originate a specific sender address using a specific domain. When SPF dictates that a sender can only arrive from 1.2.3.0/24 then any server trying to connect in using that sender(-domain) will get a failed SPF check.
Any server forwarding mail for whatever reason (this includes simple forwarders, aliased email, aliased role/group email, and some kinds of mailing lists) will fail this check, since they use the "original" sender but deliver the mail using their own IP.

This problem cannot be "fixed" by manually setting trusted_networks, since all the forwarders of the world shall be trusted, which wouldn't be really optimal. Adding only the chapters would resolve the problem only, well, for the chapters. (Admistering that manually isn't very effective, either, though probably chapter MXes can be automagically followed.)

The usual question is usually whether one can/will adjust SPF scoring with mail forwarders (like gmail tries to, sometimes), which is nontrivial and not very stable, or generally tune down SPF scoring that forwarders alone won't cause a spam classification.

(Unrelated thought: it is often not simple to weed out "our spam" from the common Junk queue where it gets mixed together. Maybe spamq-by-queues would make it simpler to

• detect our ham with in our own spam, and
• move all real spam into Junk in one swoop, by selecting all.)

spam-by-queue cannot happen. Not that nobody is able to handle that, nobody will handle it. And it's not the solution to the described problem, but at most only a weak cure for the symptoms.

@grin my point is to configure the antispam (spamassassin) run by ticket.wikimedia.org to trust the single ip that chapter uses to forward mail to VRTS (well, assuming it can be trusted)

This is relatively simple. There is no need to trust all forwarders of the world or try to guess forwardings.

The point that would be bring additional complexity would be if that chapter ip could not be (fully) trusted.

@Krd are mail moved into Junk and Probably-Spam marked somehow to be searchable by original Queue? (Preferably by stored search.)
(My problem space was that agents handle a few queues while Junk is mixed together from all of them, and agents probably do not want to sort out the spam for everybody. Is it slightly unrelated to the specific ticket though, so just mentioning.)

@grin I think this is out of scope of this task. We can discuss it at VRT wiki.