Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

2018-06-09 Thread Jeremy Harris via Exim-dev
On 06/10/2018 12:34 AM, Viktor Dukhovni via Exim-dev wrote: > > >> On Jun 9, 2018, at 7:17 PM, Jeremy Harris via Exim-dev >> wrote: >> >> It was: >> >> Zone: >>cname.example. IN CNAME nomx.example. >>nomx.example. IN A 192.0.2.

Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

2018-06-09 Thread Jeremy Harris via Exim-dev
On 06/09/2018 11:01 PM, Viktor Dukhovni via Exim-dev wrote: > I am confused by the comments in the bug tracker and code. > Can you share the cases you found that make it necessary > to recurse one extra time? > > I would expect the following behaviour from an iterative > resolver: > > Zone: >

Re: [exim-dev] [Bug 2235] New: CVE-2018-6789

2018-02-14 Thread Jeremy Harris via Exim-dev
On 14/02/18 10:58, Jakob Hirsch via Exim-dev wrote: > Anyway, I wonder why we need two base64 decoding functions. Sure, they > serve different purposes, but the inner parts mostly do the same (apart > from error handling). Shouldn't we consolidate this? > Any objections? Consolidation is good,

Re: [exim-dev] delivery event for retry timeout

2018-02-20 Thread Jeremy Harris via Exim-dev
On 20/02/18 04:28, Jasen Betts via Exim-dev wrote: > I wanted a per-recipient delivery event for "retry timeout exceeded" > so in retry.c I added the following to retry_update() > between "log_write" and "if (addr == endaddr) break;" > > msg_event_raise(US"msg:rcpt:retry:timeout",addr); > >

Re: [exim-dev] DMARC ARC

2018-02-23 Thread Jeremy Harris via Exim-dev
On 11/10/16 17:41, Jeremy Harris wrote: > On 11/10/16 10:24, Jeremy Harris wrote: >> On 10/10/16 16:27, Peter Gervai wrote: >>> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-00 >>> >>> Kind of signed "received" lines. It's implemented in GMail and AOL >>> test environments. Looks

[exim-dev] C99 coding features

2018-08-16 Thread Jeremy Harris via Exim-dev
Since f2ed27cf5f (between 4.89 & 4.90) we've documented a requirement on C99-capable compilers. This was the introduction of specified-initialiser use in the Exim code. How do people feel about other more-modern C features? This was triggered by the Postgres hackers ML pointing out that C99

Re: [exim-dev] UTF-8 and Exim string operations

2018-08-17 Thread Jeremy Harris via Exim-dev
On 08/17/2018 05:03 AM, Phil Pennock via Exim-dev wrote: > Anyone have strong feelings on how Exim should handle UTF-8 with > operators such as ${length_1:STR} ? > > Document that the current operators work on bytes This. Add new operators, or options on current ones; don't change how they

Re: [exim-dev] UTF-8 and Exim string operations

2018-08-18 Thread Jeremy Harris via Exim-dev
On 08/18/2018 08:38 AM, Heiko Schlittermann via Exim-dev wrote: > And a new addtional main option > > string_encoding = ascii | utf8 (default: ascii) > > which can then switch ${strlen:…} to be equivalent to ${ustrlen:…} I'm not particularly happy about global mode-switches. Too much

Re: [exim-dev] [Bug 2311] New: DANE verify fails with a TA-mode TLSA and a selfsigned sever cert

2018-09-09 Thread Jeremy Harris via Exim-dev
On 9/9/18 5:54 PM, Viktor Dukhovni via Exim-dev wrote: > This does not appear to be the right description. https://lists.exim.org/lurker/message/20180904.122640.3cbadefb.en.html The subject says "self signed". If it's not expected to work, perhaps you could explain why (on-list, to the

[exim-dev] Exim 4.91 RC1

2018-03-15 Thread Jeremy Harris via Exim-dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have built and uploaded Exim 4.91 RC1 to: https://ftp.exim.org/pub/exim/exim4/test/ NewStuff and Changes are as listed in https://lists.exim.org/lurker/message/20180314.204626.c1c63267.en.html The tree is still open for all commit

Re: [exim-dev] [Bug 2250] Peculiarity with SMTP delivery in Exim 4.90.1

2018-03-09 Thread Jeremy Harris via Exim-dev
On 09/03/18 13:25, admin--- via Exim-dev wrote: > That patch doesn't apply cleanly to "80a47a2c96". It looks like quite a long > has changed since then, so I'm going to need some help applying the same fix > to > intermediate versions. 80a47a2c96 was 2006; you're only looking for problems

[exim-dev] Kickoff for next release

2018-03-14 Thread Jeremy Harris via Exim-dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm starting the release procedure for the next release. As usual there will be a number of Release Candidate builds as we shake it down. Commits of any kind are acceptable at this stage; at some future point I'll declare "bug fixes only". Please

[exim-dev] branch exim-4_91+fixes created

