Alexey Melnikov writes:
Arnt Gulbrandsen wrote:
If the original subject is invalid in some way I wouldn't respond in kind.
Can you clarify?
You thought the syntax of Subject is simple enough for everyone?
Some MTAs will give you a Subject field that contains null bytes, BELs
and other stuff that really should be encoded.
If the sender uses crapware, you can get a Subject field that contains
encoded-words, but the encoded-words are just wrong, and the rules in
RFC 2047 don't produce the result users want.
Subject: =?iso-8859-1?q?Are you there, Alexey??=
Those are from clueless but innocent senders. Nasty senders can give you
this and worse:
Subject: =?us-ascii?q?=0D=0A=0D=0DBody=? text?
There's more. If you want I can dig through our test messages. But these
examples should be enough.
In these well-considered cases, I would do something other than what the
mailto-notify document says, and I think I'd be right, so SHOULD seems
better than MUST to my eyes. But as I said, I don't object to MUST.
MUST is about valid input, and at least two of those three examples
aren't valid.
The part that reads:
If ":from" is not specified or is not valid, the envelope
sender of the notification message SHOULD be set either
to the envelope "to" field from the triggering message, as
used by Sieve, or to a fixed email address (so it "comes from
the notification system"), at the discretion of the
implementation.
already list all possible alternatives, so I don't think it is a
SHOULD either.
Those aren't all possible alternatives, so although I don't mind MUST
I rather like keeping SHOULD. (One other alternative is a system
address with a single-use subaddress.)
Ok, you and Barry have convinced me that this SHOULD is fine.
Also, how about deleting the word "fixed" above?
Fine.
Arnt