[hmm, missed this until now]
On Sun, Apr 13, 2008 at 03:54:31PM +0100, Alexey Melnikov wrote:
Mark E. Mallett wrote:
I didn't [intend to] suggest getting rid of the envelope-to field from
the list of choices, but only to add an address associated with the
Sieve script to that list. I think the owner's address is at least as
good a choice for a fixed address as a system-wide one. It may be
more readable to express it as a list, e.g.:
If ":from" is not specified or is not valid, the envelope
sender of the notification message SHOULD be selected from
one of the following, at the discretion of the implementation:
- the envelope "to" field from the triggering message, as used
by Sieve;
- the address of the owner of the Sieve script;
But "the envelope "to"..." is "an address of the owner".
But not necessarily *the* address of the owner, i.e., not a fixed
address.
Note also that this mention of the "envelope 'to'" should probably be
qualified as "final envelope to" (the word "final") as has been done
elsewhere.
If multiple email aliases go to the same mailbox, I think it would be
better to use the envelope "to", so that a recipient of mailto
notifications can distinguish between different aliases.
I see that, too; and I wouldn't want an implementation to be prevented
from doing that. But see below.
- an email address associated with the notification system.
I'm actually not really happy with that wording "the address of the
owner of the Sieve script" either. What I am really aiming for (as
quoted above, even) is to allow an implementation to optionally be
configured with an email address associated with notification messages
for any individual mailbox, and that it could choose to use that as a
default return address if present.
I agree that the envelope-to is the best choice if the application
hasn't been configured to use a fixed address. But I also think that
having the only choice for a fixed address be a system-wide one isn't
fine-grained enough. So maybe instead of "the address of the owner
of the Sieve script", more like:
- an email address associated with notification messages sent on
behalf of the email-address receiving the message;
and it's up to the implementation how that association is made, or
whether it's made at all. One could actually interpret that to cover a
system-wide address, as well, maybe with some slight fiddling, so that
the other choice (the "email address associated with the notification
system") could be dropped.
This seems awfully trivial but I'm having a hard time being concise
about it, sorry.
mm