2018-04-23 Thread Jeremy Harris via Exim-dev
For distro maintainers, and similar, as per Subject and similar to previous +fixes branches. Intent is to only carry actual fixes, no new features or minor fiddling. The master branch remains the main path of development; this one is subsidiary but may be of interest to distro maintainers

Re: [exim-dev] branch exim-4_91+fixes created

2018-04-24 Thread Jeremy Harris via Exim-dev
On 23/04/18 23:05, Renaud Allard via Exim-dev wrote: > On 23/04/2018 14:57, Jeremy Harris via Exim-dev wrote: >> For distro maintainers, and similar, as per Subject > Do you release a downloadable tar.gz archive of that branch? This would > be interesting for maintainers which are

Re: [exim-dev] [Bug 2266] New: TLS SNI should default set

2018-04-17 Thread Jeremy Harris via Exim-dev
On 17/04/18 22:23, Viktor Dukhovni via Exim-dev wrote: > Not sure what you mean by "$domain", It's an Exim variable. The part of a mail address after the @. but the DANE SNI *must* be the TLSA > base domain, You're commenting with reference to the specifically non-DANE bug number. -- Jeremy

Re: [exim-dev] Preliminary dane_require_tls_ciphers support

2018-03-29 Thread Jeremy Harris via Exim-dev
On 29/03/18 04:08, Phil Pennock via Exim-dev wrote: > I've written support for a new SMTP Transport option > dane_require_tls_ciphers which is like tls_require_ciphers but is used > in _preference_ to tls_require_ciphers when DANE enabled. > > This seemed much saner than requiring lots of

Re: [exim-dev] Exim 4.91 RC1

2018-03-18 Thread Jeremy Harris via Exim-dev
On 18/03/18 03:05, Phil Pennock wrote: > On 2018-03-17 at 15:00 +0000, Jeremy Harris via Exim-dev wrote: >>> Enabling DMARC without enabling >>>SPF led to a build failure almost at the very end. >> >> Compile-time or link-time failure? Do you think

Re: [exim-dev] Exim 4.91 RC1

2018-03-17 Thread Jeremy Harris via Exim-dev
On 17/03/18 01:52, Phil Pennock wrote: > Building for `next-exim` on the exim.org box, the port-26 listener: > > * `EXPERIMENTAL_ARC` is not given with `=yes` in `src/EDITME`, which is >inconsistent at least Fixed. > * First build attempt failed: > malware.c:2150:6: error: ‘ava_re_clean’

Re: [exim-dev] delivery event for retry timeout

2018-03-05 Thread Jeremy Harris via Exim-dev
On 21/02/18 06:47, Jasen Betts via Exim-dev wrote: >> Why not just "msg:rcpt:timeout" ? What distinction were >> you implying? > > That suggests to me a TCP or SMTP timeout which will normally > be retried. retry timeout exceeded is permanent. maybe > "msg:rcpt:expired" is better? > > Do you

Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-16 Thread Jeremy Harris via Exim-dev
On 16/12/2018 10:20, Andreas Metzler via Exim-dev wrote: > 4.92rc1 adds this to the smarthost_smtp transport: > > tls_sni = $host > > I do not think that always works as expected. Depending on the DNS setup > (CNAME, round robin) $host will not contain the name of the selected > smarthost

Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-20 Thread Jeremy Harris via Exim-dev
On 19/12/2018 00:51, Phil Pennock via Exim-dev wrote: > I think this change is generally useful, in having a cleaner setup for a > very common use-case, and showing exactly where new macros should be > defined, which can reduce some of the pain encountered by newcomers to > Exim. The wording

Re: [exim-dev] Tests with TLS 1.3?

2018-12-24 Thread Jeremy Harris via Exim-dev
On 24/12/2018 09:54, Andreas Metzler via Exim-dev wrote:> did anybody yet test exim with TLS 1.3? > > Server side (exim/GnuTLS accepting messages from swaks or mutt) seems to > work (see header), however I have yet to find a public SMTP server who > offers TLS 1.3, to test outgoing deliveries.

Re: [exim-dev] [exim] Exim 4.92-RC1

2018-12-15 Thread Jeremy Harris via Exim-dev
On 14/12/2018 15:24, Paul Hecker via Exim-dev wrote: > can no longer compile this version with my current Makefile as there is > > WITH_CONTENT_SCAN=yes > > enabled and all other scanner interfaces disabled (as DISABLE_MAL_CLAM=yes, > DISABLE_MAL_AVAST=yes etc.). > > The error at compile-time

Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-04 Thread Jeremy Harris via Exim-dev
On 04/01/2019 01:02, Florian Zumbiehl via Exim-dev wrote: > may I suggest you put that on the > website somewhere? It was already there, at https://bugs.exim.org/enter_bug.cgi -- Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at

Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-02 Thread Jeremy Harris via Exim-dev
For the record, if you have a sensitive security issue, please mail secur...@exim.org -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

Re: [exim-dev] Enable enable_prdr by default

