Re: [exim-dev] [exim] spool format error: size

2019-05-02 Thread Jeremy Harris via Exim-dev
On 02/05/2019 23:06, Magnus Holmgren via Exim-dev wrote:
> That code is from SA-Exim, which implements a local_scan() function. What I 
> mean is: is there something wrong with this code, or has something been 
> broken 
> in Exim so that the permanent pool doesn't work?

It looks right per the exim docs.   However, the local_scan facilities
are not something the exim testsuite exercises; quite possibly something
has been broken.  They're also not something I've ever explored.

I doubt the permanent-pool is broken as a general thing; all
sorts of odd things would be visible in general operation.


There's a couple a memory-related debug facilities it might be
possible for you to try:

- a main-section option "debug_store", boolean.
  Set true to add checks on whether any memory being used
  by an active exim $variable is covered by a blob being
  freed.

- run under the test-harness; freed memory is overwritten
  by a distinctive pattern.

-- 
Cheers,
  Jeremy

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


Re: [exim-dev] [exim] spool format error: size

2019-05-02 Thread Jeremy Harris via Exim-dev
On 01/05/2019 22:54, Magnus Holmgren via Exim-dev wrote:
> The problem definitely is with primary_hostname getting overwritten with 
> random data after the first message, even though the code sets store_pool = 
> POOL_PERM, as directed by the documentation:
> 
> /* This needs to be retrieved through expand_string in order
>not to violate the API. */
> static uschar *primary_hostname=0;
> if (!primary_hostname) {
> store_pool = POOL_PERM;
> primary_hostname = expand_string("$primary_hostname");
> store_pool = POOL_MAIN;
> }
> 
> Is this a bug in SA-Exim or in Exim?
> 
> I could always change this to always expand $primary_hostname; it shouldn't 
> take any appreciable amount of time.

I don't find that code in the exim source... Is this a local_scan
function?

One point: It might be worth trying restoring the previous store_pool
rather than always setting it to POOL_MAIN, in case that documented
behaviour is no longer valid.  Though, as you say, a simple expansion
like that is pretty cheap.

-- 
Cheers,
  Jeremy

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


Re: [exim-dev] Mailop list: exim and google fighting over DKIM

2019-04-29 Thread Jeremy Harris via Exim-dev
On 29/04/2019 20:06, Graeme Fowler via Exim-dev wrote:
> On 29 Apr 2019, at 19:26, Andrew C Aitchison via Exim-dev  
> wrote:
>> I will do so, either here or in that bug, when I can do so without causing 
>> more heat.
> 
> The gist of the discussion (I’m a mailop subscriber) is manyfold:
> 
> 1. Google accept messages over IPv6 but require stricter verification over 
> IPv6 than IPv4
> 2. mailop.org has no SPF record
> 3. mailop.org can deliver to Google over IPv6
> 4. Signed messages inbound to mailop.org (and other lists!) from 
> Debian-derived and other setups using the default macro defined in pdkim.h 
> can have headers added which have been declared signed when they’re not 
> present*
> 5. Adding them invalidates the signature, and if the MLM software doesn’t 
> remove or re-sign the message, that can be problematic if a receiving system 
> is taking extra care with respect to verification

Bzzt.

Stop right there.

The ML adds body content.  This will invalidate the signature.

The header thing, even if you do game it, will not help that.

> 6. It appears Google will reject messages that combine elements 1 thru 5
> 
> * this is the bit I’m confused by; I have a large historical pile of messages 
> to lists from me and I can’t see a signature with those headers included 
> despite me using the defaults for a long period.
> 
> RFC4871 stated that a suggested list of headers SHOULD be signed, if existing.
> RFC6376 dropped the SHOULD and provided an example of what constitutes the 
> “core” of a message.
> 
> So *either* the Debian-derived configuration (of which the original poster 
> mentioned they were using unaltered for DKIM purposes, inheriting defaults) 
> does something different to what is expected by defaukt, or Exim’s behaviour 
> changed somewhere after 4.86/4.87 (still trying to pinpoint that) but I can’t 
> see or replicate the issue.
> 
> Puzzled, perplexed… and given that this has only just been raised, I’m even 
> more puzzled by it. There must be receivers out there who have insanely 
> strict validation policies who would have seen this before!
> 
> Graeme
> 


