DNA (was: Re: [spf-help] Re: SPF and SenderID)
Dave Crocker <[email protected]> Sun, 24 Jul 2005 10:23:36 -0700
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Message-ID | <2005724102336.229287@bbprime> |
> but on the other hand it's specifically tailored to client SMTP
> ("_VOUCH._SMTP" etc.). the EHLO domain name can be chosen relatively
> arbitrarily, and you should be careful not to claim that reputable use
> of the EHLO name extends to other services.
that might be why the _vouch qualifies (is specifically linked to) _smtp.
> if DNA can be applied to identities
> established with mechanisms other than the implied CSV-CSA, this MUST in
> my humble opinion be tagged in the accreditation record with a service
> different from "MARID", and as such the interpration will be out of
> scope for the CSV-DNA specification. we do not want to (potentially)
> repeat the MAIL FROM vs. PRA mistake, do we?
I've read this paragraph several times. I am simply not understanding it. At
the least, I have no idea what the reference to tagging with a service different
from marid means.
>
> > > as the two reputations in CSV aren't connected, it is safe to say that
> > > the recovery will be quick...
> > >
> > No doubt my confusion is from not reading this thread carefully enough,
> > but I do
> > not know what "two" reputations are being referenced. CSV deals with one
> > identity, namely the host name provided in the client smtp's helo/ehlo
> > command.
> >
> the scenario was that a domain owner had chosen an e-mail provider with
> bad reputation for its MTA name. if the domain owner switches e-mail
> provider, the new provider's MTA name will be completely independent,
> and the domain owner's sent e-mail will instaneously be rid of the bad
> reputation.
That's why the helo/ehlo name is associated with the MTA operator. Your
phrasing suggests that the "domain owner" is somehow separate from the "email
provider", whereas the ehlo name IS the email provider.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net