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

From: Philip Guenther <[email-masked]>
Date: Wed, 19 Mar 2008 02:01:52 -0600

If the SMTP session was over IPv6, what should the "remote-ip" environment 
item be set to?  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
 	x:x:x:x:x:x:d.d.d.d
form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4".

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

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" "*.mydomain.com"

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 
made.

(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:
       ${client_addr}
            The  IP  address  of  the  SMTP   client.    IPv6
            addresses  are  tagged  with  "IPv6:"  before the
            address.  Defined in the SMTP server only.

       ${client_name}
            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
            ${client_resolve}.

       ${client_ptr}
            The  result  of  the PTR lookup for the client IP
            address.    Note:   this   is   the    same    as
            ${client_name}  if  and only if ${client_resolve}
            is OK.  Defined in the SMTP server only.

       ${client_resolve}
            Holds  the  result  of  the  resolve   call   for
            ${client_name}.  Possible values are:

                OK        resolved successfully
                FAIL      permanent lookup failure
                FORGED    forward lookup doesn't match reverse lookup
                TEMP      temporary lookup failure

            Defined   in  the  SMTP  server  only.   sendmail
            performs a hostname lookup on the IP  address  of
            the  connecting client.  Next the IP addresses of
            that hostname are looked up.  If  the  client  IP
            address  does  not  appear in that list, then the
            hostname is maybe forged.  This is  reflected  as
            the  value  FORGED  for  ${client_resolve} and it
            also shows up in $_ as "(may be forged)".

While client_ptr and client_resolve are probably overkill for the sieve 
environment extension, the tagging in client_addr and precise definition 
of when client_name contains a name and not an address literal seem like 
practical guidance in this area.)

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Sun, 23 Mar 2008 10:50:10 -0700 (PDT)

> item be set to?

I would think that in this case it would obviously be the IPv6 address.
However, I take your point that the format of such addresses needs to be
specified - the underlying standards for address formats having failed to
specify this with sufficient clarity or generality, it is now up to every
application protocol where such addresses appear to deal with it separately.
Sigh. Not the way it should be, but how it is.

  Perhaps there should be a prefix on the value that

> (Yes, this thought was triggered by the "IPv6-only" experiment during the

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:

 "remote-ip"
           => 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.

> 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" "*.mydomain.com" { ... }

  is not a good way to test whether the message came from 'outside' becaus
  anyone who can create a PTR record can create one that refers to whatever
  domain they choose.

>             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:

 "remote-host"
           => 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.

> practical guidance in this area.)

I agree - see above for my proposed solution for this issue.

				Ned

---

From: Philip Guenther <[email-masked]>
Date: Sun, 23 Mar 2008 20:54:09 -0600

On Sun, 23 Mar 2008, Ned Freed wrote:
<elided>

Looks good now, thanks.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Mar 2008 21:10:06 +0000

(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?
>

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.

>  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 

The text looks good to me.

> be blank if it cannot be resolved into a host name. How about:

I like that.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 25 Mar 2008 16:35:16 +0100

>   anyone who can create a PTR record can create one that refers to whatever
[...]
>               if for some reason this information cannot be obtained for

sorry, I don't understand what this means.  is the existence of a PTR
record sufficient?  it seems so, given the above added caveat.  if so --
how is a script able to detect a forgery?

-- 
med venleg helsing,
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 09:52:49 -0700 (PDT)

> 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.

> it seems so, given the above added caveat.  if so --

It can't. That's the point.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 27 Mar 2008 00:32:21 +0100

[...]
> 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:

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:

what do you think?
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Fri, 28 Mar 2008 14:16:44 -0700 (PDT)

>         untrusted source.  For example, the test:

I really don't want to get into the whole TLS cert thing in this document.

>         This information may come from an untrusted source.  For

This, OTOH, is fine. I'll include it in the next revision.

				Ned