-- 
Cheers,
  Jeremy

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


Re: [exim-dev] Mailop list: exim and google fighting over DKIM

2019-04-29 Thread Jeremy Harris via Exim-dev
On 29/04/2019 20:33, Brielle Bruns via Exim-dev wrote:
> Heya, original cause of the havoc on mailop here!
> 
> I'll try and answer whatever questions I can.  See below.
> 
> 
> On 2019-04-29 19:06, Graeme Fowler wrote:> So *either* the
> Debian-derived configuration (of which the original poster mentioned
> they were using unaltered for DKIM purposes, inheriting defaults) does
> something different to what is expected by defaukt, or Exim’s behaviour
> changed somewhere after 4.86/4.87 (still trying to pinpoint that) but I
> can’t see or replicate the issue.

4.87 introduced support for oversigning.

> Version: 4.92-2~bpo9+1
> 
> My configuration files are ancient.  IIRC, I originally built them from
> the debian config back around 2005 or 2006 (We've actually been using
> exim since 2003).  They got updated over the years as needed and include
> a bunch of special stuff that is integrated with my DNSbl work.
> 
> So, the DKIM section is based on what I found in Debian's config.  Under
> the remote_smtp transport, I have the following:
> 
> dkim_domain = DKIM_DOMAIN
> dkim_selector = DKIM_SELECTOR
> dkim_private_key = DKIM_PRIVATE_KEY
> dkim_canon = DKIM_CANON

You'll get the default headers signed, then.  That includes signing
the lack-of-presence of a header in the set.

However: it's irrelevant.  The ML adding a header making the signature
bad does not matter.  The ML also appends to the body... making your
signature bad.  That's what signatures are for (I'm sure you know this,
just wanting to be clear in case...)

So.  DKIM signatures do not survive transmission through a ML.
(Sometime phrased as "DKIM breaks mailinglists").

The DKIM RFCs say "do not treat a lack of verifiable DKIM signature as
cause for rejecting a message".  Google is ignoring that, and the
brou-ha-ha is not really, IMHO, Exim's problem.  It's a 800Kg gorilla
problem.

-- 
Cheers,
  Jeremy

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


Re: [exim-dev] Mailop list: exim and google fighting over DKIM

2019-04-29 Thread Jeremy Harris via Exim-dev
On 28/04/2019 16:42, Andrew C Aitchison via Exim-dev wrote:
> Do the DKIM exim experts subscribe to the mailop list ?
> 
> There is an ongoing discussion on the mai...@mailop.org
> about a snafu with DKIM which implicates exim and google.
> 
> The original report of the snafu (google rejections caused the list to
> auto-unsubscribe over a hundred subscribers of the list):
> https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013974.html
> 
> 
> A description of the sending system that caused the issue:
> https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013991.html
> 
> 
> A suggestion for the exim developers:
> https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013994.html
> 
> 
> Basically a user with a stock debian exim setup (version number yet given)
> sent a message to the list with some signed non-existent headers; when the
> list passed the message on it generated these headers and google failed
> on the signature discrepancy.


Most mailinglists, including mailop, append to the body of submissions
distributed as non-digests, so DKIM signatures will become invalid due
to that (assuming the mostly-deprecated DKIM bodylength feature is not
used).

Trying to game the adding of list headers would be applying lipstick to
a pig.

The snafu is Google's fault for ignoring the part of the DKIM standard
that says "a lack of verifiable signature should not be grounds for
rejection" (my paraphrase, RFC 6376 Section 6.3), and DKIM's fault for
being an enabler of breaking traditional uses of email (mailinglists,
in this case).

-- 
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 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 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 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/ ##


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 = net-corkipset;DIR/aux-var/TEST.ipset"

to the config, some "exim -bh" to the script and some
debug_printf() in the code.  I didn't look at actual
results of the lookups though.
-- 
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: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
>> 7 separators, whatever these might be?  If yes, there is no ambiguity.
> 
> That is my hope.  But hope is all it is.  This is why I say you need to
> test.  And leave the testcases in the testsuite.

I gave in and ran some tests myself.

My optimism was misplaced, but it doesn't matter.  Your code gets
given the raw string from the user; it is _not_ colon-to-dot
translated - it can have any format of ipv6 or ip4 address
(and possibly also just be bogus).

