> For an e-mail application service provider, (ESP), one way
> to do this is for that entity to sign the RFC 2822 sender
> header.
>
> By doing so, the ESP says "I, ESP am the entity sending
> this email on behalf of my client, List (identified in the
> RFC 2822 from header) and as such an identity that is
> associated with that email and can be held accountable."
>
> This approach is consistent with best practice and is
> specifically allowed for in DK.
>
> Am I now to understand that no, you may only sign the RFC
> 2822 from header and nothing else,
No. Sender SHOULD be signed if that is what makes the authentication of
the message stronger. But I think the "confusion" is......
> if you want to: (i)
> publish a sender signing policy; or (ii) take advantage of
> any reputation proposals such as the Domain Assurance
> Council, which although out of scope, is one of the
> perceived benefits of DKIM?
>
> If so, then in it seems we are moving in the wrong
> direction. The approach is not backward compatible. It will
> prejudice the ability of certain entities to follow best
> practice. It appears to undermine the mission statement
> quoted above.
>
> On this basis only, I add my vote in favor of this petition.
.... that the ESP here is a THIRD PARTY SIGNER!
The critical issue, debate, 'dividing line' whatever you want to call it
is the "AUTHORIZATION" of the signing.
In other words, I own the domain, just because you may be hosting my
mail, doesn't really mean you have the authority to sign on my behalf.
Remember, the specs does say the signer is now accountable. So you have
to consider the idea that the ESP/ISP may not want to get involved and
in the TRADITIONAL is to not get involved in the passthru nature of
mail. Thats been the best practice and what most systems work with on
that basis.
Well ... that analysis is not accurate based on how
I operate in today's environment of abuse and compliance
management.
In my world, the ESP is the accountable party as far as the
rest of the Net is concerned. .
ESPs would love to avoid responsibility, but ... you can't.
True, the client provides the message content and the email
address for the from header.
Yes, at least one receiving network likes to see one list per
IP address.
True, the email addresses collected by the client through use of
the ESP's facility are property of the client.
Most ESPs allow clients to import data and send mail to
their lists using the ESP's facilities.
(BigHip does not, but that is another story.)
Hence the traditional "pass through" argument.
But, that "approach" allows ESPs to avoid responsibility
for the abuse coming from their network when for
example the client imports and mails to a "bad list."
In turn, this refusal to take responsibility in general
is one of the underlying reasons why we are in today's
mess.
In my view it is simple. Folks must be responsible for their
own backyard.
Therefore, in simplistic terms:
The ESP is responsible to the Net to stop abuse
coming from its network.
The ESP is accountable to the Net to respond to
complaints of abuse coming from its network.
It is therefore appropriate in most cases that the
ESP is authorized to sign for mail sent from its
Network on behalf of its clients using the sender
header because the ESP is the responsible and
accountable party to the Net.
John
John Glube
BigHip - Abuse / Compliance
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html