>> The discussion reminds me of when I was trying to write gui to say "when
>> header X is empty" [...] I eventually ended up with:
>>
>> if not header :regex "Cc" "." // If there is no Cc header that
>> contains
>> any character
>>
>> Which felt pretty clumsy for what seems to be a pretty obvious use for
>> Sieve.
>
> can you expound a little on this obvious use? I don't see the use case,
> myself, and am therefore skeptical to the need for a new reserved word
> NULL.
Well the user is trying to say "where there is no information in XXXX
headers".
Careful here. The simple presence of a field can be used to convey information.
Bcc: is the obvious example - now that recipient fields are optional it can be
used to indicate bcc copies were sent. RFC 2822 calls out this usage
specifically, as a matter of fact. I'm not sure I would ever write
a script that tested bcc this way, however, given how many transport
agents summarily (and incorrectly) drop bcc fields from messages in transport.
I have also seen an empty keywords field used to indicate "we checked for
applicable keywords but didn't find any", although RFC 2822 appears to disallow
this usage.
They don't care if the the header is absent, or is empty, they
just care that it contains no data and want to switch on both in the same
manner. So I could imagine script wanting to say:
"If there are no Cc addresses"
"If there is no subject"
"If there is no spam score header"
"If there is no virus score header information"
"If the priority of the message is not specified"
Headers with no value to them sound pretty useless,
Not necessarily. See above.
but of course some
headers are required to be there to meet the standards, and a header with no
value isn't prohibted by the standards, so a sensible filter really should
accommodate them. It feels as though sieve as it stands leaves the user to
write a couple of faulty scripts before they finally write their anyof(not
exists, is empty) test.
I'm again failing to see the real use case. Of course you can write users want
this or that behavior, but wanting something doesn't mean it is actually
useful. About the closest thing here is the "no subject" test you cite - I
could sort of see wanting to treat an empty subject the same way as as no
subject. Recipient field tests that go beyond things testing for explicit
presence of a particular address have always struck me as extremely risky given
the vagarities of how clients construct these fields and how they get mangled
by the transport infrastructure. As for score tests, this is probably a case
where you want to distinguish between no field and an invalid field (an empty
field is presumably invalid).
Of course this issue can be abstracted away and solved in the gui, I just
thought it was an issue worth bringing up in the context of this NULL/""
discussion, and wondered if it was worth us providing an easier solution for
writing these filters.
IMO the proposed solution adds complexity without adding value.
Ned