Re: DKIM extension tags feature

On Fri, 8 Apr 2011, Daniel Black wrote:
> Sounds like one sure way to condem any future standard tags. I looked
> briefly on the release and got put of by John's contempt so I'll
> probably not look again. I could be missing something.

I wouldn't let one person's disdain for an idea prevent you from thinking
about it.

There are some obvious desired uses for per-user or equivalent tags. "i="
can be used that way, but some people think its strict format adds
needless complexity, so a new free-form tag would be better. This is a
mechanism for doing that.

Put another way: If a signer and a verifier want to add a tag to the
signature that between then means something, this is the way that would
happen. What's missing is some out-of-band signaling that such a
mechanism is in use, but that's more complicated to get right.

>> I've already crafted a patch to add support for this to libopendkim in
>> the next major release (later this year), but now I need to find a good
>> way to add this to the filter's configuration. My current plan is to
>> add a new data set called "ExtensionTags" that would would be queried
>> the same way SigningTable is queried; the filter would expect an even
>> number of values returned, in tag-value pairs.
>
> as a data set could it be queried on anything that would suit the
> majority of proposed used?

Not sure what you're getting at here. Can you elaborate?

>> Does that sound reasonable? Would tying it to the SigningTable make
>> more sense? Is there a better idea?
>
> A lua function to add tag-values.

Yep, did that. Just wondering if there's an easy, intutive "native"
option to be explored as well.

What we also need is a receive-side option, for detecting and abstracting
extension tags. I'll do that in Lua as well, but there might be a native
solution there that makes sense as well.
Received on Fri Apr 08 2011 - 15:12:20 PST