Re: [exim] IPv6 in route_data and route_list
Please note that I am now no longer subscribed to this list. Please copy replies to me if you wish me to see them. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] IPv6 in route_data and route_list
On Thu, May 28, 2020 at 11:38:19AM +0200, Hendrik Meyburgh via Exim-users wrote:
> Hahaha, tried again.
>
>
> Testing e...@gmail.com
>
> Considering e...@gmail.com
> >>>
> routing e...@gmail.com
> > backscatter router <
> local_part=echo domain=gmail.com
> checking "condition" "${if and{{bool_lax{${if def:sender_address
> {0}{1{bool_lax{${lookup ldap {USE"...
> backscatter router skipped: condition failure
> > test_router router <
> local_part=echo domain=gmail.com
> calling test_router router
> test_router router called for e...@gmail.com
> domain = gmail.com
> route_item = * <+::0:107:4::583
> gmail.com in "*"? yes (matched "*")
> original list of hosts = ‘<+::0:107:4::583' options = ''
> expanded list of hosts = ‘<+::0:107:4::583' options = ''
> set transport remote_smtp
> finding IP address for ::0:107:4::583
It's treating the IPv6 address as a hostname, so it's trying to look
up "::0:107:4::583" in the DNS to get its IP/IPv6 addresses.
Have you tried an IPv6 literal:
<+[::0:107:4::583]
There is an example in the documentation that shows this:
route_list = * "http://exim.org/exim-html-current/doc/html/spec_html/ch-the_manualroute_router.html#SECID120
--
Russell King
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
On Tue, Apr 28, 2020 at 11:45:31AM +0100, Jeremy Harris via Exim-users wrote:
> On 28/04/2020 11:32, Russell King via Exim-users wrote:
> > I notice you set a Reply-to: header on your messages, were you
> > expecting me to reply to that address, or to the list? I've
> > chosen the list.
>
> I blame Thunderbird. List is preferred, as far as I'm concerned.
I'll try to remember, but I can't guarantee. As I say, all the other
mailing lists I'm on are mandatory reply-to-all, so hitting 'g' in mutt
has been highly ingrained in me over the last 20 years when replying
to mailing list email (and in fact almost all email.)
> > When exim chooses to use one of the addresses that results in
> > the 'REJECT' rule being hit on the firewall, the machine running exim
> > gives a "Permission denied" errno. I can trigger this via:
> >
> > # telnet ::::214:fdff:fe10:1be6 25
> > ...
> > telnet: Unable to connect to remote host: Permission denied
>
> Oh, now _that_ is fun. Exim is merely reporting what the
> OS tells it. If you strace that telnet, is it actually
> the "connect" syscall that returns EPERM? That's the implication
> of the error message.
"Permission denied" is actually EACCES. EPERM is "Operation not
permitted".
But yes, strace returns EACCES for connect().
> The Linux connect(2) mapage offers EPERM for a local firewall
> rule, but yours is remote... I wonder what a packet capture
> shows?
"ICMP6, destination unreachable, unreachable prohibited".
There is a table in the Linux kernel source code in net/ipv6/icmp.c,
tab_unreach[], which maps the ICMPv6 unreachability code to a local
errno:
{ /* ADM_PROHIBITED */
.err= EACCES,
.fatal = 1,
},
It can also map to EACCES for POLICY_FAIL and REJECT_ROUTE
unreachability codes. Its use dates back as far as the modern git
history of the Linux kernel (back to 2.6.12-rc2, so 15 years) at
least.
It seems the connect(2) man page needs to be fixed with respect to
this too (I'll see if that can happen.)
However, it seems this use of EACCES in this way is nonstandard
according to POSIX, and I don't want to start a debate here about
the use of errno codes - it's not up to me.
--
Russell King
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
On Tue, Apr 28, 2020 at 11:38:04AM +0100, Jeremy Harris via Exim-users wrote: > On 28/04/2020 11:17, Andrew C Aitchison via Exim-users wrote: > > > > On 27/04/2020 20:52, Russell King via Exim-users wrote: > >> 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf <= pat...@.armlinux.org.uk > > U=patchd P=local S=1535 > >> 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf H=pandora.armlinux.org.uk > > [::::214:fdff:fe10:1be6] Permission denied > >> 2020-04-27 20:36:17 1jT9Y7-0003B4-Mf => u...@example.com R=smart_route > > T=remote_smtp H=pandora.armlinux.org.uk > > [::::214:fdff:fe10:1be6] > > X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes A=fixed_cram C="250 OK > > id=1jT9Y8-0004ff-Qf" > >> > >> My guess is that there is some file that exim can't access while > >> attempting to send to pandora, but I think working out what is > >> going to be very hard (I guess debug isn't allowed from non-root > >> users?) > > > > ... and followed up with: > >> and grepping the strace output for errors: > >> > >> 19841 openat(AT_FDCWD, "/var/spool/exim4//input//1jTM7j-0005A1-Na-D", > >> O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0640) = -1 EACCES (Permission denied) > > On today's non-Unix "selinux" systems, you need to also worry > about the mostly-invisible marks placed on files... Turning selinux > to "permissive" may be a useful and quick test. True, but not applicable in my situation; the host is not using selinux. In any case, I've fixed the firewall, and now that address no longer gives EACCES. Thanks for the pointer. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
On Tue, Apr 28, 2020 at 11:17:09AM +0100, Andrew C Aitchison wrote: > > On 27/04/2020 20:52, Russell King via Exim-users wrote: > >2020-04-27 20:36:15 1jT9Y7-0003B4-Mf <= pat...@.armlinux.org.uk > U=patchd P=local S=1535 > >2020-04-27 20:36:15 1jT9Y7-0003B4-Mf H=pandora.armlinux.org.uk > [::::214:fdff:fe10:1be6] Permission denied > >2020-04-27 20:36:17 1jT9Y7-0003B4-Mf => u...@example.com R=smart_route > T=remote_smtp H=pandora.armlinux.org.uk > [::::214:fdff:fe10:1be6] > X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes A=fixed_cram C="250 OK > id=1jT9Y8-0004ff-Qf" > > > >My guess is that there is some file that exim can't access while > >attempting to send to pandora, but I think working out what is > >going to be very hard (I guess debug isn't allowed from non-root > >users?) > > ... and followed up with: > >and grepping the strace output for errors: > > > >19841 openat(AT_FDCWD, "/var/spool/exim4//input//1jTM7j-0005A1-Na-D", > >O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0640) = -1 EACCES (Permission denied) > >19841 openat(AT_FDCWD, "/var/log/exim4/mainlog", > >O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied) > >19841 openat(AT_FDCWD, "/var/log/exim4/paniclog", > >O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied) > > > >So we're not getting anywhere near delivery (which is where the permission > >denied error is happening). > > Are you sure that the permission denied error is happening near delivery ? > The timestamps suggest that the permission denied is nearer message input > (<=) than delivery (=>). I'm quite sure that it's delivery - see my reply to Jeremy, where the problem has now been located, and you will likely be surprised by its cause. It has nothing to do with local file permissions at all! *Sigh* the reply-to-list thing gets me again, and I'm getting fed up with having to re-edit the headers or rewrite the reply each time I reply to an email on this mailing list. Reply-to-list is just too foreign to me, being a kernel developer where reply-to-all is mandatory. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
Hi Jeremy, I notice you set a Reply-to: header on your messages, were you expecting me to reply to that address, or to the list? I've chosen the list. On Tue, Apr 28, 2020 at 10:23:56AM +0100, Jeremy Harris via Exim-users wrote: > On 28/04/2020 08:12, Russell King via Exim-users wrote: > > On Mon, Apr 27, 2020 at 09:11:18PM +0100, Jeremy Harris via Exim-users > > wrote: > >> On 27/04/2020 20:52, Russell King via Exim-users wrote: > >>> I'm running debian stable on my machines, and I've noticed that when > >>> one of my scripts sends email, > >> > >> I'm hoping that means you can trigger it on demsnd? > > > > I believe so - exim is being called from a perl script running as the > > user stated in the log line thusly: > > > > /usr/sbin/sendmail -oi -t > > Ah. I was assuming the message came to the daemon using SMTP. > > So, to handle a commandline message with debug > add near the top of your nonsmtp-data acl > >warn control = debug/opts=+all Thanks, I put it in the acl_not_smtp_start ACL instead, which seems to have worked as far as getting a debug log. However, I have some bad news. I've spent quite some time trying to track it down - what I can say is that it isn't a file permission problem, but a network-induced issue. (I now have a mailbox full of a hundred or so test messages to delete!) As I mentioned, there are several IPv6 addresses for pandora - and it seems I haven't permitted them all in the firewall rules facing the DMZ. When exim chooses to use one of the addresses that results in the 'REJECT' rule being hit on the firewall, the machine running exim gives a "Permission denied" errno. I can trigger this via: # telnet ::::214:fdff:fe10:1be6 25 ... telnet: Unable to connect to remote host: Permission denied Note: the firewall and the machine running exim are two entirely separate machines; they are not on the same machine. So, this error can be induced remotely. It would be obvious if it was something like: H=foobar.example.org [10.0.0.1] Connection refused but when it's: H=foobar.example.org [10.0.0.1] Permission denied it's rather confusing exactly what is going on and where that error is coming from. Besides the problems of getting any debug out of it (I think the way you suggested above is the only way to do it), there's another issue as well - the retry database stops exim using those addresses, which means that the more attempts are made, the more exim refrains from triggering the error with larger and larger intervals. So, this has been a particularly nasty and difficult problem to track down. It's probably worth documenting the error message somewhere that people will find it, and listing firewall issues as a potential cause of it. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
On Tue, Apr 28, 2020 at 09:43:31AM +0100, Andrew C Aitchison wrote: > On Tue, 28 Apr 2020, Russell King via Exim-users wrote: > > >On Mon, Apr 27, 2020 at 09:11:18PM +0100, Jeremy Harris via Exim-users wrote: > >>On 27/04/2020 20:52, Russell King via Exim-users wrote: > >>>I'm running debian stable on my machines, and I've noticed that when > >>>one of my scripts sends email, > >> > >>I'm hoping that means you can trigger it on demsnd? > > > >I believe so - exim is being called from a perl script running as the > >user stated in the log line thusly: > > > > /usr/sbin/sendmail -oi -t > > > >>>I get a spurious and unexplained > >>>"Permission denied" error: > > Does changing that to > /usr/sbin/sendmail -oi -t -v > give you any clues ? > > "exim -v" doesnt give as much information as "exim -d" but should > be available as any user. Good suggestion, but alas no: LOG: MAIN <= pat...@.armlinux.org.uk U=patchd P=local S=377 patchd@:~/test$ delivering 1jTMBH-0005BJ-F0 Connecting to pandora.armlinux.org.uk [::::214:fdff:fe10:1be6]:25 ... failed: Permission denied LOG: MAIN H=pandora.armlinux.org.uk [::::214:fdff:fe10:1be6] Permission denied Connecting to pandora.armlinux.org.uk [::::214:fdff:fe10:1be6]:25 ... connected Interestingly, the IPv6 prefix is different on the actual delivery this time around from the line with the error (I have several IPv6 prefixes internally, a 2001: and a private prefix.) > >The protection on setuid processes means that while you can do this: > > > > strace /usr/sbin/sendmail -oi -t > > > >as an unprivileged user, the process will no longer be executed setuid, > >and it definitely will not be able to access a bunch of files (such as > >those giving it the credentials for the smarthost.) > > The output of > strace -f -eopen,openat -o /tmp/exim.strace /usr/sbin/sendmail -oi -t > should be small and include the name of the file that cannot be read > (unless there is another unreadable file that stops exim reaching the > problem access). That gives me: 2020-04-28 10:01:51 1jTM7j-0005A1-Na Failed to create spool file /var/spool/exim4//input//1jTM7j-0005A1-Na-D: Permission denied 2020-04-28 10:01:51 1jTM7j-0005A1-Na Failed to create spool file /var/spool/exim4//input//1jTM7j-0005A1-Na-D: Permission denied 2020-04-28 10:01:51 1jTM7j-0005A1-Na Failed to create spool file /var/spool/exim4//input//1jTM7j-0005A1-Na-D: Permission denied and grepping the strace output for errors: 19841 openat(AT_FDCWD, "/var/spool/exim4//input//1jTM7j-0005A1-Na-D", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0640) = -1 EACCES (Permission denied) 19841 openat(AT_FDCWD, "/var/log/exim4/mainlog", O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied) 19841 openat(AT_FDCWD, "/var/log/exim4/paniclog", O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied) So we're not getting anywhere near delivery (which is where the permission denied error is happening). This is entirely obvious (at least to me with 25+ years experience of Linux kernel, having ported it to the ARM architecture back in the 1990s) because running strace _prevents_ the OS from honouring the setuid bit on exim. I think the *only* way to find this is to build a custom version of exim with the internal security checking for the -d option removed, or to audit the source code. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
On Tue, Apr 28, 2020 at 11:38:28AM +0300, Evgeniy Berdnikov via Exim-users wrote: > On Tue, Apr 28, 2020 at 08:59:58AM +0100, Russell King via Exim-users wrote: > > On Tue, Apr 28, 2020 at 10:38:13AM +0300, Evgeniy Berdnikov via Exim-users > > wrote: > > > Write a wrapper over /usr/sbin/sendmail which should start exim > > > as root and with additional debug flags. > > > > I don't think that will work based on my testing so far. > > > > If exim is started as root, then the problem goes away (which is not > > surprising because root can generally do anything, bypassing file > > permissions.) > > Root obeys file permissions, but generally it have more permissions > than ordinary user. No. root bypasses file permissions: # ls -l testsend -rw--- 1 patchd nogroup 105 Apr 28 08:34 testsend # id uid=0(root) gid=0(root) groups=0(root) # cat testsend From: patchd ... root can read this file, despite not being the owner, and not having "other" mode bits set. To take this to the extreme: # chmod 0 testsend # ls -l testsend -- 1 patchd nogroup 105 Apr 28 08:34 testsend # cat testsend From: patchd ... > > That is the exact problem getting debug in this situation: you need > > exim to be invoked as the user concerned to then drop privileges > > back to an unprivileged user to then trigger the permission denied > > error. However, you can't enable debug. > > Take one minute to think. User runs MTA as "/usr/sbin/sendmail -oi -t", > passing argv[0..2] = ["/usr/sbin/sendmail", "-oi", "-t"]. You have to > replace argv with ["-d+all", "-oi", "-t"] and run exim binary from other > location, where it may stay with setuid bit. No magic here, no need for > special priveleges, it can be done with 2 lines shell script: > > #!/bin/sh > exec /usr/sbin/exim -d+all "$@" > > This script does not ever need to be setuid. While that much is true, it is you who need to think, and actually read my email messages. $ id uid=120(patchd) gid=65534(nogroup) groups=65534(nogroup) $ /usr/sbin/exim -d+all -oi -t < testsend ... 09:52:43 19733 cwd=/usr/local/patches/test 4 args: /usr/sbin/exim -d+all -oi -t exim: debugging permission denied $ As I said, due to the security in exim, you can _not_ use debugging if exim is called from a non-privileged user - it is an option that is denied to the user. The second issue: you can not have setuid scripts on Linux. Yes, you can set the setuid bit on a script, but the kernel will not honour it. If you don't believe me, try running this script as a normal user with the script setuid root on Linux: #!/bin/sh id "id" will tell you that the script is not running root. So, an all three points you've raised, you are very much mistaken and it seems you're confused. Thanks anyway. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
On Tue, Apr 28, 2020 at 10:38:13AM +0300, Evgeniy Berdnikov via Exim-users wrote: > On Tue, Apr 28, 2020 at 08:12:30AM +0100, Russell King via Exim-users wrote: > > I believe so - exim is being called from a perl script running as the > > user stated in the log line thusly: > > > > /usr/sbin/sendmail -oi -t > ... > > > If you have root, the moral equivalent of > > > > > > # service exim stop && exim -d+all -bd 2>&1 | tee log > > > ... > > > ctrl-c > > > # service exim start > > > # less log > > > > How does that help when the process that accepted the message and > > delivered it was started by the user concerned, and the message > > was not handled by the daemonised exim? > > Write a wrapper over /usr/sbin/sendmail which should start exim > as root and with additional debug flags. I don't think that will work based on my testing so far. If exim is started as root, then the problem goes away (which is not surprising because root can generally do anything, bypassing file permissions.) That is the exact problem getting debug in this situation: you need exim to be invoked as the user concerned to then drop privileges back to an unprivileged user to then trigger the permission denied error. However, you can't enable debug. If you run exim as root, it doesn't seem to do that, so the error doesn't occur, but you can enable debug. > > Due to the implemented security on setuid processes started by non-root > > users, I don't think I can. > > If you have root access to this machine, you can do anything. > If you are not, just delegate this work to sysadmin. Respectfully, I don't think you've thought about the problem. How do I start exim as a user, get it's PID, to then launch a strace session from the root shell before the process finishes? It takes less than a second between the message being submitted and the error occurring. The protection on setuid processes means that while you can do this: strace /usr/sbin/sendmail -oi -t as an unprivileged user, the process will no longer be executed setuid, and it definitely will not be able to access a bunch of files (such as those giving it the credentials for the smarthost.) I've tried setting hold_domains in the exim config file, submitting a test message as the unprivileged user, then manually running a delivery (exim -d+all -M ) as root, and, as expected, there is no permission denied error _because_ it's being executed as root, and "root can do anything". -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Spurious permission denied error
On Mon, Apr 27, 2020 at 09:11:18PM +0100, Jeremy Harris via Exim-users wrote: > On 27/04/2020 20:52, Russell King via Exim-users wrote: > > I'm running debian stable on my machines, and I've noticed that when > > one of my scripts sends email, > > I'm hoping that means you can trigger it on demsnd? I believe so - exim is being called from a perl script running as the user stated in the log line thusly: /usr/sbin/sendmail -oi -t > > I get a spurious and unexplained > > "Permission denied" error: > > > > 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf <= pat...@.armlinux.org.uk > > U=patchd P=local S=1535 > > 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf H=pandora.armlinux.org.uk > > [::::214:fdff:fe10:1be6] Permission denied > > > My guess is that there is some file that exim can't access while > > attempting to send to pandora, but I think working out what is > > going to be very hard (I guess debug isn't allowed from non-root > > users?) > > If you have root, the moral equivalent of > > # service exim stop && exim -d+all -bd 2>&1 | tee log > ... > ctrl-c > # service exim start > # less log How does that help when the process that accepted the message and delivered it was started by the user concerned, and the message was not handled by the daemonised exim? Running the daemonised exim with debug enabled clearly is not going to help in this instance. > > However, there's a general principle of error reporting here: > > shouldn't error messages contain some hint as to what is being > > done when the error was encountered? > > I agree, and that's bugworthy. Please get debug output so > we can locate where in processing it is; that should help > find the problem coding. Due to the implemented security on setuid processes started by non-root users, I don't think I can. See above, and my initial message where I also explained why that is not possible. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Spurious permission denied error
Hi, I'm running debian stable on my machines, and I've noticed that when one of my scripts sends email, I get a spurious and unexplained "Permission denied" error: 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf <= pat...@.armlinux.org.uk U=patchd P=local S=1535 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf H=pandora.armlinux.org.uk [::::214:fdff:fe10:1be6] Permission denied 2020-04-27 20:36:17 1jT9Y7-0003B4-Mf => u...@example.com R=smart_route T=remote_smtp H=pandora.armlinux.org.uk [::::214:fdff:fe10:1be6] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes A=fixed_cram C="250 OK id=1jT9Y8-0004ff-Qf" My guess is that there is some file that exim can't access while attempting to send to pandora, but I think working out what is going to be very hard (I guess debug isn't allowed from non-root users?) Sure enough, trying it results in: exim: debugging permission denied However, there's a general principle of error reporting here: shouldn't error messages contain some hint as to what is being done when the error was encountered? Given that -d+all can't be used in this case, and the binary can't be straced (because it's set-uid), IMHO the only way to track this down is for that general principle to be adhered to by the exim code base. As this doesn't seem to be causing a problem, it's not something I care about, but I thought I would bring it to people's attention. Thanks. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] exim doesn't seem to properly clean up after exhausing spool space
Hmm, so seems like there's no interest in this bug report? On Sat, Dec 14, 2019 at 05:11:32PM +, Russell King via Exim-users wrote: > Hi, > > It seems that exim doesn't properly clean up after a failure to write > to its message queue, but ends up leaving what it has written in the > spool and other directories. > > The sending server (exim) reported: > > 2019-12-14 12:53:58 1ig6vR-0003NP-2l <= r...@flint.armlinux.org.uk U=rmk > P=local S=14483755 id=@gmail.com > 2019-12-14 12:54:28 1ig6vR-0003NP-2l H=mail.armlinux.org.uk > [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after end of > data: 451 Temporary local problem - please try later > > after it tried to deliver a message, because mail.armlinux.org.uk ran > out of space (oops.) A 14MB email tends to be the exception here. > > On mail.armlinux.org.uk (debian buster, 4.92-8+deb10u3): > > 2019-12-14 12:54:23 1ig6vq-00073k-Ez H=flint.armlinux.org.uk > [x:x:x:x:201:2ff:fe14:8fad] Warning: ACL "warn" statement skipped: condition > test deferred > ... repeated several times ... > 2019-12-14 12:54:28 1ig6vq-00073k-Ez malware acl condition: clamd > /run/clamav/clamd.ctl : ClamAV returned: > /var/spool/exim4/scan/1ig6vq-00073k-Ez/1ig6vq-00073k-Ez.eml: Can't create > temporary directory ERROR > > It looks like this occasion was properly cleaned up. Then the sending > server had another couple of goes using some of the other addresses for > the server (different IPv6 prefixes): > > 2019-12-14 12:54:43 1ig6vR-0003NP-2l H=mail.armlinux.org.uk > [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after end of > data: 421 Unexpected failure, please try later > 2019-12-14 12:54:44 1ig6vR-0003NP-2l H=mail.armlinux.org.uk > [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after > pipelined MAIL FROM: SIZE=14672979: 421 > Unexpected failure, please try later > > For the second attempt, mail.armlinux.org.uk logged: > > 2019-12-14 12:54:43 1ig6wH-00073p-Mu H=flint.armlinux.org.uk > [x:x:x:x:201:2ff:fe14:8fad] Warning: ACL "warn" statement skipped: condition > test deferred > ... repeated several times ... > 2019-12-14 12:54:43 1ig6wH-00073p-Mu H=flint.armlinux.org.uk [x:x2019-12-14 > 13:02:56 Start queue run: pid=27196 -qfl > > Note the last log line was corrupted, which suggests exim couldn't write > to the log file (space was available but only as reserved for root.) > However, note the spool ID. > > At this point, mail.armlinux.org.uk stopped receiving anything else: > > 2019-12-14 13:04:26 spool directory space check failed: space=0 inodes=353381 > > as the space that that previous attempt left a bunch of files behind: > > -rw-r- 1 Debian-exim Debian-exim 14479989 Dec 14 12:54 > /var/spool/exim4/input/1ig6wH-00073p-Mu-D > > without a -H file, so exim is never going to process that. Also: > > # ls -al /var/spool/exim4/scan/1ig6wH-00073p-Mu/ > -rw-r- 1 Debian-exim Debian-exim 14479970 Dec 14 12:54 > 1ig6wH-00073p-Mu-0 > -rw-r- 1 Debian-exim Debian-exim3 Dec 14 12:54 > 1ig6wH-00073p-Mu-1 > -rw-r- 1 Debian-exim Debian-exim 1867851 Dec 14 12:54 > 1ig6wH-00073p-Mu-2 > -rw-r- 1 Debian-exim Debian-exim5 Dec 14 12:54 > 1ig6wH-00073p-Mu-3 > -rw-r- 1 Debian-exim Debian-exim 819200 Dec 14 12:54 > 1ig6wH-00073p-Mu-4 > -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 > 1ig6wH-00073p-Mu-5 > -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 > 1ig6wH-00073p-Mu-6 > -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 > 1ig6wH-00073p-Mu-7 > -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 > 1ig6wH-00073p-Mu-8 > -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 > 1ig6wH-00073p-Mu-9 > -rw-r- 1 Debian-exim Debian-exim 14484031 Dec 14 12:54 > 1ig6wH-00073p-Mu.eml > > were all left behind from that attempt. > > I'm going to provision a separate filesystem for exim's spool for the > future, but the obvious question is - shouldn't exim have cleaned up > after itself, rather than leaving large stale files behind? > > I guess the plus point of leaving the files behind is it creates a > hard failure that gets noticed! > > Thanks. > > -- > Russell King > > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://wiki.exim.org/ > -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] exim doesn't seem to properly clean up after exhausing spool space
Hi, It seems that exim doesn't properly clean up after a failure to write to its message queue, but ends up leaving what it has written in the spool and other directories. The sending server (exim) reported: 2019-12-14 12:53:58 1ig6vR-0003NP-2l <= r...@flint.armlinux.org.uk U=rmk P=local S=14483755 id=@gmail.com 2019-12-14 12:54:28 1ig6vR-0003NP-2l H=mail.armlinux.org.uk [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after end of data: 451 Temporary local problem - please try later after it tried to deliver a message, because mail.armlinux.org.uk ran out of space (oops.) A 14MB email tends to be the exception here. On mail.armlinux.org.uk (debian buster, 4.92-8+deb10u3): 2019-12-14 12:54:23 1ig6vq-00073k-Ez H=flint.armlinux.org.uk [x:x:x:x:201:2ff:fe14:8fad] Warning: ACL "warn" statement skipped: condition test deferred ... repeated several times ... 2019-12-14 12:54:28 1ig6vq-00073k-Ez malware acl condition: clamd /run/clamav/clamd.ctl : ClamAV returned: /var/spool/exim4/scan/1ig6vq-00073k-Ez/1ig6vq-00073k-Ez.eml: Can't create temporary directory ERROR It looks like this occasion was properly cleaned up. Then the sending server had another couple of goes using some of the other addresses for the server (different IPv6 prefixes): 2019-12-14 12:54:43 1ig6vR-0003NP-2l H=mail.armlinux.org.uk [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after end of data: 421 Unexpected failure, please try later 2019-12-14 12:54:44 1ig6vR-0003NP-2l H=mail.armlinux.org.uk [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after pipelined MAIL FROM: SIZE=14672979: 421 Unexpected failure, please try later For the second attempt, mail.armlinux.org.uk logged: 2019-12-14 12:54:43 1ig6wH-00073p-Mu H=flint.armlinux.org.uk [x:x:x:x:201:2ff:fe14:8fad] Warning: ACL "warn" statement skipped: condition test deferred ... repeated several times ... 2019-12-14 12:54:43 1ig6wH-00073p-Mu H=flint.armlinux.org.uk [x:x2019-12-14 13:02:56 Start queue run: pid=27196 -qfl Note the last log line was corrupted, which suggests exim couldn't write to the log file (space was available but only as reserved for root.) However, note the spool ID. At this point, mail.armlinux.org.uk stopped receiving anything else: 2019-12-14 13:04:26 spool directory space check failed: space=0 inodes=353381 as the space that that previous attempt left a bunch of files behind: -rw-r- 1 Debian-exim Debian-exim 14479989 Dec 14 12:54 /var/spool/exim4/input/1ig6wH-00073p-Mu-D without a -H file, so exim is never going to process that. Also: # ls -al /var/spool/exim4/scan/1ig6wH-00073p-Mu/ -rw-r- 1 Debian-exim Debian-exim 14479970 Dec 14 12:54 1ig6wH-00073p-Mu-0 -rw-r- 1 Debian-exim Debian-exim3 Dec 14 12:54 1ig6wH-00073p-Mu-1 -rw-r- 1 Debian-exim Debian-exim 1867851 Dec 14 12:54 1ig6wH-00073p-Mu-2 -rw-r- 1 Debian-exim Debian-exim5 Dec 14 12:54 1ig6wH-00073p-Mu-3 -rw-r- 1 Debian-exim Debian-exim 819200 Dec 14 12:54 1ig6wH-00073p-Mu-4 -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 1ig6wH-00073p-Mu-5 -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 1ig6wH-00073p-Mu-6 -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 1ig6wH-00073p-Mu-7 -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 1ig6wH-00073p-Mu-8 -rw-r- 1 Debian-exim Debian-exim0 Dec 14 12:54 1ig6wH-00073p-Mu-9 -rw-r- 1 Debian-exim Debian-exim 14484031 Dec 14 12:54 1ig6wH-00073p-Mu.eml were all left behind from that attempt. I'm going to provision a separate filesystem for exim's spool for the future, but the obvious question is - shouldn't exim have cleaned up after itself, rather than leaving large stale files behind? I guess the plus point of leaving the files behind is it creates a hard failure that gets noticed! Thanks. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Define preferred encryption algorithms
On Thu, Oct 10, 2019 at 04:30:29PM +0200, jmedard--- via Exim-users wrote: > Hello, > > > > More and more Internet security diagnostic tools (such as Immuniweb and > Hardenize) specify that mail servers should be able to offer their preferred > encryption algorithms. They consider it a security risk if the server must > not be configured to select the best-available suite. > > > > They say: "The server does not prefer cipher suites. We advise to enable > this feature in order to enforce use of the best cipher suites selected." > > > > On Exim the order of the encryption string, present in "tls_require_ciphers" > does not matter, the order is not used. > > > > I think this requires the switch to "Server preference", via the > openssl_options: "+cipher_server_preference", but it is not enough for the > server to define a recommended encryption algorithm. Hi, I don't know whether you're subscribed to the list or not, so I'll Cc my reply to you. Some background in SSL/TLS may be beneficial. When SSL starts up, the client sends a "Client Hello" that identifies the ciphers it supports (and other data.) The server compares the list with its own cipher list to identify those ciphers supported by both ends. The server then selects one of those ciphers and sends the selected cipher back in the "Server Hello". The way openssl under exim selects the cipher depends on this "+cipher_server_preference" flag: - If this flag is not set, the first common cipher in the order of the client's list will be selected. This means the client has the power to select which cipher will be used. The client _could_ list weak ciphers before strong ciphers, and you'd end up with a weak cipher. - If this flag is set, the first common cipher in the order of the server's list will be selected. Provided the server's list is in the order of strongest..weakest, it gives the server the ability to select the strongest supported common cipher irrespective of what the order of ciphers that client has sent. So, "+cipher_server_preference" is what you want. What may be causing your problem is the way you are specifying the ciphers to the server. There are various prefixes to that change how the cipher list is created. To see the list of ciphers, use: $ openssl ciphers It's worth pointing out that you have to be _very_ careful with the cipher list, because ciphers can move around depending on how you specify them in the list. Here's what the prefix characters mean (grabbed from the openssl ciphers man page): If ! is used then the ciphers are permanently deleted from the list. The ciphers deleted can never reappear in the list even if they are explicitly stated. If - is used then the ciphers are deleted from the list, but some or all of the ciphers can be added again by later options. If + is used then the ciphers are moved to the end of the list. This option doesn't add any new ciphers it just moves matching existing ones. Beware of the "+" prefix - even if you explicitly list a strong cipher at the start of the list, it can have the effect of moving that cipher lower down in the list. As an example: kEECDH:kRSA:kEDH:kPSK:+CAMELLIA128:+AES256:... on some versions of openssl, can result in the first cipher being ECDHE-RSA-AES128-GCM-SHA256, with ECDHE-RSA-AES256-GCM-SHA384 being way lower in the list (because +AES256 moved it there, after the CAMELLIA128 ciphers.) Removing the + from AES256 in that string results in the first four being: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 Note: I am not recommending any particular ciphers in this post, I am just pointing out how this works and the pitfalls that you might be falling in to. Personally, I use https://github.com/drwetter/testssl.sh to test non- https services, which has similar functionality to a popular online checker for https. Hope this helps. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] CVE-2019-13917
On Thu, Jul 25, 2019 at 10:04:19AM +0100, Jeremy Harris via Exim-users wrote:
> If the effective configuration file for exim does not use sort
> then the system is trivially declarable as not being vulnerable.
> Use this command to check: "exim -bP config | grep sort".
The grep expression seems to be a bit over-zealous - it'll pick up
on, e.g., "remote_sort_domains" rather than just the sort expansion
operator. Or is "remote_sort_domains" also implicated?
If it's just the ${sort operator you're after, I think you want the
grep to be:
grep '\${[[:space:]]*sort'
?
--
Russell King
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Available ciphers with stock Debian (gnutls) exim
On Sat, Jul 13, 2019 at 01:52:50PM +0100, Russell King via Exim-users wrote: > On Sat, Jul 13, 2019 at 01:32:34PM +0100, Russell King via Exim-users wrote: > > Maybe it's something to do with the certs/key? > > ... and it was - the wrong usage on the cert. Now fixed. Maybe someone can provide some hints what Key Usage should be set for an exim server certificate. According to Red Hat's website: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Standard_X.509_v3_Certificate_Extensions.html leads me to think that only keyEncipherment and keyAgreement need be set - this is what I had originally, and gnutls refused to offer any EC ciphers. Adding digitalSignature and nonRepudiation to the cert seems to have allowed gnutls to enable EC ciphers, but I don't understand why based on the description above. Can someone say definitively what key usages should be set and which should not be set for an exim server and explain why for each? Thanks. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Available ciphers with stock Debian (gnutls) exim
On Sat, Jul 13, 2019 at 01:32:34PM +0100, Russell King via Exim-users wrote: > Maybe it's something to do with the certs/key? ... and it was - the wrong usage on the cert. Now fixed. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Available ciphers with stock Debian (gnutls) exim
On Sat, Jul 13, 2019 at 01:19:29PM +0200, Andreas Metzler via Exim-users wrote: > Russell King via Exim-users wrote: > > I've been noticing a difference in behaviour between debian systems > > (using gnutls) and rpm-based systems (using openssl) when it comes to > > the ciphers used to transport mail using exim - and it appears to be > > specific to whether the gnutls end is the server or not. > > > As an example, when debian-exim talks to rpm-exim, it uses > > TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256. However, when rpm-exim talks > > to debian-exim, it uses TLSv1.2:AES128-GCM-SHA256:128. > > > I'm not interested in debating what is a better cipher or anything > > of that ilk, but I'd like to understand what is going on, why there > > is this difference, whether it is intentional, or a config cockup. > [...] > > I get the same whether I leave tls_require_ciphers empty or set it > > to NORMAL. Hmm, so it looks like stock debian exim4 just doesn't > > support EC ciphers at all. > [...] > > Does anyone know what's going on here? Is the stock debian exim > > 4.89-2+deb9u4 built against gnutls 3.5.8-5+deb9u4 intentionally > > restricted to a small set of ciphers? Can anyone else reproduce > > this? > > Hello > > Running the old exim version (4.89) in a stretch (Debian 9.9) chroot > without setting tls_require_ciphers I get this when connecting with > current (well, 3.6.7) gnutls-cli This looks like you upgraded gnutls beyond what is in Stretch (which is only 3.5.8-5+deb9u4). Digging into this more, it looks like a gnutls issue. If I run: # gnutls-serv --echo -p 15 --x509keyfile=exim.key --x509certfile=exim.cert and then: # gnutls-cli -p 15 --debug 5 localhost ... |<4>| HSK[0x17d0818]: SERVER HELLO (2) was received. Length 85[85], frag offset 0, frag length: 85, sequence: 0 |<4>| HSK[0x17d0818]: Server's version: 3.3 |<4>| HSK[0x17d0818]: SessionID length: 32 |<4>| HSK[0x17d0818]: SessionID: 25dab9ea480a12a68e2bd3d6000f0ab12e05906199ab5c62c109fb94c1efd0c6 |<4>| HSK[0x17d0818]: Selected cipher suite: RSA_AES_256_GCM_SHA384 In other words, it seems stock Stretch gnutls can't negotiate ECDSA ciphers with itself. > gnutls-cli-debug reports the following info: > whether we need to disable TLS 1.2... no > whether we need to disable TLS 1.1... no > whether we need to disable TLS 1.0... no > whether %NO_EXTENSIONS is required... no >whether %COMPAT is required... no > for TLS 1.0 (RFC2246) support... yes > for TLS 1.1 (RFC4346) support... yes > for TLS 1.2 (RFC5246) support... yes > for TLS 1.3 (RFC8446) support... no > |<1>| FFDHE groups advertised, but server didn't support it; falling back to > server's choice >TLS1.2 neg fallback from TLS 1.6 to... TLS1.2 > for inappropriate fallback (RFC7507) support... yes >for certificate chain order... sorted > for safe renegotiation (RFC5746) support... yes > for encrypt-then-MAC (RFC7366) support... yes >for ext master secret (RFC7627) support... yes >for heartbeat (RFC6520) support... no >for version rollback bug in RSA PMS... dunno > for version rollback bug in Client Hello... no > whether the server ignores the RSA PMS version... no > whether small records (512 bytes) are tolerated on handshake... yes > whether cipher suites not in SSL 3.0 spec are accepted... yes > whether a bogus TLS record version in the client hello is accepted... yes > whether the server understands TLS closure alerts... no > whether the server supports session resumption... no > for anonymous authentication support... no > |<1>| FFDHE groups advertised, but server didn't support it; falling back to > server's choice > for ephemeral Diffie-Hellman support... yes > |<1>| FFDHE groups advertised, but server didn't support it; falling back to > server's choice > for RFC7919 Diffie-Hellman support... no >for ephemeral EC Diffie-Hellman support... yes > for curve SECP256r1 (RFC4492)... yes > for curve SECP384r1 (RFC4492)... yes > for curve SECP521r1 (RFC4492)... yes > for curve X25519 (RFC8422)... no >
[exim] Available ciphers with stock Debian (gnutls) exim
Hi, I've been noticing a difference in behaviour between debian systems (using gnutls) and rpm-based systems (using openssl) when it comes to the ciphers used to transport mail using exim - and it appears to be specific to whether the gnutls end is the server or not. As an example, when debian-exim talks to rpm-exim, it uses TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256. However, when rpm-exim talks to debian-exim, it uses TLSv1.2:AES128-GCM-SHA256:128. I'm not interested in debating what is a better cipher or anything of that ilk, but I'd like to understand what is going on, why there is this difference, whether it is intentional, or a config cockup. The debian-exim server has tls_dhparam set to historic, so it's using a 2048-bit DH. I've dumped the connection, this time between openssl s_client on a Fedora laptop and the debian system, which shows the same behaviour. It looks like gnutls as a server doesn't want to do EC. According to tshark: SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 202 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 198 Version: TLS 1.2 (0x0303) Random ... Session ID Length: 0 Cipher Suites Length: 90 Cipher Suites (45 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) ... Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ... Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 67 Extension: ec_point_formats Type: ec_point_formats (0x000b) Length: 4 EC point formats Length: 3 Elliptic curves point formats (3) EC point format: uncompressed (0) EC point format: ansiX962_compressed_prime (1) EC point format: ansiX962_compressed_char2 (2) Extension: elliptic_curves Type: elliptic_curves (0x000a) Length: 10 Elliptic Curves Length: 8 Elliptic curves (4 curves) Elliptic curve: secp521r1 (0x0019) Elliptic curve: secp384r1 (0x0018) Elliptic curve: secp256k1 (0x0016) Elliptic curve: secp256r1 (0x0017) but the server hello replies with: TLSv1.2 Record Layer: Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 77 Version: TLS 1.2 (0x0303) Random ... Session ID Length: 32 Session ID: ... Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) I thought maybe I needed to change tls_require_ciphers, so I tried setting it to "tls_require_ciphers = NORMAL" and restarting exim, but it still doesn't want to use EC ciphers, even though "gnutls-cli -l --priority=NORMAL" lists them, e.g. Cipher suites for NORMAL TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2 ... TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 0xc0, 0x2b TLS1.2 ... TLS_ECDHE_RSA_AES_128_GCM_SHA2560xc0, 0x2f TLS1.2 The exim manual says that tls_eccurve is ignored for gnutls, so that can't be it. If I use nmap to scan the available ciphers against the gnutls exim, I get: 25/tcp open smtp | ssl-enum-ciphers: ... | TLSv1.2: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CCM - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CCM - strong | TLS_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 - strong | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 - strong | compressors: | NULL |_ least strength: strong I get the same whether I leave tls_require_ciphers empty or set it to NORMAL. Hmm, so it looks like stock debian exim4 just doesn't support EC ciphers at all. When run against the rpm-based exim server, nmap reports many more cipher suites to choose from, which includes the EC ciphers. Does anyone know what's going on
Re: [exim] Extra copies of list mail (was Re: CVE-2019-10149: already vulnerable ?)
On Tue, Jun 25, 2019 at 09:26:51AM -0400, Bill Cole via Exim-users wrote: > On 25 Jun 2019, at 9:03, Jeremy Harris via Exim-users wrote: > > > PS: I do not need an additional copy of list emails. I get > > very tired of getting them. If your MUA does not have > > a "reply to list" button, please get a better one. > > I swear, I'm going to start deliberately ignoring anyone > > who sends me a useless copy, real soon now. > > I entirely concur, but it is an understandable error given what the mailing > list is now doing to sidestep DMARC risks: Yes, but there's more points on this subject too... Given that different lists have different policies, and that it takes a mental decision by the replier to choose the correct reply method, it seems to me that mistakes will happen. For example, if you spend most of the week on Linux kernel related lists, it's mandatory to use reply-to-all unless you really want to reply to just the sender. Reply-to-list is strongly abhored. Then if you come to exim-users, you have to remember to use a different reply behaviour. If you hardly reply on exim-users, that's going to be very accident prone. So, I don't think this kind of jumping down people's throats and threatening to ignore people when they use the wrong reply button is acceptable behaviour. It could just be an accident caused by there being no automatic way for an email client to have the _right_ behaviour for a particular list policy. All the time that list policy is reliant on the right reply button being pressed, mistakes will happen. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] CVE-2019-10149: 4.87 to 4.91 are vulnerable
On Tue, Jun 11, 2019 at 03:42:09PM +0200, Heiko Schlittermann via Exim-users wrote: > Hi, > > Russell King (Di 11 Jun 2019 15:33:47 CEST): > > Hi, > > > > While looking for the fix on the web version of git.exim.org, I find that > > although I can get a listing based on the branch, I'm unable to get commit > > or commitdiffs. > > > > For example, the page at: > > > > https://git.exim.org/exim.git/shortlog/refs/heads/exim-4_91+fixes > > > > gives links such as: > > > > commit > > | commitdiff > > The behaviour you describe seems to depend on the browser. FF is > reported to work, while Chromium doesn't. Probably this varies with the > versions. I think you've misunderstood my email. Please look carefully at those links I've quoted... > If in the above URL you substitute + by %2B, it works. I'm not sure if > this is gitweb's fault. But gitweb could easily avoid this issue by not > using unescaped plus signs. As I stated in my original post, I've tried subsituting the " " with both + and %2b. I was using Firefox, I've also used elinks as well. Nothing works to get a commitdiff. >https://git.exim.org/exim.git/shortlog/refs/heads/exim-4_91%2Bfixes That URL is not a problem - getting the shortlog is not a problem. Following any of the links from the shortlog _is_ a problem as my original post stated. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] CVE-2019-10149: 4.87 to 4.91 are vulnerable
Hi, While looking for the fix on the web version of git.exim.org, I find that although I can get a listing based on the branch, I'm unable to get commit or commitdiffs. For example, the page at: https://git.exim.org/exim.git/shortlog/refs/heads/exim-4_91+fixes gives links such as: commit | commitdiff Notice the space character where there should be a plus character. This gives a gitweb page which contains "400 - Invalid hash parameter". If I subsitute a + character there, or %2b, then the commitdiff page still doesn't give me a commitdiff. It looks like the gitweb you have doesn't like "+" in the branch names, branches without a "+" character in them appear to work fine. On Wed, Jun 05, 2019 at 02:21:18PM +, Heiko Schlittermann via Exim-users wrote: > We will publish the fix today 2019-06-05 15:15 UTC on the exim-4_91+fixes > branch of our public Git repo git.exim.org. > > Distros can release their packages by that date. > > Sorry for the inconveniences. > -- > Heiko Schlittermann (unterwegs) > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://wiki.exim.org/ -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Auth command used when not advertised
Hi, My mail server is being hit with auth attempts when the helo hasn't advertised the presence of authentication - for example, this morning for an hour: 2018-11-25 09:23:58 SMTP protocol error in "AUTH LOGIN" H=15.157.231.35.bc.googleusercontent.com (M9AIVXy9WZ) [35.231.157.15]:53324 I=[78.32.30.218]:587 AUTH command used when not advertised 2018-11-25 09:23:58 SMTP protocol error in "AUTH LOGIN" H=15.157.231.35.bc.googleusercontent.com (WHFIaBK) [35.231.157.15]:53620 I=[78.32.30.218]:587 AUTH command used when not advertised 2018-11-25 09:23:59 SMTP protocol error in "AUTH LOGIN" H=15.157.231.35.bc.googleusercontent.com (7bdz0k) [35.231.157.15]:53712 I=[78.32.30.218]:587 AUTH command used when not advertised ... 2018-11-25 10:14:59 SMTP protocol error in "AUTH LOGIN" H=15.157.231.35.bc.googleusercontent.com (RlgrRD) [35.231.157.15]:53098 I=[78.32.30.218]:587 AUTH command used when not advertised at about a rate of 2 per second. Although that's a fairly low rate, and doesn't cause a problem, I'd rather have a way to (eg) rate limit such hosts to stop the log file pollution. While it's possible to rate limit using exim ACLs, as there is no ACL for this case, there isn't a way to automatically ratelimit such hosts except by parsing the log file (granted, it wouldn't actually be controlling access per se.) My current technique to deal with such people is to spot them in the log file, and add a blocking firewall entry when they bother me, which is sub-optimal as it tends to stay for a very long time, so I'd rather be able to have some way to rate limit such things to (eg) 1 attempt per hour or so, which having exim able to "do something" in this case beyond merely logging the fact would allow. Maybe this would be a feature request for an ACL that gets run on failed auth attempts, similar to the smtp notquit ACL? (Yes, I'm aware that this is a block-cracking attempt, and yes, I'm already using elements of Lena's implementation - but that doesn't cover this situation.) Thanks. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
