[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Saturday, May 14, 2011 5:00 PM
Subject: Re: [ietf-dkim] Last Call: <draft-ietf-dkim-mailinglists-10.txt>
(DKIM And Mailing Lists) to BCP
Nits and Comments:
In Section 3.1.
author: The agent that provided the content of the message being
sent through the system. The author delivers that content to the
originator in order to begin a message's journey to its intended
final recipients. The author can be a human using an MUA (Mail
User Agent) or a common system utility such as "cron", etc.
What is "cron?" and how does it interface with the originator defined as
the MSA? is cron an MTA or MUA?
It's a daemon that runs on UNIX systems which can be told to run specific
programs at specific periodic times. It is neither an MTA nor an MUA; it is an
example of something that is an "author" in this context but is not also a
I suggest to remove the "or a common .." text since we already know
what MUA implies - a mail creation application or replace the text
or any other message creation application [with an MTA
That doesn't make sense in the case of cron because it doesn't have an MTA
component. It invokes a local MTA.
I personally say take it out. Not needed. Thats an *nix idea. Windows
people generally do not know what that is.
I think it's best to have an example. "cron" seems to be an ideal one, though
I'd be happy to add a second, Windows-specific, example if there is one. If
not, changing 'such as "cron"' to 'such as the "cron" UNIX utility' seems a
better change to me.
In Section 3.1.
verifier: Any agent that conducts DKIM signature analysis.
I know this is a semantical nit, but RFC4671 uses verification, never
analysis and it (analysis) is only stated as an out of scope boundary
layer concept (in section 3.11). Perhaps the intent is to suggest
the verifier does both:
verifier: Any agent that conducts DKIM signature validation and perhaps
[results|TRUST and ADSP] analysis.
The verifier does not do both. An external module deals with ADSP and "trust"
or other evaluation of the delivered domain name.
I would be fine with changing "analysis" to "validation" though, to make that
In Section 3.1 for receiver, it is very clear with stating the agent
for "final delivery", so why not add the MDA labeled terminology as it
was done with originator with MSA?
receiver: ..... This agent can be often referred to as the
Mail Delivery Agent (MDA).
Works for me.
Ietf mailing list