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

[Alexey Melnikov <[e-mail]>]

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

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

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

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