Isn't this really a generic issue, not specific to sieve?
It is. If anything at all, it applies to any mechanism that sends
messages or asks to send them, that is not just Sieve notifications,
but mail, SMS services etc. in general.
In discussions, we observed (Sieve) notifications have some properties
of redirects and this topic is no exception.
How can I protect myself from misredirected mails? I have had that
problem a few times now, because some people simply can't spell their
main address right, redirect to domain(_at_)localpart(_dot_)tld and the like.
One time I answered and told a member of a political part their internal
reports were rather boring to me. No answer, but the mails stopped. ;)
I called one admin and told him his perl installation lacked a specific
module and his cron job might work better if he installed it. He took
it with humour once he knew I did not break into his system, and fixed
the mail address for cron mails, too.
The problem does exist already, but so far answering solved it, because
the messages were sent by mistake and people don't like violating their
privacy by mistake. The message origin is usually quite clear and we
need to ensure it stays that way, that's why draft-ietf-sieve-notify-12
(the notification framework) says in section 3.3:
In order to minimize/prevent forgery of the author value,
implementations SHOULD impose restrictions on what values can
specified in a ":from" parameter. For example, an implementation may
restrict this value to be a member of a list of known author
addresses or to belong to a particular domain. It is suggested that
values which don't satisfy such restrictions simply be ignored rather
than causing the notify action to fail.
Spam, including SMS spam, is a different thing, because the sender tries
to hide.
Michael