[Top] [All Lists]

Re: Comments on draft-freed-sieve-environment-04

2008-03-25 03:47:55

(Speaking as an individual contributor.)

Ned Freed wrote:

Perhaps there should be a prefix on the value that indicates the address family, or it should be formatted like the 'host'
part of URI?

Note that the obvious test of
     environment :matches "remote-ip" "*.*.*.*"

will match an IPv6 address literal if the implementation uses the
form, such as with the IPv4 compat addresses, ala "::FFFF:".

(Yes, this thought was triggered by the "IPv6-only" experiment during the
IETF technical plenary.)

Well, I certainly hope that for any given address there's exactly one way it will end up being represented. If that's not the case then there's a major
problem that goes far beyond this specific issue.

There's also the issue of how any future sort of address should be handled. Since RFC 2821 has already had to deal with this I think the best way to handle
it is by referring to the formats defined there. I currently have:

          => IP address of remote SMTP/LMTP/Submission client, if
             applicable and available. IPv4, IPv6, and other types of
             addresses are respectively represented in the formats
             defined by the IPv4-address-literal, IPv6-address-literal,
             and General-address-literal productions defined in
             [RFC 2821] section 4.1.3.

As a side note, I think RFC 2821 IPv6 format sucks, because it doesn't match what socket functions return on various OSes. (RFC 2821 uses "IPv6:" prefix). But it is too late to fix that. So, under the circumstances, your proposal is quite reasonable.

There probably should be a security consideration that explains that the
value of the "remote-host" item may be controlled by an untrusted source.
For example, the test
     environment :matches "remote-host" "*"

is *not* a good way to test whether the message came from 'outside' unless
the implementation there's some sort of IP->host->IP consistency check

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:

   if environment :matches "remote-host" "*" { ... }

 is not a good way to test whether the message came from 'outside' becaus

typo: because

anyone who can create a PTR record can create one that refers to whatever domain they choose.

The text looks good to me.

(The sendmail MTA faced the above issues some time ago for the pre-defined
variables it provides to its rulesets.  To quote the sendmail operations
guide, it defined variables as follows:
            The  IP  address  of  the  SMTP   client.    IPv6
            addresses  are  tagged  with  "IPv6:"  before the
            address.  Defined in the SMTP server only.

            The host name of the SMTP client.   This  may  be
            the  client's  bracketed IP address in the form [
            nnn.nnn.nnn.nnn    ]    for    IPv4     and     [
            IPv6:nnnn:...:nnnn  ] for IPv6 if the client's IP
            address is not resolvable, or if it is resolvable
            but  the  IP  address  of  the  resolved hostname
            doesn't match the original IP  address.   Defined
            in    the    SMTP    server   only.    See   also

I think a simpler way to handle this is to say that the name will
be blank if it cannot be resolved into a host name. How about:

I like that.

          => Host name of remote SMTP/LMTP/Submission client, if
             applicable and available. The empty string will be returned
             if for some reason this information cannot be obtained for
             the current client.