RE: How about A-R dkim-adsp's "header.from" value?

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Tue, 6 Jul 2010 11:23:16 -0700

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-
> bounce_at_lists.opendkim.org] On Behalf Of Alessandro Vesely
> Sent: Tuesday, July 06, 2010 11:16 AM
> To: opendkim-users_at_lists.opendkim.org
> Subject: How about A-R dkim-adsp's "header.from" value?
>
> Hi all,
> the specs seem quite confusing about that field. Does it actually
> /have/ to be there, or is it optional? Since A-R fields are not meant
> to be shown to end users, that question is really about what do we
> expect some downstream filter may do with such value.

Nothing can require you to add the field, of course. The specification is there to say "If you generate this, or you want to consume it, here's the format to use."

> In case the header.from value is needed, it apparently makes little
> sense to strip comments but leave the display name in place, since
> they can be used for the same purpose. Is that a "bug" in the ADSP
> spec? A "header.from" propspec appears in RFC 5451 for domainkeys,
> and in pre-rfc5451 drafts for dkim-adsp, and in both cases it is an
> easily parsable value...

That sounds more like a question for ADSP's authors than for this forum. But in any case I'm not sure why the display name is interesting to either specification.

> IMHO, for generic filtering, a "header.domain" would be the only
> required datum for decisions about signatures being or being not
> author domain ones, and I'd be tempted to use "x-header.domain". Is
> anything planned for opendkim's filter, about this?

I'm not clear on what you're proposing. What's an example of the case you're trying to cover?
Received on Tue Jul 06 2010 - 18:23:25 PST