Bart Schaefer wrote:
On Feb 1, 9:11am, Steve Atkins wrote:
}
} On Feb 1, 2010, at 8:57 AM, Ian Eiloart wrote:
}
} > Does ARF allow richer expression than ANNOTATE?
}
} Probably - it's basically a container format.
}
} More importantly, perhaps, it would be easy to roll out on existing
} installations with a trivial configuration change, rather than
} requiring functionality in the mailstore that may not be there.
Anything that's going to be added as metadata to the message header
needs to be carefully specified so that a client that understands the
format can reside behind a server that does not. E.g., depending on
where this metadata is added, one option might be to require a DKIM
signature to cover it.
Consider the following off-the-cuff implementation possibility:
A header that has:
Name of server (or administrative unit (domain)) inserting the header.
What to send in report:
ARF copy, or forward or selected header[s] or?
How to send report:
email (including address), or some other protocol and
destination.
Are we asking that these could be inserted at source (eg: on AOL
outbounds)? Or, receiving-end implementation? Or both?
If receiver only, the receiver simply discards any previous ones and
inserts their own.
As long as the client "knows" whether its front ends support this
functionality (might be config value of administrative domain), and
ignores them if it isn't, the security issues are fairly limited.
Still need DKIM?
If the sender is "permitted" to insert them, for them to mean much, you
get into the same issues as end-to-end DKIM on email has. You know that
the signature verifies or not, but you still don't know whether you want
to trust the information.
I think of this as more of a "receiver sets policy". If we allow
senders to insert them, we have to have a way for the receiver to assert
overriding policy. Eg: "everything but stuff I can tell is from AOL
comes to me, and the AOL stuff can be sent as they request"). Either by
inspecting and possibly altering/replacing the header in flight, or
being able to get instructions on what to respect to the clients. The
latter might get rather nasty.
In any event, such things have to be thought out well in advance so that
the clients do have a solid spec to work against, and the receivers know
what they have to do too.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg