Re: [exim-dev] [Bug 2972] New: ACL check "!verify = reverse_host_lookup" gives error
On 2023-01-12, admin--- via Exim-dev wrote: > > The error was: > [2/2] error in ACL: "=" missing after ACL "verify" condition > [1\2] 2023-01-12 16:53:36.247 [18255] Exim configuration error in line 137 of > /etc/mail/exim.conf: > error in ACL: "=" missing after ACL "verify" condition And it's definately that line? This command: cat -n /etc/mail/exim.conf | grep '^ *1[34][0-9]\W' shows that line as 137? > So this is weird to me. Am I blind and can't spot my own error? Sorry for the > noise, if so. Maybe there could be some non-printing, or other unusual, characters on that line, UTF-8 is both a blessing and a curse, maybe re-typing the line from scratch will fix it. -- Jasen. pǝsɹǝʌǝɹ sʇɥƃᴉɹ ll∀ -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] notdef_crashes in tls-gnu.c
the code in src/src/tls-gnu.c disabled by # ifdef notdef_crashes seems to rhyme with the other code that was recently changed (support for tls 1.1 with not extensions, coimmit: ece23f05d6 ) could it be the same problem, and the same solution? -- Jasen. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp
On 2021-10-22, Viktor Dukhovni via Exim-dev wrote: >> On 22 Oct 2021, at 11:45 am, admin--- via Exim-dev wrote: >> >> For what it's worth, by experience, you should avoid sending anything to any >> yahoo domains using pipelining. They will just retaliate on you if you do it, >> they will, for example, greylist the servers using pipelining but will allow >> the other ones. >> If this is really an exim bug, it's still worth correcting it, but you should >> really disable pipelining to yahoo, even when this bug will be resolved. > > Why would they bother advertising PIPELINING, if they don't > actually mean to tolerate its use? That does not seem right... > BINARYMIME RFC3030 (https://datatracker.ietf.org/doc/html/rfc3030#section-4.2) doesn't show pipelined BDAT: the sender synchronises before sending body data. Dropping the connection seems like a resonable response to such a synchronisation error. PIPELINING RFC2920 (https://datatracker.ietf.org/doc/html/rfc2920) synchrionises the pipeline before any message content is trasmitted (the "DATA" command is allowed but the sender must wait for "354" before sending content) -- Jasen. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] servers expansion
On 2021-06-12, Jeremy Harris via Exim-dev wrote: > On 12/06/2021 20:56, Andrew C Aitchison via Exim-dev wrote: >> On Sat, 12 Jun 2021, Jasen Betts via Exim-dev wrote: >>> I'm wanting to be able to use expansion variables in the servers= >>> parameter of query-style lookups. > > This immediately sounds dangerous. It can't use tainted values, so the value will be untainted data like the result of some lookup or arithmetic. > [suggested code change] > >>> This seems to work for simple variables which is enough for me. Full >>> brace expansion does not work (I think the parser gets confused). >>> >>> As I understand it this is not going to cause a memory leak. >>> >>> a few lines down from this serverlist is checked to be taint-free so >>> this feels safe to me. >> >> Isn't the idea to check a string is taint-free *before* expanding it ? > > Precisely. Consider what an attacker might present you with to get > expanded, and the extensive facilities that Exim expansion offers. Isn't the value computed and then checked for taint before the dangerous thing is done. In this case the dangerous thing using the servers setting to connect to and to query a variable server. The check is on line 161 if (is_tainted(server)) -- Jasen. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] servers expansion
On 2021-06-12, Andrew C Aitchison via Exim-dev wrote:
> On Sat, 12 Jun 2021, Jasen Betts via Exim-dev wrote:
>
>>
>> I'm wanting to be able to use expansion variables in the servers=
>> parameter of query-style lookups.
>>
>> I can use variables if I put servers= inside the query, but if
>> servers= is used there I can't use tainted variables in the query.
>>
>> I crawled around looking at the source code trying to
>> backtrace to the caller code and finally came up with this patch:
>>
>> --- a/build/exim/src/lookups/lf_sqlperform.c
>> +++ b/build/exim/src/lookups/lf_sqlperform.c
>> @@ -129,7 +129,7 @@ else
>> uschar * ele;
>> for (int sep = ','; ele = string_nextinlist(, , NULL, 0); )
>> if (Ustrncmp(ele, "servers=", 8) == 0)
>> - { serverlist = ele + 8; break; }
>> + { serverlist = expand_string( ele + 8 ); break; }
>> }
>>
>> if (!serverlist)
>> ---
>>
>> This seems to work for simple variables which is enough for me. Full
>> brace expansion does not work (I think the parser gets confused).
>>
>> As I understand it this is not going to cause a memory leak.
>>
>> a few lines down from this serverlist is checked to be taint-free so
>> this feels safe to me.
>
> Isn't the idea to check a string is taint-free *before* expanding it ?
If the expansion being done is a safe expansion then the taintness is
preserved and the checking is deferred until a dangerous expansion is
encountered. (this is AIUI done by some sort of pointer magic)
Variable substitution is taint-preserving so if tainted data
is used in the servers parameter it will be rejected by the test.
(because servers is rightly considered dangerous)
--
Jasen.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
[exim-dev] servers expansion
I'm wanting to be able to use expansion variables in the servers=
parameter of query-style lookups.
I can use variables if I put servers= inside the query, but if
servers= is used there I can't use tainted variables in the query.
I crawled around looking at the source code trying to
backtrace to the caller code and finally came up with this patch:
--- a/build/exim/src/lookups/lf_sqlperform.c
+++ b/build/exim/src/lookups/lf_sqlperform.c
@@ -129,7 +129,7 @@ else
uschar * ele;
for (int sep = ','; ele = string_nextinlist(, , NULL, 0); )
if (Ustrncmp(ele, "servers=", 8) == 0)
- { serverlist = ele + 8; break; }
+ { serverlist = expand_string( ele + 8 ); break; }
}
if (!serverlist)
---
This seems to work for simple variables which is enough for me. Full
brace expansion does not work (I think the parser gets confused).
As I understand it this is not going to cause a memory leak.
a few lines down from this serverlist is checked to be taint-free so
this feels safe to me.
--
Jasen.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2368] Exim 4.91-RC4 compile warning for unused result
On 2019-02-02, Andrew C Aitchison via Exim-dev wrote: > On Sat, 2 Feb 2019, admin--- via Exim-dev wrote: > >> https://bugs.exim.org/show_bug.cgi?id=2368 >> >> Jeremy Harris changed: >> >> What|Removed |Added >> >> Resolution|--- |WONTFIX >> Assignee|ni...@exim.org |jgh146...@wizmail.org >> Status|NEW |RESOLVED >> >> --- Comment #1 from Jeremy Harris --- >> This is a matter for choosing compiler switches to avoid doing such static >> analysis. We refuse to endlessly chase such things by using more-and-more >> convoluted coding. Even the cast-to-void could be regarded as such an >> attempt, but it least its heritage goes back over thirty years. > This patch makes the code clearer, > and makes it explicit that we know what we are doing. > If it makes that the compiler happy at the same time, > then we can leave the switches set in a way that helps us avoid writing > new bugs. If the optimizer does not spot it you have code that wastes resources (albeit a small amount in this case). Also now you have two variables that are assigned a value which is not used: this is potentially another static analysis violation. (gcc would find that at optimisation level 2 last time I checked) casting the function result to void is the traditional way to silence the unused return value warnings: /* ignoring the return values here because nothing can be done if this fails */ (void) write(fd, process_info, process_info_len); (void) close(fd); -- When I tried casting out nines I made a hash of it. -- ## 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
On 2018-12-16, Phil Pennock via Exim-dev wrote: > On 2018-12-16 at 10:42 +, Jeremy Harris via Exim-dev wrote: >> On 16/12/2018 10:20, Andreas Metzler via Exim-dev wrote: >> > 4.92rc1 adds this to the smarthost_smtp transport: >> > >> > tls_sni = $host What does DANE say we shoud ask for? I remember it being non-obvious but easily explained. However I don't however remember the detail. -- When I tried casting out nines I made a hash of it. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2341] delay_warning failing to send messages
On 2018-12-05, Andrew C Aitchison via Exim-dev wrote: > On Wed, 5 Dec 2018, admin--- via Exim-dev wrote: > >> https://bugs.exim.org/show_bug.cgi?id=2341 >> >> --- Comment #8 from Jeremy Harris --- >> Thanks. It seems I'm on the right track; now we need to decide if that is >> now too much notification... there's no per-sender tracking on this, it's >> per-deferred message, so (as in your test) one sender will get a warning >> for every message they send, repeated per the delay_warning setting >> as modified by the queue run occasions. >> >> Leaving it like that will be simplest. I'll commit that for now, but >> opinions >> on any need for additional control are welcom. > > Like David, I'd expect and want a message for every delayed message. > > However, if someone malicious finds a full mailbox, could they use it > to amplify attacks on a third party ? > On the face of it, sending an almost null message to the full mailbox > could result in larger messages being sent to an innocent third-party. > What happens when a message with multiple senders (is that reply-to or from) > is delayed; does each one get a delay warning ? > > [ Am I giving too many hints to spammers by asking in a public list ? ] NDRs go to the envelope sender, so they will bounce back to a single address (per message), but there can be several "delayed" messages and a single bounce (retry timeout exceeded) for each input, so that provides small-scale amplification, until the timeout is reached, after that no amplification. where available SPF is one mitigation for this. It prevents the attacker from forging the sender address. -- When I tried casting out nines I made a hash of it. -- ## 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
On 2018-08-17, 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
Yeah stay with treating srings as nul terminated arrays of octets.
The same unit the RFCs use to define email and SMTP.
> and add ulength_1 for being UTF-8 aware?
Would also need utf8-aware also substr and strlen.
is it going to count code-points or glyphs?
> Look at the top-bit being set and assume UTF-8, or
> will that break too much with all the places which are still ISO-8859-1?
Just looking at that bit won't tell you enough to count code-points or
glyphs. you need to then group the octets together, and you need to do
something when you hit a non-valid octet
parts of ${utf8clean can probably be re-used.
"${lc" "${uc" and "${if eqi" need consideraton too
--
ت
--
## 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
On 2018-02-20, Jeremy Harris via Exim-dev <exim-dev@exim.org> wrote: > 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. Yeah! I thought perhaps I'd need to mess around initialising variables for use in expansions, but after adding that one line everything just worked :) >> Have I chosen a suitable event name? > > 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. -- This email has not been checked by half-arsed antivirus software -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] delivery event for retry timeout
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? Have I chosen a suitable event name? Jasen. -- This email has not been checked by half-arsed antivirus software -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
