[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-freed-sieve-environment-04
> On Tue, 2008-03-25 at 09:52 -0700, Ned Freed wrote:
> > > On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> > > > Also a good point. I have added:
> > > >
> > > > The remote-host environment item defined in this specification is usually
> > > > determined by performing a PTR DNS lookup on the client IP address. This
> > > > information may come from an untrusted source. For example, the test:
> [...]
> > > sorry, I don't understand what this means. is the existence of a PTR
> > > record sufficient?
> >
> > Who knows? The mechanism used to obtian the remote-host isn't (and should not
> > be) specified. As such, a PTR could be sufficient. Or it may not be - some
> > systems do a backwards-forwards check. And there can even be cases when a PTR
> > record isn't needed - DNS names aren't the only game in town, you know.
> ok. I think it could be made a little clearer, though. how about:
> How to determine the remote-host environment item defined in
> this specification is left up to the implementation, e.g, if TLS
> is in use, the remote system's name can be extracted from the
> client certificate if the signer is trusted. Probably more
> commonly it will be determined by performing a PTR DNS lookup on
> the client IP address. This information may come from an
> untrusted source. For example, the test:
I really don't want to get into the whole TLS cert thing in this document.
> another alternative, with no specific details about alternatives:
> An implementation can use any technique to determine the
> remote-host environment item defined in this specification, and
> the trustworthiness of the result will vary. One common method
> will be to perform a PTR DNS lookup on the client IP address.
> This information may come from an untrusted source. For
> example, the test:
This, OTOH, is fine. I'll include it in the next revision.
Ned