[exim] Rate limiting and TOTP - was Re: Looking for an example
On Wed, 1 Jul 2020, Sebastian Nielsen via Exim-users wrote: Its just that such systems you describe only prevents further damage when the damage is already done. It could be enough with like a few spam messages to get blacklisted. So even if you ratelimit to like 10 messages per day, you still risk ending up on blacklist if some account is compromised. For low volume systems, yes that could be true. The best way as I said is to enforce sign in limits. Limit account to GeoIP, limit account to ISP. Require TOTP to reset IP limits. Use TOTP for webmail login. Only allow limitless logins from campus IPs. ...... TOTP is the easiest way to secure an account, but don't work over SMTP/IMAP, instead it can only be used in webmail, thats why you need to use some IP limitation for SMTP/IMAP where a TOTP login to the webmail also authorizes the source IP to access SMTP/IMAP for the user in question. (X)OAUTH2 uses short-term, but not one-time, passwords. Microsoft and Gmail seem to be using these successfully with SMTP/POP/IMAP. Would this be an acceptable alternative ? (Exim doesn't currently support (X)OAUTH2 and experience with alpine/fetchmail/mutt/thunderbird suggests that client-side support is needed for each host domain, so I am not clear that this is a feasible suggestion.) -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk -- ## 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] option -MCd
On 30/06/2020 16:01, Marc Haber via Exim-users wrote: > A contributor on the bug report says: > |I am pretty sure that the problem is caused by the commit > 6906c131d1d07d07831f8fbabae6290a3cba6ca3 > |(Use a monotonic clock, if available, for ID generation). > > |The change contains measuring of the difference between CLOCK_MONOTONIC and > realtime once > |at startup (exim_clock_init), but as far as I understand CLOCK_MONOTONIC > > |on Linux does not increase during suspend/hibernate (possibly wrognly [1]), > > |so the difference grows then, unaccounted for. > > | > > |[1]: https://stackoverflow.com/a/3527632/1236045 > > > Is this the possible cause of the issue showing up on at least three > Debian systems since we upgraded to exim 4.94? Aha. Yes, because Linux does not adhere to Posix for CLOCK_MONOTONIC over a suspend, every message will get a delay after final-dot for the aggregate suspend time since the exim process (the daemon, for smtp receptions) was started. This is obviously untenable and Exim must workaround the standards-deficient platform. Fix upcoming. Frank - if you see this, could a suspend have been involved in your cases? -- Cheers, Jeremy -- ## 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] option -MCd
On 30/06/2020 16:01, Marc Haber via Exim-users wrote: > Is this the possible cause of the issue showing up on at least three > Debian systems since we upgraded to exim 4.94? It does sound plausible that it is related. How was the message given exim - command-line or smtp? Was it first given to exim before, or after, the suspend/resume? How long was the suspend? How long did you wait, in the hung-at-final-dot condition, before using pkill? An experiment of a short suspend, and waiting for longer than that, would be of interest - assuming the issue can be created on demand. I'm not a regular user of suspend myself, and don't trust it to function well enough on this system. If you can easily repro and are prepared to build & test variants, this would be useful. Even just disbling the CLOCK_MONOTONIC code would be a good step. -- Cheers, Jeremy -- ## 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] option -MCd
On Fri, 19 Jun 2020 10:04:09 +0100, Jeremy Harris via Exim-users wrote: >Exim uses the system time as part of generating unique identifiers. >To do that it waits, if needed, for the granularity of the time >it is using for that purpose. That should be something in the >millisecond range. To end up having to wait for six minutes >suggests that your system time jumped backwards by that much. > >Exim is not designed to work in that environment. It assumes that >time only goes forwards, and that it does move. If you are >deliberately changing the system time backwards I suggest that >at the very least you need to stop Exim first and restart after. >Even doing that could result in unintended behaviour for the >doubly-covered apparent period. Debian has a similiar issue in the latest exim version, bug #962847, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962847. There, the issue is probably related to a Linux system sent to Suspend and waking up later. I see the issue on my own notebook as well when delivering a message to the local exim via SMTP to localhost. exim has the message on the queue, but the SMTP session is hung, after "." in the data phase. pkill -9 exim and restarting exim will have the message sent by the next queue runner, but the calling software receives a connection abort and will eventually resend a second copy. A contributor on the bug report says: |I am pretty sure that the problem is caused by the commit 6906c131d1d07d07831f8fbabae6290a3cba6ca3 |(Use a monotonic clock, if available, for ID generation). |The change contains measuring of the difference between CLOCK_MONOTONIC and realtime once |at startup (exim_clock_init), but as far as I understand CLOCK_MONOTONIC |on Linux does not increase during suspend/hibernate (possibly wrognly [1]), |so the difference grows then, unaccounted for. | |[1]: https://stackoverflow.com/a/3527632/1236045 Is this the possible cause of the issue showing up on at least three Debian systems since we upgraded to exim 4.94? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- ## 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 samba4 active directory
Hi, thanks for your help ! I do it and now its working ! cat -- ## 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] Tainted filename on DKIM signing in 4.94
On 30-06-2020 16:22 +200, Jeremy Harris wrote:
Something along the lines of
dkim_private_key = \
${lookup {${sender_address_domain}} \
dsearch,ret=full {/usr/local/etc/exim} \
{$value/dkim.private.key} {false}}
--
Cheers,
Jeremy
Perfect, thanks very much Jeremy.
--
## 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] Tainted filename on DKIM signing in 4.94
On 30/06/2020 13:59, Andy Smith via Exim-users wrote:
> remote_smtp:
> driver = smtp
> dkim_domain = ${sender_address_domain}
> dkim_selector = dkimxy
> dkim_private_key = ${if exists \
> {/usr/local/etc/exim/${sender_address_domain}/dkim.private.key}\
> {/usr/local/etc/exim/${sender_address_domain}/dkim.private.key}\
> {false}}
> dkim_canon = relaxed
>
> I'm unsure if this is the case on the other thread, but my requirement
> is to choose the key based on the sender domain so as to support unique
> DKIM keys for multiple domains. Can anyone advise?
Something along the lines of
dkim_private_key = \
${lookup {${sender_address_domain}} \
dsearch,ret=full {/usr/local/etc/exim} \
{$value/dkim.private.key} {false}}
--
Cheers,
Jeremy
--
## 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] allow alias file to include aliases from another file
On 6/30/2020 8:16 AM, Jeremy Harris via Exim-users wrote:
On 29/06/2020 20:44, Jason Keltz via Exim-users wrote:
If an item is of the form
:include:
a list of further items is taken from the given file and included
at that point. Note: Such a file can not be a filter file; it is
just an out-of-line addition to the list. The items in the
included list are separated by commas or newlines and are not
subject to expansion. If this is the first item in an alias list
in an lsearch file, a colon must be used to terminate the alias
name. This example is incorrect:
list1 :include:/opt/lists/list1
It must be given as
list1: :include:/opt/lists/list1
Tainted data may not be used for a filename.
I can use the third form (last1: :include:/opt/lists/list1) in my
/etc/aliases file. However, I cannot use the first form:
:include:/etc/aliases.alternate
Am I misinterpreting the instruction?
It depends on how you are obtaining this list item. The item itself
takes the "first form". If you are doing an lsearch to get the item,
then the line in the file for lsearch (which needs both a key to
search for, and the data to be returned) needs to terminate the
key with a colon.
If you are not using an lsearch then "third form" is not relevant.
Hi Jeremy,
Thanks for your response. I'm still missing something
All I want to know is whether the following line alone in an existing
/etc/aliases file should or should not allow me to include aliases from
an additional external file:
:include:/etc/aliases.alternate
My system_aliases is defined as:
system_aliases:
driver = redirect
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases}}
user = exim
file_transport = address_file
pipe_transport = address_pipe
If this syntax will not work, is there an additional way to include a
secondary aliases file?
The reason I am asking for this is because one alias file is modified by
hand, but the other one is automatically generated.
Thanks!
Jason.
--
## 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] allow alias file to include aliases from another file
On 30/06/2020 15:19, Jason Keltz via Exim-users wrote:
> All I want to know is whether the following line alone in an existing
> /etc/aliases file should or should not allow me to include aliases from
> an additional external file:
>
> :include:/etc/aliases.alternate
>
> My system_aliases is defined as:
>
> system_aliases:
> driver = redirect
> allow_fail
> allow_defer
> data = ${lookup{$local_part}lsearch{/etc/aliases}}
^^^
You're doing an lsearch.
I said:
>> The item itself
>> takes the "first form". If you are doing an lsearch to get the item,
>> then the line in the file for lsearch (which needs both a key to
>> search for, and the data to be returned) needs to terminate the
>> key with a colon.
Your line:
:include:/etc/aliases.alternate
does not have a key for the lsearch.
--
Cheers,
Jeremy
--
## 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] Tainted filename on DKIM signing in 4.94
Hi all,
I have the same issue as reported here:
https://lists.exim.org/lurker/message/20200606.112240.9ecf1e56.en.html
But I'm too thick to undestand if the solution posted can be applied to
my setup as it looks a bit different:
remote_smtp:
driver = smtp
dkim_domain = ${sender_address_domain}
dkim_selector = dkimxy
dkim_private_key = ${if exists \
{/usr/local/etc/exim/${sender_address_domain}/dkim.private.key}\
{/usr/local/etc/exim/${sender_address_domain}/dkim.private.key}\
{false}}
dkim_canon = relaxed
I'm unsure if this is the case on the other thread, but my requirement
is to choose the key based on the sender domain so as to support unique
DKIM keys for multiple domains. Can anyone advise?
thanks in advance,
Andy.
--
## 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] allow alias file to include aliases from another file
On 29/06/2020 20:44, Jason Keltz via Exim-users wrote: >> If an item is of the form >> >> :include: >> >> a list of further items is taken from the given file and included >> at that point. Note: Such a file can not be a filter file; it is >> just an out-of-line addition to the list. The items in the >> included list are separated by commas or newlines and are not >> subject to expansion. If this is the first item in an alias list >> in an lsearch file, a colon must be used to terminate the alias >> name. This example is incorrect: >> >> list1 :include:/opt/lists/list1 >> >> It must be given as >> >> list1: :include:/opt/lists/list1 >> >> Tainted data may not be used for a filename. >> > I can use the third form (last1: :include:/opt/lists/list1) in my > /etc/aliases file. However, I cannot use the first form: > > :include:/etc/aliases.alternate > > Am I misinterpreting the instruction? It depends on how you are obtaining this list item. The item itself takes the "first form". If you are doing an lsearch to get the item, then the line in the file for lsearch (which needs both a key to search for, and the data to be returned) needs to terminate the key with a colon. If you are not using an lsearch then "third form" is not relevant. -- Cheers, Jeremy -- ## 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] Looking for an example
> From: Mark Elkins > I'm looking for an example for how to cure this problem. > > Every now and then, a user will give his password to a bad actor (Social > Engineering). That bad person then goes to my webmail interface and > sends out a lot of SPAM e-mail - which goes to my port 587 (only) Exim > (version 4.94).. > > The mail server then gets black-listed :-( > All my users details are in a MySQL Database. Ideally - I could change > their status to "disabled" How to detect outgoing spam: https://github.com/Exim/exim/wiki/BlockCracking -- ## 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] allow alias file to include aliases from another file
Hi. I have an Exim aliases file that works fine (let's call it /etc/aliases). I want /etc/aliases to be able to include another automatically generated aliases file (say, /etc/aliases.generated). According to the Exim documentation on the "redirect router": * If an item is of the form :include: a list of further items is taken from the given file and included at that point. Note: Such a file can not be a filter file; it is just an out-of-line addition to the list. The items in the included list are separated by commas or newlines and are not subject to expansion. If this is the first item in an alias list in an lsearch file, a colon must be used to terminate the alias name. This example is incorrect: list1:include:/opt/lists/list1 It must be given as list1: :include:/opt/lists/list1 Tainted data may not be used for a filename. I can use the third form (last1: :include:/opt/lists/list1) in my /etc/aliases file. However, I cannot use the first form: :include:/etc/aliases.alternate Am I misinterpreting the instruction? Jason. -- ## 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] 4.94 - De-tainting without lookup?
The 2020-06-29 19:54:26, Michael Haardt via Exim-users wrote:
> Matthias Hörmann wrote:
>
> > Why not use a simple whitelist string replacement? All characters but
> > some known valid characters (say [a-zA-Z0-9_.-]) are replaced with a
> > known valid character (say _)? We use that in puppet all the time to
> > generate paths. As long as you disallow slashes you don't even have to
> > worry about .. appearing in there. Potentially a check for a maximum
> > length might be useful to add but that should fail on its own if the
> > filesystem can not handle it.
>
> For your application, that may suffice. For others, more may be needed.
> Thinking of /base/$variable/path, it may be quite important that the
> variable is not "..", especially if you create files and directories
> on demand.
But the solution I propose is strictly more powerful than just allowing
lookups to detaint values. In fact it is lookups that may suffice for
some simplistic cases but won't work anywhere else while a sanitizing
option should work for all use-cases, even if the results might
sometimes be visually less than pleasing (e.g. a string consisting
entirely of replacement characters).
>
> Tainted variables are not an obstacle meant to enforce workarounds
> somehow.
By releasing them without any warning that is exactly what you are
forcing onto people though. You made the exim config language severely
less expressive and people are not just going to throw away their
use-cases that can not be implemented with lookups.
Worse, you might make some people pin exim to an old version and forget
about upgrading it which is worse in a security sense.
>
> The idea is to verify tainted values and assign the result to an untainted
> variable that is further used like previously tainted variables were, ideally
> doing so only once at a central spot. The verifier decides if the passed
> value is valid.
>
> The problem of tainted values possibly exploiting something due to a
> missing verification is real.
It is, I have seen it in the wild on our servers...which is why we have
been using character whitelists in our ACLs for quite a while now,
throwing out all that nonsense that the spec for email addresses allows
but nobody uses in practice, e.g. {}
>
> String manipulations as such can't be verifiers, but they can sanitize bad
> values, so they pass a subsequent verifier, if that's what you want to do.
>
> As I wrote, currently there are only lookups acting as verifier and that's
> likely not enough. If you want to sanitize values, you could translate
> some characters to an underscore (still tainted), feed that to a path
> component "lookup" that makes sure it is not ".", ".." and contains no
> slashs, get an untainted value from that and be fine. Except that we
> don't have a pseudo lookup like that yet, and that there may be better
> ideas how to integrate verifiers that check conditions other than a key
> or query lookup in a database of some kind.
But your lookups are _not_ verifiers. They are a de-tainting mechanism
that only works for a rather limited set of use-cases, namely the ones
where you have a very limited set of known valid values. We are talking
about email here though, we can not use lookups for the entire set of
valid local parts and domains on the internet, not even the subset we
wish to receive mail from or send mail to.
>
> Michael
>
> --
> ## 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/
--
Mit freundlichen Grüßen,
Matthias Hörmann
fon: +49 (0) 521 - 329647-29
fax: +49 (0) 521 - 329647-40
email: matthias.hoerm...@saltation.com
---
saltation GmbH & Co. KG | Niederwall 43 | 33602 Bielefeld
Sitz Bielefeld | Amtsgericht Bielefeld HRA 15344
Persönlich haftende Gesellschafterin:
saltation Beteiligungs-GmbH | Niederwall 43 | 33602 Bielefeld
Sitz Bielefeld | Amtsgericht Bielefeld HRB 39339
Geschäftsführer: Daniel Brün
---
Wir erfüllen unsere Informationspflichten gem. Artt. 13-14 DS-GVO
durch Veröffentlichung auf unserer Internetseite unter
https://www.saltation.com/de/datenschutzerklaerung.html
oder durch Zusendung auf Ihre formlose Anfrage.
--
## 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/