This is with a direct ${lookup } call as per your testcases.

I don't know if a lookup done via the list-syntax
  "hosts = corkipset:/filename"
will be different.  Probably it will, sigh.

More testing needed.
-J

-- 
## 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 hope is all it is.  This is why I say you need to
test.  And leave the testcases in the testsuite.

> 
> I think I must keep in mind 2 cases:
> 
> 1. Addresses coming from exim itself, for example $sender_host_address.
> Unfortunately the spec doesn't say what format this is in (if it is
> IPv6).  Can you enlighten me about this?

That specific expansion returns whatever the library inet_ntop()
does.  The Linux manpage says, for ipv6, "the most appropriate ...
format".  I think that means "abbreviated".  It does note that
ipv6-mapped ipv4 addresses are converted to ipv6, which I assume
means "no dotted tail section" (it lists that as a bug, so it could
change sometime).

> 2. Addresses explicitly written into the configuration by user.  This
> one is about what I can require from users.  I need to document that in
> the experimental documentation file.

I'm hoping it turns out that you can handle all reasonable input
representations with minimal effort, so placing few restrictions
on the user.
-- 
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 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 dots instead of colons would be ambiguous,
> wouldn't it?   Say, ...1.2.3.4 could mean either the mapped address
> or the normal IPv6 address 0:0:0::0001:0002:0003:0004 .

You can write them either way; both are acceptable and the number-base
of the dotted-portion gets translated ( .234 does _not_ become :0234 ).

But that's ipv6 addresses given to exim, not how they are given to
the place you're coding.  I think you need to check, given that a
colon-to-dot translation has been done by the time it hits you.
I'd expect conversion to unabbreviated form to have been done too.
-- 
Cheers,
  Jeremy

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


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] 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 say "group".  You presumably are
not running the README guidance of an 022 umask;
fix by "chmod -R g-w aux-fixed".

-- 
Cheers,
  Jeremy

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


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 -> ../../CA/CA.pem
>  lrwxrwxrwx 1 itz eximtest   19 Feb 23 13:33 d89e5358.0 -> ../../CA/Signer.pem

What does "ls -l aux-fixed/0037*" tell you?
-- 
Cheers,
  Jeremy


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


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 whether
the first-ever value is zero. You'd need "strict" for that, too.
-- 
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-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, section 10.12.
> 
> Since IP addresses are the only things worth testing by this lookup,
> maybe I should internally translate them from dot to colon, before I
> pass them to libcork?

If you can reliably detect the ipv6-ness, yes, that sounds like the
minimally intrusive way.
-- 
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-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 
details at http://www.exim.org/ ##


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 will.
-- 
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 disingenuous.  To be useful the admin configuring Exim
has to write ACL code implementing the per-user filters.

I accept that it would publish the facility more widely, perhaps
encouraging the big providers to also implement it.  I'm dubious
if they listen to anything though.

There is a small amount of boilerplate ACL code which I can add
to the example config provided with the Exim distribution.  Perhaps
that will encourage packagers (eg. Debian) to consider supporting
PRDR.  Unfortunately, deciding what you want to support with per-
user filters is not a small task.
-- 
Cheers,
  Jeremy

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


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 http://www.exim.org/ ##


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

There aren't any specific tests in the regression suite for TLS1.3 -
but I did have to force a few tests to use 1.2 and make other tolerant
of 1.3-specific output in logs etc.  I think only OpenSSL builds
showed up needing such changes though.

At least we know OpenSSL builds have been seen to talk 1.3 - mail me
offlist if you want to use one of my systems as a target.
-- 
Cheers,
  Jeremy


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


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 "should be" could be relaxed slightly, maybe, since it isn't
required by Exim's parsing.  "It is simplest to", perhaps?


I see you quietly removed prdr.  Has it been seen to cause problems?


On multi_domain - some really stupid hosts (hi, Google!) can't handle
it, and will _always_ temp-reject any RCPT after the first domain
(G gives an explicit text error saying it can't hack it).

-- 
Cheers,
  Jeremy

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


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 anymore but a different value.

Phil - that went in at 26739076ae in the example config; could you
comment?
-- 
Thanks,
  Jeremy

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


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 is
> 
> gcc -DMACRO_PREDEF malware.c
> malware.c:52:2: error: empty enum is invalid
>   } scanner_t;

