[exim-dev] [Bug 2369] New feature: single-key lookup type based on libcorkipset - https://github.com/dcreager/libcorkipset
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&action=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
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
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
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
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
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
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
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
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/ ##
