Stop from going to Spam

[JamesHenderson]

I just received an update from support.

They have a fix written and pending code review and deployment, and expect it’ll be working again Monday or Tuesday..

[xyzzy]

Got it too. I guess he's pretty much echoing his updates on both tickets.

[SideshowBob]

Originally Posted by xyzzy

Ok, I guess. So you are disabling all the tests in section 3 (Sieve generated for spam protection) so that it doesn't matter what X-Spam-Known-Sender is set to? No backscatter to test either?

It depends on your backscatter setting, if it's set to discard you get:

### 3. Sieve generated for spam protection
if not header :matches "X-Spam-Known-Sender" "yes*" {
  if 
    allof(
    header :contains "X-Backscatter" "yes",
    not header :matches "X-LinkName" "*"
    )
  {
    discard;
    stop;
  }
}

which seems OK. Probably you can remove that with "Do nothing", but I'm not sure whether they still add X-Backscatter then.

I don't actually use any of this as I have a "stop;" at the end of the first section.

[xyzzy]

Originally Posted by SideshowBob

It depends on your backscatter setting, if it's set to discard you get:
- - -
Probably you can remove that with "Do nothing", but I'm not sure whether they still add X-Backscatter then.

That's the reason for changing X-Spam-Known-Sender, i.e., under conditions FM doesn't support in it's contacts (e.g., *@*.company.com). I don't want to have to be concerned about choosing the spam protection settings based on what code it may or may not generate. If those conditions remain all based on X-Spam-Known-Sender then I rather have the code flow as it was designed for unknown senders as usual no matter what my spam protection setting might be.

What's I find unique (?) about FM is it's sieve support and that it gives the user so much power to tailor their mail handling their own personal way. So you can do whatever you feel appropriate and I can do the same.

[JamesHenderson]

OK, Support has told me it has been fixed and it now works for me.

My script is like this and the idea is to whitelist without having the address in contacts (as I will never want to email these addresses).

### 0.  Whitelist
if not header :matches "X-Spam-Known-Sender" ["yes*", "in-addressbook"]
{
	if anyof(
		...,
		...,
		...
		)
	{
		deleteheader "X-Spam-Known-Sender";
		addheader "X-Spam-Known-Sender" "yes from sieve Whitelist";
	}
}

[xyzzy]

Yup, they updated my ticket as well. But so it doesn't fall through the cracks I reopened it reminding them they need to update Sieve Tester as well!

I gave them this small test case which is the one I used to verify it still doesn't work there.

require ["fileinto", "variables", "editheader"];

deleteheader "X-Spam-Known-Sender";
addheader "X-Spam-Known-Sender" "changed header";
if header :matches "X-Spam-Known-Sender" "*" {fileinto "${1}";}

with the following "email" as a test,

 X-Spam-Known-Sender: original header

Still seeing Sieve Tester filing the original and not the changed header.

Update:
Already got a reply (he must be there right now as I reported it). He says they are not going to fix sieve tester. Oh well. For Sieve Tester purposes this is not critical anyhow.

[JamesHenderson]

Originally Posted by xyzzy

Yup, they updated my ticket as well. But so it doesn't fall through the cracks I reopened it reminding them they need to update Sieve Tester as well!

I gave them this small test case which is the one I used to verify it still doesn't work there.

require ["fileinto", "variables", "editheader"];

deleteheader "X-Spam-Known-Sender";
addheader "X-Spam-Known-Sender" "changed header";
if header :matches "X-Spam-Known-Sender" "*" {fileinto "${1}";}

with the following "email" as a test,

 X-Spam-Known-Sender: original header

Still seeing Sieve Tester filing the original and not the changed header.

Update:
Already got a reply (he must be there right now as I reported it). He says they are not going to fix sieve tester. Oh well. For Sieve Tester purposes this is not critical anyhow.

Thanks for trying! I assume they think that not enough people will use Sieve Tester for that purpose.

[xyzzy]

Originally Posted by JamesHenderson

Thanks for trying! I assume they think that not enough people will use Sieve Tester for that purpose.

In this particular case they may be right. Not just that one purpose but for any purpose.

I've submitted other problems with Sieve Tester (ST) in the past they just reject them usually with the reason that they think not enough users use sieve to justify spending resources on ST. In general they are right about that too but my philosophy why even supply an inconsistent tool?

At any rate let me quote exactly what he replied about ST.

Sieve tester is almost certainly not ever getting fixed. It's not really built the same way as the rest of our code, which means that it's not ever going to be a reliable simulation, so it's not fit for purpose.

Hopefully after some more work on Sieve (namely, replacing all our use of the ManageSieve protocol with JMAP), we'll build a new mechanism for simulating Sieve behavior that is guaranteed to same way as the delivery mechanism.

Until then, I can pretty much guarantee that Sieve tester isn't getting any real time spent on it.

If they always have the mindset that not enough users use sieve why would they even bother with producing another tester (although I would think their tech support might need it sometimes too)? That second paragraph is encouraging but I am not holding my breath on this.