Thanks for the report; the next RC will have a dummy enum value added
just before that line.

> Getting the following error when disabling the complete WITH_CONTENT_SCAN 
> setting.
> 
> main option "spamd_address" unknown

I can't duplicate this.  Possibly you need a "make clean" before that
"make" ?
-- 
Cheers,
  Jeremy

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


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
> https://git.exim.org/buildfarm-client.git/commitdiff/0ce98df83e53cc21a25d98f95e431803a398742c

The code addition looks reasonable on the surface.  Go head and
push it to master.

I'm not going to spend time trying to duplicate your work...
An additional comment in the template, saying exactly what
syntax is needed, would be good.

I'm not going to spend time trying to duplicate your work...
once you're up and running, a potted recipe would be
useful for posterity.  I can't guess how you managed
to do a main exim build without those headers... presumably
you're not limiting yourself to a no-ssl exim (if so,
perhaps we need a no-ssl testsuite build option).
-- 
Cheers,
  Jeremy

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


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 originator)?
-- 
Cheers,
  Jeremy

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


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
scope for "oops!".


Doing it as an option would look like ${strlen/utf8:...}
modulo choice of the option separator.  We don't currently
have any expansion operators that use options, which is
a mark against going that way.
-- 
Cheers,
  Jeremy

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


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 currently work (barring bugs).
-- 
Cheers,
  Jeremy



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


