[exim-dev] [Bug 2369] New feature: single-key lookup type based on libcorkipset - https://github.com/dcreager/libcorkipset

2019-02-26 Thread admin--- via Exim-dev
https://bugs.exim.org/show_bug.cgi?id=2369

Ian  changed:

   What|Removed |Added

   Attachment #1178|0   |1
is obsolete||

--- Comment #7 from Ian  ---
Created attachment 1180
  --> https://bugs.exim.org/attachment.cgi?id=1180=edit
Latest corkipset update, dealing with the fscking dot vs colon problem

The situation around dots and colons in IPv6 addresses was insane already
before I started this work, and the insanity was showing in the way that
iplsearch was hardcoded as a special case.  This iteration of my patch heals
the insanity by introducing a new lookup API method, host_separator() which
tells the caller what the lookup in question expects as the IPv6 separator. 
When host_separator is not implemented for a lookup naturally the insane
default of '.' is assumed :-)

This iteration of the patch also makes my corkipset lookup (apart from the
existing iplsearch) implement this method, such that the find() method can
always assume IPv6 addresses in the normal, ':' separated format.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

2019-02-26 Thread Ian Zimmerman via Exim-dev
On 2019-02-26 22:26, Ian Zimmerman wrote:

> In fact it seems that iplsearch lookups are somewhat special when used
> in lists.  And that is what interests me in this situation, because I
> want corkipset lookup to share the same specialness.  I think the dot
> translation is an awful hack, and basically I want nothing to do with it
> ;-) 
> 
> Do you know how (where in the code) iplsearch is made special in this way?

Ok, I found it: it is in verify.c , function check_host().

I can deal with it, but my patch will have to touch (minimally) that code.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


[exim-dev] [Bug 166] Headers as well as body in file for autoreply

2019-02-26 Thread admin--- via Exim-dev
https://bugs.exim.org/show_bug.cgi?id=166

Michael Evans  changed:

   What|Removed |Added

 CC||mjevans1...@gmail.com

--- Comment #2 from Michael Evans  ---
What I need is just one small option flag for this router:

headers_continue

Default False; when set to True the delimiting double-CRLF between the "header"
and "body" sections would be suppressed.

Setting that to true would allow the use of MIME encoding libraries as well as
not statically encoding the global MIME escape character in the configuration
and in the generation of message reply files.  This would be MUCH more
//secure// than re-using MIME boundary parts.  It would also, hopefully, be
back-portable to stable Debian releases.

This could be a security issue in contexts where un-trusted users contribute
anything to the reply data, I'm having trouble thinking of an example offhand. 
However I'm not willing to say that it'd never be exploitable.

The above would make sending a MIME encoded multipart message body as a secure
option.

My current understanding is that such a message should look something like
this:


From: 
To: 
Subject: Example Multipart
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BLAH"

--BLAH
Content-Type: multipart/alternative; boundary="OHNO"

--OHNO
Content-Type: multipart/text; charset="utf-8"
Content-Transfer-Encoding; quoted-printable

The text and marked up versions are supposed to be equivalent.

--OHNO
Content-Type: text/html;charset="utf-8"
Content-Transfer-Encoding: quoted-printable

The text and marked up versions are supposed to be
equivalent.

--OHNO

--BLAH
Content-Type: image/jpgeg;name="somefile.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;filename="somefile.png"
Content-ID: 

Encoded file goes here.  Look this up if necessary

...

--BLAH

.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

2019-02-26 Thread Ian Zimmerman via Exim-dev
I am still confused by this paragraph in section 10.12:

 When an IPv6 address is converted to a string, dots are normally used
 instead of colons, so that keys in lsearch files need not contain colons
 (which terminate lsearch keys). This was implemented some time before
 the ability to quote keys was made available in lsearch files. However,
 the more recently implemented iplsearch files do require colons in IPv6
 keys (notated using the quoting facility) so as to distinguish them from
 IPv4 keys. For this reason, when the lookup type is iplsearch, IPv6
 addresses are converted using colons and not dots. In all cases, full,
 unabbreviated IPv6 addresses are always used.

My naive understanding was that lookups are more primitive than host
lists, and exim converts the subject into a string _once_ and then
matches it against each list item in turn, passing the converted string
to the lookup's *find() entry when an item refers to a lookup.  But this
paragraph seems to imply that exim does the conversion anew for each
lookup item; after all there could be multiple lookups of different
kinds in the list, some iplsearch and some plain lsearch.

In fact it seems that iplsearch lookups are somewhat special when used
in lists.  And that is what interests me in this situation, because I
want corkipset lookup to share the same specialness.  I think the dot
translation is an awful hack, and basically I want nothing to do with it
;-) 

Do you know how (where in the code) iplsearch is made special in this way?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

