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
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).
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
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
Hi,
thanks for your help !
I do it and now its working !
cat
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
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}\
>
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
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
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 =
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
> 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)
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
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
14 matches
Mail list logo
