New 'high-risk change' thing in beta is horrible!

[aoeuaoeu]

Huh?? I don't understand the first thing you say. And the second thing you say is a strawman remark.

When I, or any other Sieve user, goes to make *only* `fileinto` edits there ought not be a password challenge. It's not a """high-impact or high risk""" change. Fact.

It's lazy..and it's amateurish..on Fastmail's part to treat all Sieve edits as """high-impact or high risk""" ones. If Fastmail insists on meddling with Sieve then it ought to examine the changes themselves.

[Terry]

Well if someone hacks into some ones email service (Fastmail) they can change the sieve script to divert emails and most people would not know the sieve script has been changed unless they look daily.

So having a password for some of us a good idea.

But now they have taken away the password lock on the aliases, same thing someone can add an email address to an alias and receive mail for that email address.

[aoeuaoeu]

No, dude, having a banner be visible for a limited time window (e.g., one week) is a good idea.

Example for Sieve: 'Sieve script modified Sat, Nov 12th'.

Example for aliases: 'Alias created Sat, Nov 12th'.

Gmail does something like this, I think.

Fastmail says the password prompt is for """high-impact or high-risk""" changes and, flat out, Sieve `fileinto` is neither of those things. Password prompt for measly `fileinto` is awfully heavy-handed, no matter how fearful some users feel.

[JeremyNicoll]

Originally Posted by Terry

Well if someone hacks into some ones email service (Fastmail) they can change the sieve script ....

So having a password for some of us a good idea.

Could you explain why? It seems to me that if someone "hacks into" someone's FM account, they already know the password ... so can easily change the script.


More of a hazard would be a someone (with the skill to change a script) getting at your PC/phone when you've left it unlocked & unattended. Then the password check would help.

But it seems to me that very few bad actors would tackle the script directly - for a start they'd have to know that that was possible when faced with a GUI allowing point+click changes. It'd be easier and probably quicker to add spurious rules via the GUI or to modify existing ones so they don't do what they originally did.

One of the problems with the GUI is that it doesn't show well the details of what any non-trivial filter does so (eg) adding a condition that effectively disables a rule is easy and you'd never know from the GUI's list-of-rules display. For example many of my rules display as eg

A header called Return-Path ends with @somedomain.com> AND Subject matches regular expres....

and the regular expression isn't displayed at all. Adding a third condition that is unlikely ever to be true disables the rule and is not clear.


You may have noticed that it's possible to add a "name" to a rule - which is something I (and maybe other people) asked FM to do, precisely because of this problem. But it has the drawback - if someone else has got-at your Settings - that the name text might be completely misleading.

[aoeuaoeu]

Yes! Great points! Thank you, JeremyNicoll, for writing it all out.

I don't use the relatively new 'rules' system--I use Sieve only--and so this all is Greek to me.

The answer here is banners not heavy-handed password prompts. 'Sieve last updated Sat, Nov 12th.' 'Rules last updated Sat, Nov 12th.'

Feels as if Fastmail has gone braindead with this heavy-handed password nonsense. Next they'll be asking for password when the user changes the color scheme!

[aoeuaoeu]

Originally Posted by Terry

Well if someone hacks into some ones email service (Fastmail) they can change the sieve script to divert emails and most people would not know the sieve script has been changed unless they look daily.

So having a password for some of us a good idea.

Do you even use Sieve, man??

[JeremyNicoll]

Originally Posted by aoeuaoeu

No, dude, having a banner be visible for a limited time window (e.g., one week) is a good idea.

Perhaps, but the script itself is auto-generated from one's rules and whatever logic they merge into it and might change more often than you expect.

Maybe every rule's date of last change should be stored/displayed so one could (at least) subset the display to show just the rules changed in the last n days. (This info IS available - see below - but not in the GUI.)

There'd need to be a display also of when changes last occurred in any of the optional user-supplied sections of the script.


I'd /hope/ that everyone who uses Sieve periodically opens the edit display and saves a copy of the whole script...


Aha! I just tried the "Export" option - which generates a JSON file, but it's clearly structured with lots of line breaks, not just one very long line of data as many JSON files look like) and easily readable in a text editor. Best of all, the information stored for each rule shows its date of creation and date of last change.

[aoeuaoeu]

Great post, JeremyNicoll. I didn't realize even that there's export functionality. Feels as if I'm just scratching the surface of the 'rules' section!