2019-02-26 Thread Jeremy Harris via Exim-dev
On 26/02/2019 18:23, Ian Zimmerman via Exim-dev wrote:
>   So at least this is a documentation bug.

Notes added; 52af443324 and c77d3d85fe.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

2019-02-26 Thread Ian Zimmerman via Exim-dev
On 2019-02-26 17:28, Jeremy Harris wrote:

> >   devuan-205f!35 exim$ cat strange-iplist
> >  "::::::0102:0203" : data
> >  ":::102:203" : also_data
> >  1.2.3.4 : more_data
> 
> 
> >   devuan-205f!38 exim$ ./src/build-Linux-aarch64/exim -C 
> > /home/itz/exim/exim.conf -be 
> > '${lookup{::::::0102:0203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
> >  bad
> >   devuan-205f!39 exim$ ./src/build-Linux-aarch64/exim -C 
> > /home/itz/exim/exim.conf -be 
> > '${lookup{:::102:203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
> >  bad
> 
> The address being looked up, :::102:203, is an ipv6-mapped ipv4
> and we'd expect it to match 1.2.2.3 in the file.  But you only have
> 1.2.3.4

But according to the spec (section 10.11) the mapping is done _when
checking an address for membership in a host list_.  I read that (IMO
with justification) as meaning a bare lookup does no such translation,
because none is mentioned in the part of the spec about lookups (that
would be section 9.3 I guess).  So at least this is a documentation bug.

The fact that the address I tested was a mapped one was intentional, of
course, because those are the ones presenting potential ambiguity when
expressed in a dot delimited form.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

2019-02-26 Thread Jeremy Harris via Exim-dev
On 26/02/2019 16:17, Ian Zimmerman via Exim-dev wrote:
> On 2019-02-26 11:21, Jeremy Harris wrote:
> 
>>> And bingo, it seems to not work as documented:
> 
>   devuan-205f!35 exim$ cat strange-iplist
>  "::::::0102:0203" : data
>  ":::102:203" : also_data
>  1.2.3.4 : more_data


>   devuan-205f!38 exim$ ./src/build-Linux-aarch64/exim -C 
> /home/itz/exim/exim.conf -be 
> '${lookup{::::::0102:0203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
>  bad
>   devuan-205f!39 exim$ ./src/build-Linux-aarch64/exim -C 
> /home/itz/exim/exim.conf -be 
> '${lookup{:::102:203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
>  bad

The address being looked up, :::102:203, is an ipv6-mapped ipv4
and we'd expect it to match 1.2.2.3 in the file.  But you only have
1.2.3.4


>> So far, I see you giving a dot-group-hex ipv6 to an iplsearch
>> lookup, which is wrong per docs:
>> "key for an iplsearch lookup must be an IP address".
> 
> Huh?  Both commands 38 and 39 (2nd and 3rd from the end in my up thread
> post) try looking up a colon-separated IPv6 address which is present in
> the file -- in fact the same address in both the abbreviated and full
> forms -- and do not find it.

I was looking at your last test, with
......0102.0203

-- 
Cheers,
  Jeremy

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

2019-02-26 Thread Ian Zimmerman via Exim-dev
On 2019-02-26 11:21, Jeremy Harris wrote:

> > And bingo, it seems to not work as documented:

  devuan-205f!35 exim$ cat strange-iplist
 "::::::0102:0203" : data
 ":::102:203" : also_data
 1.2.3.4 : more_data
  devuan-205f!38 exim$ ./src/build-Linux-aarch64/exim -C 
/home/itz/exim/exim.conf -be 
'${lookup{::::::0102:0203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
 bad
  devuan-205f!39 exim$ ./src/build-Linux-aarch64/exim -C 
/home/itz/exim/exim.conf -be 
'${lookup{:::102:203}iplsearch{/home/itz/exim/strange-iplist}{good}{bad}}'
 bad

> Which bit are you saying doesn't match docs?
> 
> So far, I see you giving a dot-group-hex ipv6 to an iplsearch
> lookup, which is wrong per docs:
> "key for an iplsearch lookup must be an IP address".

Huh?  Both commands 38 and 39 (2nd and 3rd from the end in my up thread
post) try looking up a colon-separated IPv6 address which is present in
the file -- in fact the same address in both the abbreviated and full
forms -- and do not find it.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset

2019-02-26 Thread Jeremy Harris via Exim-dev
On 26/02/2019 02:19, Ian Zimmerman via Exim-dev wrote:
> And bingo, it seems to not work as documented:

Which bit are you saying doesn't match docs?

So far, I see you giving a dot-group-hex ipv6 to an iplsearch
lookup, which is wrong per docs:
"key for an iplsearch lookup must be an IP address".

That's distinct from the use of dots in an iplsearch file.
-- 
Cheers,
  Jeremy

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##