[Top] [All Lists]

Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]

2008-04-02 13:36:56

Arnt Gulbrandsen wrote:

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.

MTAs doing that are simply broken.

Now, if a user used encoded-character to specify such garbage in the :message value, that is another story. Hmm, I think we need to specifically allow implementations to alter Subject in such cases.

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.

Exactly (last sentence). And the MUST doesn't tell anything about encodings.

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?


I believe I've already suggested a better replacement for this in another message.