2019-01-12 Thread Jeremy Harris via Exim-dev
On 11/01/2019 09:59, Дилян Палаузов via Exim-dev wrote: > To make progress with PRDR please switch the default for enable_prdr to True. Although doing so would be safe (a missing prdr ACL is defaulted to "accept"), it would be pointless from the point of view of the receiving end and somewhat

Re: [exim-dev] Enable enable_prdr by default

2019-01-14 Thread Jeremy Harris via Exim-dev
On 13/01/2019 10:06, Дилян Палаузов via Exim-dev wrote: > Anyway, implementing Sieve’s ereject will make it very easy to do rejecting > per recipient without explicit ACLs. Just > let the user upload Sieve. I suggest you try that before implying it will interwork with PRDR. I don't think it

Re: [exim-dev] buildfarm client proposal: tests configure support

2018-09-16 Thread Jeremy Harris via Exim-dev
On 9/15/18 2:34 AM, Phil Pennock wrote: > I've pushed to buildfarm-client.git a new branch `test_configure_tuning` > with one additional commit: > > https://git.exim.org/buildfarm-client.git/shortlog/refs/heads/test_configure_tuning >

Re: [exim-dev] Test suite unusable?

2019-02-23 Thread Jeremy Harris via Exim-dev
On 24/02/2019 01:16, Ian Zimmerman via Exim-dev wrote: > devuan-205f!2 test$ ls -l aux-fixed/0037* > -rw-rw-r-- 1 itz eximtest 1660 Feb 23 13:33 aux-fixed/0037.f-1 Thanks! You found a testsuite bug; the message has been wrong since I first wrote it (and you're the first to notice!). It should

Re: [exim-dev] Test suite unusable?

2019-02-23 Thread Jeremy Harris via Exim-dev
On 23/02/2019 22:44, Ian Zimmerman via Exim-dev wrote: > the 2nd complaint is probably not a showstopper, but the only > world-writeable files are as follows: > > eximtest@devuan-205f:~/exim/test$ ls -lRa aux-fixed/ | grep 'w[-xsS] ' > lrwxrwxrwx 1 itz eximtest 15 Feb 23 13:33 9ec80de3.0 ->

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

2019-02-24 Thread Jeremy Harris via Exim-dev
On 24/02/2019 18:52, Jeremy Harris via Exim-dev wrote: > On 24/02/2019 18:11, Ian Zimmerman via Exim-dev wrote: >>> I'd expect conversion to unabbreviated form to have been done too. >> >> Do you mean I can expect an IPv6 address (mapped or not) to have exactly &

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

2019-02-24 Thread Jeremy Harris via Exim-dev
On 24/02/2019 07:47, Ian Zimmerman via Exim-dev wrote: > On 2019-02-10 23:03, Jeremy Harris wrote: > >> If you can reliably detect the ipv6-ness, yes, that sounds like the >> minimally intrusive way. > > How are the IPv4-mapped IPv6 addresses written in Exim? > > The straight translation to

Re: [exim-dev] Test suite unusable?

2019-02-24 Thread Jeremy Harris via Exim-dev
On 24/02/2019 02:23, Ian Zimmerman via Exim-dev wrote: > Do you have a suggestion for the version mismatch? Ignore it. -- 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-24 Thread Jeremy Harris via Exim-dev
On 24/02/2019 18:11, Ian Zimmerman via Exim-dev wrote: >> I'd expect conversion to unabbreviated form to have been done too. > > Do you mean I can expect an IPv6 address (mapped or not) to have exactly > 7 separators, whatever these might be? If yes, there is no ambiguity. That is my hope. But

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

Re: [exim-dev] [Bug 2376] New: log_message doesn't log if connection is interrupted (which is quite unexpected) while other rules in the same acl are applied

2019-02-20 Thread Jeremy Harris via Exim-dev
On 20/02/2019 12:25, Arkadiusz Miśkiewicz via Exim-dev wrote: > Is there a way to do ratelimit counting but make it return true, so > entire acl will fire? Have a very large limit (so it never exceeds it) and negate the condition. I suggest this rather than a zero limit as I cannot recall

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

2019-02-24 Thread Jeremy Harris via Exim-dev
On 24/02/2019 19:17, Jeremy Harris via Exim-dev wrote: > I don't know if a lookup done via the list-syntax > "hosts = corkipset:/filename" > will be different. Probably it will, sigh. Dots, and always seven. I tested by adding "pipeline_advertised_hosts = n

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 :

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-10 Thread Jeremy Harris via Exim-dev
On 10/02/2019 22:42, Ian Zimmerman via Exim-dev wrote: > Turns out the underlying library wants IPv6 addresses colon separated; > but in contexts where a host address is being tested for list > membership, exim passes it to the lookup as dot-separated. This is of > course documented in the Spec,

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

2019-02-07 Thread Jeremy Harris via Exim-dev
On 04/02/2019 15:53, Ian Zimmerman via Exim-dev wrote: > Is there a document about the preferred project style? I've done a quick writeup here: https://github.com/Exim/exim/wiki/Exim-coding-style -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim