[exim] Obfuscating $authresults

2019-09-25 Thread Richard James Salts via Exim-users
Hi all, I'm looking at the resulting Authentication-Results: header from an $authresults expansion when using smtp auth and it's giving auth=pass (METHOD) smtp.auth=user, or in the case of local submission local=pass (non-smtp, $primaryhostnam) u=user. I was wondering if it would be possible to

Re: [exim] New compromise...?

2019-09-25 Thread Viktor Dukhovni via Exim-users
On Wed, Sep 25, 2019 at 09:47:41AM +0200, Mark Elkins via Exim-users wrote: > However - from my viewpoint, the Username used in the authentication > "mycli...@zanet.co.za" should be the same as the "From".. i.e. <= > minan...@zanet.co.za. > Is there a neat way to drop emails when the "From" is n

Re: [exim] New compromise...?

2019-09-25 Thread Sebastian Nielsen via Exim-users
Yeah. Both of them is good. First have a base restriction that locks an account to a specific country. Then use a ratelimit to further restrict inside the country. Could be a good idea to have different ratelimits for /32, /24 and /16, so /16 has very strict ratelimit (only like 4 different per

Re: [exim] New compromise...?

2019-09-25 Thread Randy Bush via Exim-users
> However - from my viewpoint, the Username used in the authentication > "mycli...@zanet.co.za" should be the same as the "From".. i.e. <= > minan...@zanet.co.za. > Is there a neat way to drop emails when the "From" is not the same as > the PLAIN authenticated name? so some of the spammers will ad

Re: [exim] Content scanning and non-MIME messages

2019-09-25 Thread Ian Zimmerman via Exim-users
On 2019-09-25 07:21, Dennis Davis wrote: > Chapter 14 of the manual. The main option message_body_visible: > > message_body_visible Use: main Type: integer Default: 500 Yes, thanks. I'll leave it at the default until I get a spam message because of it :-) -- Please don't Cc: me priv

Re: [exim] New compromise...?

2019-09-25 Thread Heiko Schlittermann via Exim-users
Sebastian Nielsen via Exim-users (Mi 25 Sep 2019 05:49:26 EDT): > Another way to deal with compromises is to IP-restrict the user accounts so > they can only login from where they are supposed to login from. > If ALL of your users "belong" to the same country - for example i fits a > company-in

Re: [exim] New compromise...?

2019-09-25 Thread Heiko Schlittermann via Exim-users
Heiko Schlittermann (Mi 25 Sep 2019 13:12:45 EDT): > Maybe we use ratelimit to restrict the numbers of distinct > sender_host_addresses that are allowed to do (successful) > authentication. We can. > The challenge will be to find the right balance between being too sloppy > and too strict. cl_c

Re: [exim] SMTP error from remote mail server after pipelined MAIL

2019-09-25 Thread Graeme Fowler via Exim-users
On 25 Sep 2019, at 15:43, necktwi via Exim-users wrote: > How to run recovery? I tried rm -rf /var/spool/exim/db/* and started the exim That’s one perfectly valid way, although there are others specific to the Berkeley DB tools you have installed (or can install). However: > These messages are

Re: [exim] New compromise...?

2019-09-25 Thread Sebastian Nielsen via Exim-users
Yeah, and for home/webhosting, its easy for the user to set up a VPN to his home router (most routers today have a VPN server function) and use his home IP while on the go. Originalmeddelande Från: Richard James Salts via Exim-users Datum: 2019-09-25 12:36 (GMT+01:00) Till:

Re: [exim] New compromise...?

2019-09-25 Thread Cyborg via Exim-users
Am 25.09.19 um 12:11 schrieb Julian Bradfield via Exim-users: > Um, some people do occasionally travel, you know. > Solution: VPN.  Makes SMTP indirectly a 2FA ;) It also helps against surveilance and hacks. best regards, Marius -- ## List details at https://lists.exim.org/mailman/listinfo/exi

Re: [exim] New compromise...?

2019-09-25 Thread Cyborg via Exim-users
Am 25.09.19 um 11:49 schrieb Sebastian Nielsen via Exim-users: > Another way to deal with compromises is to IP-restrict the user accounts so > they can only login from where they are supposed to login from. > If ALL of your users "belong" to the same country - for example i fits a > company-inter

Re: [exim] New compromise...?

2019-09-25 Thread Richard James Salts via Exim-users
On 25 September 2019 8:11:10 pm AEST, Julian Bradfield via Exim-users wrote: >On 2019-09-25, Sebastian Nielsen via Exim-users >wrote: >> list of CIDR ranges that your country, or even better, your company, >uses. >> >> If different users belong to different countries, for example if you >run

Re: [exim] New compromise...?

2019-09-25 Thread Julian Bradfield via Exim-users
On 2019-09-25, Sebastian Nielsen via Exim-users wrote: > Another way to deal with compromises is to IP-restrict the user accounts so > they can only login from where they are supposed to login from. > If ALL of your users "belong" to the same country - for example i fits a > company-internal email

Re: [exim] New compromise...?

2019-09-25 Thread Cyborg via Exim-users
Am 25.09.19 um 11:21 schrieb Heiko Schlittermann via Exim-users: > > In MAIL ACL (or later) you can block messages from authenticated users > if authenticated ID does not match the sender address, or you can > ratelimit on the authenticated ID > ehm.. we are talking about a hacked mail account, no

Re: [exim] New compromise...?

2019-09-25 Thread Sebastian Nielsen via Exim-users
Another way to deal with compromises is to IP-restrict the user accounts so they can only login from where they are supposed to login from. If ALL of your users "belong" to the same country - for example i fits a company-internal email server, I would suggest set auth_advertise_hosts to a list o

Re: [exim] New compromise...?

2019-09-25 Thread Heiko Schlittermann via Exim-users
Mark Elkins via Exim-users (Mi 25 Sep 2019 03:47:41 EDT): > However - from my viewpoint, the Username used in the authentication > "mycli...@zanet.co.za" should be the same as the "From".. i.e. <= > minan...@zanet.co.za. > Is there a neat way to drop emails when the "From" is not the same as the >

[exim] New compromise...?

2019-09-25 Thread Mark Elkins via Exim-users
Hi folk, I came across a new (to me) method of sending SPAM through my 587 only mail relay system for my clients. As usual - a user has given up her password (social engineering - whatever). The account was being used to send about 10 emails at a time with a different from address and from dif