[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 permits variable declaration embedded in "for"
statements, eg:

for (int i = 0; ...) { ... }


Ref:
   6.8.5  Iteration statements

   Syntax

   iteration-statement:
   while ( expression ) statement
   do statement while ( expression ) ;
   for ( expr-opt ; expr-opt ; expr-opt ) statement
   for ( declaration ; expr-opt ; expr-opt ) statement


I'm tempted by that one.

I severely dislike C++ - style one-line comments:   code // comment.
I don't like mixing declarations with code.

Other possibilities mentioned include:
- variadic macros
- compound declarations:  function((struct x) {1, 2})


Comments?
-- 
Cheers,
  Jeremy

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


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.1
>>  Query:
>>cname.example. IN MX ?
>>  Response:
>>Answers:
>>  cname.example. IN CNAME nomx.example.
> 
> OK, that's what I'd expect, from this you can conclude
> that "nomx.example" has no MX records.

With a retry count of one, and the current coding, it failed
when it hit that case.  It was far simpler to loop once than
try to rewrite all the code.
-- 
Jeremy


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


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:
> cname.example. IN CNAME cname2.example.
> cname2.example. IN CNAME nomx.example.
> nomx.example. IN A 192.0.2.1
>   Query:
> cname.example. IN MX ?

That was not the situation that forced the 1-retry.

It was:

  Zone:
cname.example. IN CNAME nomx.example.
nomx.example. IN A 192.0.2.1
  Query:
cname.example. IN MX ?
  Response:
Answers:
  cname.example. IN CNAME nomx.example.

-- 
Cheers,
  Jeremy

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


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 using a "ports" system like the
> BSDs.

No. It's only a git branch; no releases are built using it.
-- 
Cheers,
  Jeremy

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


[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 wanting to keep abreast
of fixes as they arrive but not at the bleeding-edge.
-- 
Cheers,
  Jeremy

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


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

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


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 conditional logic,
> especially since we already ignore most of the TLS options once DANE is
> in play anyway.
> 
> I wrote code for OpenSSL and GnuTLS and tested compilation with OpenSSL.
> 
> I wrote docs.  I did not write tests, I'm way out of practice on the
> Exim test suite.
> 
> Pushed to dane_require_tls_ciphers in the main git repo.

The coding is nicely selfcontained, and at a quick glance should do
the job.

I'm unsure about the philosophy of the interface; having one option
override another.  You mentioned "complex expansions" before in the
discussion but without detail.  I assume that's the same consideration
as "lots of conditional logic" above.  Was that discarding the solution
of dnsdb-lookup expansions selecting values for the original
tls_require_ciphers option?


> Jeremy, does this look mergeable/sane?  Did we get as far as pre-merge
> testing at any point, rather than post-merge testing?

I'd prefer testing was in place before merge if at all possible.
Certainly in place before it hits a release.

> What sort of coverage do we need from tests?  It's honestly going to be
> faster if someone else writes them

I'll have a go, planning to push into the dane_require_tls_ciphers
branch.
-- 
Cheers,
  Jeremy


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


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 we need
>> a specific check early in the build?
> 
> I think it was compile-time, but am not 100% sure.  I did also have a
> link-time failure, but that was my fault and led to my commit to
> openssl.txt: the EXPERIMENTAL_DMARC coming above the TLS config meant
> that using `LDFLAGS=` instead of `LDFLAGS+=` stomped on the DMARC
> library.  Oops.
> 
> Shame there's no `.pc` file for opendmarc.
> 
> Oh: any preferences around OpenSSL 1.1.X for exim.org box?  We currently
> "drink our own champagne" when it comes to advice around OpenSSL
> libraries and deprecation, with 1.0.2n in /opt/openssl/.

Anything "reasonably recent" on the main-use is fine.
Heading towards the bleeding edge is valuable for shaking out
problems, but does mean effort (probably for you).

> I'm tentatively thinking that we can wait for OpenSSL 1.1.1 to reach
> Beta status, then have /opt/openssl111/ for that, and have port-25 Exim
> use 1.0.2 and port-26 Exim use 1.1.1, just skipping 1.1.0 entirely. 

That's fine by me.  We'd want to move the main-use to 1.1.1 after
that went official, and after we'd had enough testing done on the
port-26.

In other news, I finally got DKIM Ed25519 working with 1.1.1 last night.
That code will be in RC2.
-- 
Cheers,
  Jeremy


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


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’ undeclared (first use in this 
> function)
>  if (!ava_re_clean)

Fixed

> malware.c:2156:6: error: ‘fprot6d_re_error’ undeclared (first use in this 
> function)
>  if (!fprot6d_re_error)

Fixed, though my poor eyes cannot actually see the difference that
gitk assures me is there!


>  * While the `DISABLE_DNSSEC=yes` option has the comment `Enabling
>SUPPORT_DANE unconditionally overrides this setting.`, other options
>are "you must have this other thing turned on or build will fail",
>which might be worth reconsidering.

True.  Changed to match the general pattern.

>  Enabling DMARC without enabling
>SPF led to a build failure almost at the very end.

Compile-time or link-time failure?   Do you think we need
a specific check early in the build?

-- 
Cheers,
  Jeremy


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


[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 types.  There is at least
one known bugfix yet to go in.


Files:

SIZE(exim-4.91_RC1.tar.bz2)= 1905117
SIZE(exim-4.91_RC1.tar.gz)= 2399530
SIZE(exim-4.91_RC1.tar.xz)= 1738460
SIZE(exim-html-4.91_RC1.tar.bz2)= 491621
SIZE(exim-html-4.91_RC1.tar.gz)= 719308
SIZE(exim-html-4.91_RC1.tar.xz)= 486612
SIZE(exim-pdf-4.91_RC1.tar.bz2)= 1999605
SIZE(exim-pdf-4.91_RC1.tar.gz)= 2026935
SIZE(exim-pdf-4.91_RC1.tar.xz)= 1967968
SIZE(exim-postscript-4.91_RC1.tar.bz2)= 1073363
SIZE(exim-postscript-4.91_RC1.tar.gz)= 1443043
SIZE(exim-postscript-4.91_RC1.tar.xz)= 1068324

SHA256(exim-4.91_RC1.tar.bz2)= 
05b5285281db672139650a79abce0d410c8a7a59e5102fe149e4e713f820f7f6
SHA256(exim-4.91_RC1.tar.gz)= 
dd7ef29a5679df1cd2cae8d171313e3f7f3dd88a30f0a4454db5ccf3d04b
SHA256(exim-4.91_RC1.tar.xz)= 
1645298c448d26b537da740f4afc51c6a138138e561686954e8bf96f2f3f532e
SHA256(exim-html-4.91_RC1.tar.bz2)= 
c5338f6acb0bca6b1258b70e6917a1d1cc882e981a54f8256ab7cf4c1f539aa5
SHA256(exim-html-4.91_RC1.tar.gz)= 
7268af8ae75ffbd243a7a15ab2d6dd7731039b1bb5f798347630629aedc8d1ff
SHA256(exim-html-4.91_RC1.tar.xz)= 
7f3d8e1b9c88af5ee5b12e505bbb1bb7ca97faeb53af02b11174064dd0f5d45a
SHA256(exim-pdf-4.91_RC1.tar.bz2)= 
ff1fc30f0502d4903b28e4d860b22d4fecfc16c56c2861b5921bfbe296b307d0
SHA256(exim-pdf-4.91_RC1.tar.gz)= 
a56eb43904c5e042b4fc38dfb23a6580a275ba97af3602e0c44a14d42c2a1746
SHA256(exim-pdf-4.91_RC1.tar.xz)= 
a96d01bbf6b933c8bf2b9ec9f906ebaae49cfffefd3868f50a0d2667f32d5779
SHA256(exim-postscript-4.91_RC1.tar.bz2)= 
dd5030776404b6351e43a233081dce765bfc75fd57836925117fbfdb0b89089a
SHA256(exim-postscript-4.91_RC1.tar.gz)= 
3432c8768ff46baf359c46bfcbf846aab230f9b633ba7d626b1d1de0a3d03912
SHA256(exim-postscript-4.91_RC1.tar.xz)= 
c3ec7199777a8f7eb80d02d1ed5d2ba5aa95f54a0942d5f1948aa468c816d877

- -- 
Cheers,
  Jeremy
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEqYbzpr1jd9hzCVjevOWMjOQfMt8FAlqq5k4ACgkQvOWMjOQf
Mt9wAAf/X0rL9CjATpsM9ZIVPvVF94yGF2q9oosnWuo2/0Dtri5ACLi1KNl7WoPY
x40C+SDrxTSqK8s//796wg3gMDVhEuXulp1rQ7CoKl4sWw4r3OY08XJz75tdCsVI
weaFzpW3GNDqXGTQk/IW6hBg6+8W4HvQ1ci/4vV7HXj/8Ua5A63yZq/ZeVaUmz29
AQrDsJ0zj496HNiG0ixEpVB3CszW1vs0KXbKWnlkdBAC7HcZsGzIXl0eCmuADZ+w
SRjgkmt++ZGMAYbUgvR2jV5+w6fIchmxWrYDQN9PC4QoO0bf+ABBkaudorgGnQvX
4SXk/F5GnyH22Ug+AEWxDmYuC1wvaA==
=w2KV
-END PGP SIGNATURE-

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


[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 test the Release Candidates.  Production use is sometime
the only way bugs get found.

Developers: please check Bugzilla for the bugs assigned to you,
and make commits as needed.  Also assess your work-in-progress;
anything which you think needs a full release-cycle of soaking
should be pushed into the 4,next branch rather than the mainline.
I just synced 4.next, and enabled it in the buildfarm.



(You can skip the rest of this message if you don't care about
what's been done since the last release of Exim)



The current NewStuff file reads:

Version 4.91
- --

 1. Dual-certificate stacks on servers now support OCSP stapling, under GnuTLS
version 3.5.6 or later.

 2. DANE is now supported under GnuTLS version 3.0.0 or later.  Both GnuTLS and
OpenSSL versions are moved to mainline support from Experimental.

 3. Feature macros for the compiled-in set of malware scanner interfaces.

 4. SPF support is promoted from Experimental to mainline status.  The template
src/EDITME makefile does not enable its inclusion.

 5. Logging control for DKIM verification.  The existing DKIM log line is
controlled by a "dkim_verbose" selector which is _not_ enabled by default.
A new tag "DKIM=" is added to <= lines by default, controlled by
a "dkim" log_selector.

 6. Receive duration on <= lines, under a new log_selector "receive_time".

 7. Options "ipv4_only" and "ipv4_prefer" on the dnslookup router and on
routing rules in the manualroute router.

 8. Expansion item ${sha3:} / ${sha3_:} now also supported
under OpenSSL version 1.1.1 or later.

 9. DKIM operations can now use the Ed25519 algorithm in addition to RSA, under
GnuTLS 3.6.0 or later.

10. Builtin feature-macros _CRYPTO_HASH_SHA3 and _CRYPTO_SIGN_ED25519, library
version dependent.

11. "exim -bP macro " returns caller-usable status.

12. Expansion item ${authresults {}} for creating an
Authentication-Results: header.

13. EXPERIMENTAL_ARC.  See the experimental.spec file.

14: A dane:fail event, intended to facilitate reporting.


The ChangeLog file reads:

GF/01 DEFER rather than ERROR on redis cluster MOVED response.
 When redis_servers is set to a list of > 1 element, and the Redis servers
 in that list are in cluster configuration, convert the REDIS_REPLY_ERROR
 case of MOVED into a DEFER case instead, thus moving the query onto the
 next server in the list. For a cluster of N elements, all N servers must
 be defined in redis_servers.

JH/01 Replace the store_release() internal interface with store_newblock(),
  which internalises the check required to safely use the old one, plus
  the allocate and data copy operations duplicated in both (!) of the
  extant use locations.

JH/02 Disallow '/' characters in queue names specified for the "queue=" ACL
  modifier.  This matches the restriction on the commandline.

JH/03 Fix pgsql lookup for multiple result-tuples with a single column.
  Previously only the last row was returned.

JH/04 Bug 2217: Tighten up the parsing of DKIM signature headers. Previously
  we assumed that tags in the header were well-formed, and parsed the
  element content after inspecting only the first char of the tag.
  Assumptions at that stage could crash the receive process on malformed
  input.

JH/05 Bug 2215: Fix crash associated with dnsdb lookup done from DKIM ACL.
  While running the DKIM ACL we operate on the Permanent memory pool so that
  variables created with "set" persist to the DATA ACL.  Also (at any time)
  DNS lookups that fail create cache records using the Permanent pool.  But
  expansions release any allocations made on the current pool - so a dnsdb
  lookup expansion done in the DKIM ACL releases the memory used for the
  DNS negative-cache, and bad things result.  Solution is to switch to the
  Main pool for expansions.
  While we're in that code, add checks on the DNS cache during store_reset,
  active in the testsuite.
  Problem spotted, and debugging aided, by Wolfgang Breyha.

JH/06 Fix issue with continued-connections when the DNS shifts unreliably.
  When none of the hosts presented to a transport match an already-open
  connection, close it and proceed with the list.  Previously we would
  queue the message.  Spotted by Lena with Yahoo, probably involving
  round-robin DNS.

JH/07 Bug 2214: Fix SMTP responses resulting from non-accept result of MIME ACL.
  Previously a spurious "250 OK id=" response was appended to the proper
  failure response.

JH/08 The "support for" informational output now, which built with Content
  Scanning 

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 between 4.89.1
and 4.90.1 so you don't need to bisect the whole world?
-- 
Cheers,
  Jeremy

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


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 want me to write up a patch and submit it to the bug tracker.
> 
> I guess I should because that way I can include updates to the
> documentation.

Yes please.  On the name, my arguments would be that a TCP-level
timeout would have a name starting "tcp" (we already have tcp:connect
and tcp:close)... but it doesn't matter too much.  Your original
is fine (and leaves other possibilities open).
-- 
Cheers,
  Jeremy

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


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 useful for trusted path checking.
>>
>> It's more of a mmailinglist-software thing than an MTA thing,
>> I think.
> 
> I'll modify that.  It's a mailinglist thing as regards generation;
> but the final receiving MTA wants a checking implementation.
> 
> The latter is where Exim might want to provide support.

I started work on an implementation.  Anyone out there
interested in testing interoperability?  Please contact me.
-- 
Cheers,
  Jeremy

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


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);
> 
> (line 901 in the current github master)
> 
> Is this enhancement accetpable to the exim maintainers? 

Having one is fine.  They're simple to add once you've
found the right place in the code.

> Have I chosen a suitable event name?

Why not just "msg:rcpt:timeout" ?  What distinction were
you implying?

-- 
Cheers,
  Jeremy

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


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, so long as we're assured that the definition
of the base-64 method being used in the two cases is the same.
I think there's more than one alphabet in common use, for different
purposes...  But if this turns out to be the case, perhaps a merged
routine could handle either.

Some microbenchmarking wouldn't go amiss, along with the usual
regression testing.
-- 
Cheers,
  Jeremy

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