Re: [exim] Windows based Mail servers and exim

2023-02-07 Thread Julian Bradfield via Exim-users
On 2023-02-07, The Doctor via Exim-users  wrote:
> Wonder if anyone has notice a problem with
> Windows based server like Exchange or spamrtmail
> sending to exim servers

What makes you think the problem is with the server software?

> No connection could be made because the target computer actively refused it. 
> This usually results from trying to connect to a service that is inactive on 
> the remote host - that is, one with no server application running. For more 
> information and tips to fix this issue see this article: 
> https://go.microsoft.com/fwlink/?LinkId=389361

If it were my server you were trying to connect to, this would mostly
likely mean that you had been trying to crack my server and had been
blocked. Perhaps your client is also running malicious software?

-- 
## 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] DKIM: signing failed: LONG_LINE - in paniclog

2023-01-07 Thread Julian Bradfield via Exim-users
On 2023-01-07, Andrew C Aitchison via Exim-users  wrote:
> On Sat, 7 Jan 2023, Julian Bradfield via Exim-users wrote:
...
>> But the question was, why is this panic-worthy? I thought the paniclog
>> was supposed to indicate that exim is seriously broken, not just
>> encountering some malformed email.
>
> IIUC the message was lost, which exim considers to be a big deal
> (though you know better in this instance).

Nope. The message just gets sent without signing.
(Remarkably, although it was as spammy as hell, gmail accepted it for
my user.)

-- 
## 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] DKIM: signing failed: LONG_LINE - in paniclog

2023-01-07 Thread Julian Bradfield via Exim-users
On 2023-01-06, Jeremy Harris via Exim-users  wrote:
> You could perhaps configure to not attempt to sign such messages
> by using a suitable expansion for dkim_domain.  If you can't
> use something like $sender_address then $max_received_line_length
> might work.

Or I could just reject them on receipt - they're spam, anyway.

But the question was, why is this panic-worthy? I thought the paniclog
was supposed to indicate that exim is seriously broken, not just
encountering some malformed email.

-- 
## 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] DKIM: signing failed: LONG_LINE - in paniclog

2023-01-06 Thread Julian Bradfield via Exim-users
>From time to time I get this. I know what the message means, and why
it happens, but why does this message go into the paniclog and disturb
me, when I don't care at all about it and can't see why I should?

-- 
## 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 4.96 stopping because postfix is starting?

2022-12-20 Thread Julian Bradfield via Exim-users
On 2022-12-20, Johnnie W Adams via Exim-users  wrote:
> What puzzles me about that is why this _doesn't_ pass SPF. The outbound
> node is also mta.ualr.edu, which is right there in the SPF record:
> "v=spf1 a:mta.ualr.edu include:_spf.google.com redirect=_spf.ualr.edu"

> I also don't quite understand this from the log: What should be in the
> empty set of brackets?
>
> SPF check for [] does not pass with ip: [144.167.8.120].

Are you sending a message with an empty MailFrom ?
In that case, the SPF check will be done against postmaster@EHLO,
where EHLO is the name your server gave in EHLO. If that name isn't
covered by your SPF records, it won't pass.

-- 
## 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] FTP access to exim.org not working?

2022-12-17 Thread Julian Bradfield via Exim-users
On 2022-12-17, Mike Tubby via Exim-users  wrote:
> Has something changed w.r.t. FTP access to exim.org?
>
> I have downloaded new versions of Exim for years using FTP CLI but now I 
> can't files from two different hosts and with 'active' or 'passive' modes.

Works for me in active mode, but not in passive mode.
(Xubuntu 20.04).

-- 
## 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] debugging tls handshake failure

2022-11-25 Thread Julian Bradfield via Exim-users
On 2022-11-23, Viktor Dukhovni via Exim-users  wrote:

> So, have you tried configuring a complete certificate chain (ideally
> without the Android compatibility crutch).  Did that make any
> difference?

Well, since doing that I haven't seen any fatal alerts in the logs.
But I also haven't had another attempt from the bank in question yet,
only from the usual spammers.

I wasn't actually asking how to fix the problem, by the way, only
about how to get the alert information, which Jeremy answered.

-- 
## 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] debugging tls handshake failure

2022-11-24 Thread Julian Bradfield via Exim-users
On 2022-11-23, Kirill Miazine via Exim-users  wrote:
> • Julian Bradfield via Exim-users [2022-11-23 18:25]:
> [...]
>> Kirill wrote:
>> 
>> something in base64 which got saved as such:)
>
> I wonder why...

Because when you save an article in slrn, it saves the entire
article. There doesn't appear to be a "write the decoded body" option,
and there isn't an option to follow up to multiple articles in one
post, so I just saved all the replies to a file and edited that.

>> Asking I think for any information, as he sees something similar. Will
>> do.
>
> exactly: https://marc.info/?l=exim-users&m=166919251811778&w=2

I didn't say I didn't have the original, it just wasn't in
my followup, and slrn also doesn't let you go back to the article
display while composing.

Yes, I could just use Gnus, but the Gnus interface annoys me too
much, and I've been using rn variants for 35 years ...

Maybe I'll extend slrn ...

-- 
## 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] debugging tls handshake failure

2022-11-23 Thread Julian Bradfield via Exim-users
Thank you for the various replies!

Viktor wrote:

>> 2022-11-21 21:10:42 TLS error on connection from 
>> r218.notifications.rbs.co.uk [130.248.154.218] (gnutls_handshake): A TLS 
>> fatal alert has been received.
>
>OpenSSL would usually log the alert number (and associated text string),
>from which one could infer more information about what the remote client
>is unhappy about.  I'd hope that GnuTLS could also log this (or make the
>alert info available to Exim to optionally log).

Hopefully if I set it correctly, per Jeremy's reply below, it will.

>That said, the most common issues that remote clients are unhappy about
>are untrusted certificates and expired certificates.  Perhaps you have a
>Let's Encrypt certificate chain that includes a cross cert to the now
>expired DST Root CA (for Android compatibility).  You can configure
>certbot et. al. to build a chain that skips the cross cert, expecting
>clients to support the ISRG root.

>If the server in question is "london.jcbradfield.org", then another
>potential issue is a missing intermediate issuer certificate.  Your
>certificate chain has only the leaf server certificate without the
>required "R3" intermediate issuer certificate.  If using certbot, use
>"fullchain.pem" not "cert.pem" (or the equivalent for a different
>setup).

Indeed. That's only been the case recently. For the last 20 years,
I've been presenting a self-signed certificate and had never noticed any
problems. A few days ago I happened to notice my bank getting these
TLS fatal alerts and then *not* falling through to plain text, which
most others do.
So I started experimenting, but hadn't yet got as far as giving the
full chain (largely, I admit, because I don't have certification
internalized, and just follow recipes).

Jeremy wrote:
>The gnutls library helpfully (I infer) reads the environment at
>process startup, too early for the config-driven addition of that
>variable.  Try having the thing firing off the exim process
>adding to the environment instead.  You'll need to add it
>to keep_environment.

Thanks! Should have thought of that.

>Alternatively, since you know there's an alert involved, go down
>the packet capture route.  You'll need to
>add_environment = SSLKEYLOGFILE=/sslkeys
>and tell wireshark where to pick them up
>(edit/pref/protocols/tls/ Master Secret Log filename)

Ugh. Hopefully not... Presumably that would also have to be done by
setting it before exim start.

>Oh, yes, do ensure you're running with Exim's debug facilities
>enabled.  Commandline option or ACL modifier.

Tried that. Debug +tls gave nothing useful.


Kirill wrote:

something in base64 which got saved as such:) (Anybody know a
newsreader which supports following up to multiple article at once?)

Asking I think for any information, as he sees something similar. Will
do.

-- 
## 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] debugging tls handshake failure

2022-11-21 Thread Julian Bradfield via Exim-users
I should like to know what's happening here:

2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk 
[130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received.

However, I can't see how to get any more information. I've tried
setting
add_environment = GNUTLS_DEBUG_LEVEL=3
in the exim4 config file, but it doesn't appear to do anything.

Is there a way to get more information?


-- 
## 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] drop connection on auth failure

2022-07-15 Thread Julian Bradfield via Exim-users
On 2022-07-15, Jeremy Harris via Exim-users  wrote:
> My practice, and I think it would help with this sort of
> attacker, is to delay the auth response for a fail.
> By 15 or 20 seconds.  Most drop off by about ten, so

How do you do this? Abusing server_condition doesn't work, as it's
only expanded if the base authentication succeeds.
(My authentication method is cram-md5.)

-- 
## 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] drop connection on auth failure

2022-07-15 Thread Julian Bradfield via Exim-users
On 2022-07-15, Slavko via Exim-users  wrote:
> To OP: I will do not suggest to use as aggressive bans at all, as a lot
> of hosts try only once and then go away, thus banning them is only
> resource wasting...

Not my experience. A large number of hosts try every hour or two -
presumably they're part of a distributed net working its way through
possible credentials. (Why they think any of these addresses might
exist, I do not know - most of them don't.)
By implementing a 10-day ban for any auth failure, the number of
attempts per day drops by a factor of 5 to 8.

> You can use AUTH attempts counting in AUTH ACL and the do something with
> this value, eg. (i do not drop by this way, thus only idea):
>
>   warn  set acl_c_authcnt = ${eval10:$acl_c_authcnt+1}
>
>   drop  condition   = ${if >{$acl_c_authcnt}{1}}
> condition   = $authentication_failed
> logwrite= H=$sender_fullhost LAST FAILed: \
>   $authenticated_fail_id

That only works on multiple AUTHs in the same session, doesn't it?

> I recently discovered (OK, i ugpraded it) fail2bans bantime auto
> incerement, whis i see as very useful for banning these toxics and to
> deal with false positives relative acceptable with short initial
> bantime:

Interesting, thanks. I don't know whether that's on my system (I
cannot be bothered with custom installations these days), but I'll
check.

-- 
## 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] drop connection on auth failure

2022-07-15 Thread Julian Bradfield via Exim-users
On 2022-07-15, Jeremy Harris via Exim-users  wrote:
> On 15/07/2022 14:17, Jeremy Harris via Exim-users wrote:
>> This will crash that exim process, hence dropping the connection.
> No, I'm mistaken.
> Could you set up your fail2ban to be less aggressive?

Of course I could, but I don't want to! 

-- 
## 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] drop connection on auth failure

2022-07-15 Thread Julian Bradfield via Exim-users
On 2022-07-15, Evgeniy Berdnikov via Exim-users  wrote:
> On Fri, Jul 15, 2022 at 01:54:56PM +0100, Julian Bradfield via Exim-users 
> wrote:
>> I should like exim to drop the connection on a client AUTH failure.
>> (Because as soon it's seen in the log, fail2ban will DROP the client IP,
>> and so the exim process will hang around until the SMTP session times
>> out.)
>
>  Note that fail2ban is not a realtime service, it scans logs in timely
>  manner (typically by cron, every 10-15 min). So probability for active
>  connection to be blocked by fail2ban is very low.

Yes, it is a realtime service, at least in my system.

>  Nevetheless, if you want to keep active connections unblocked, you may
>  insert before fail2ban's rules your own rule, which allows packets for
>  established connection to be passed. Example for Linux:
>
>  iptables -I INPUT 1 -p tcp -m multiport --destination-ports 25,465,587 \
> -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Ah, I'm not well up on iptables, so hadn't thought of that. Thanks!

-- 
## 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] drop connection on auth failure

2022-07-15 Thread Julian Bradfield via Exim-users
I should like exim to drop the connection on a client AUTH failure.
(Because as soon it's seen in the log, fail2ban will DROP the client IP,
and so the exim process will hang around until the SMTP session times
out.)

However, I can't see a way to do this. Am I missing something in the
docs?



-- 
## 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] google bounce messages

2022-06-25 Thread Julian Bradfield via Exim-users
On 2022-06-25, Randy Bush via Exim-users  wrote:
[ who?
>> Please, do not send reply direct to me, one message via ML is
>> enough...
>
> the world needs to modify mua reply behavior because your M*A can't deal
> with dupes?

No, exim-users members should follow what has been standard tech list
etiquette since forever. As the exim-users etiquette guide says,
"In general discussion should take place on the list itself, and
replies should be sent to the list rather than the originator."
It does go on to say "Some people prefer to send responses to both
list and originator. If you prefer not to get CCs to your personal
address, set a Reply-to header containing the mailing list address."
but I can't see why the burden should be on the recipient to get round
poor etiquette.

If your MUA can't do the right thing, get a better MUA.
Duplicate suppression is a real pain - if the personal copy arrives
first, the list copy won't get filtered into wherever you keep list
mail. 

-- 
## 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] Closing off Port to non-SSL traffic

2022-06-23 Thread Julian Bradfield via Exim-users
On 2022-06-23, The Doctor via Exim-users  wrote:
> Is their a way to close off Port 25 unless you are using SSL?
>
> Heads up
>
> The I caught on porn now pay up scandal is back.

Did it ever go away?

> Further this hackers are maurauding mail servers for usernames
> and passwords to relay their messages.

Tedious, isn't it. I get probed by 5000 hosts per day. I've now set
fail2ban to "one strike and you're out".

> We all need to closing port 25 to non-SSL traffic.

I don't understand how that helps. You shouldn't be allowing plain
text password authentication over non-SSL connections now - the
default configuration doesn't allow this.
How does it help to ban other non-SSL communication?

-- 
## 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] multiple cc: headers

2022-05-09 Thread Julian Bradfield via Exim-users
On 2022-05-09, Slavko via Exim-users  wrote:
> Dňa 9. 5. o 10:53 Julian Bradfield via Exim-users napísal(a):
>> I'd never seen this before, so I went off to check RFC5822, and I see
>> that in the 5822 version, only one of the To:, CC: or BCC: headers is
>> allowed to be generated.
>
> RFC 5822 doesn't exists.

My error - google autocorrected me to 5322 and I didn't
notice. (Happens every time...)

>> However, the RFC says that implementations MUST accept the (now)
>> obsolete syntax, and SHOULD treat multiple destination address headers
>> in the obvious way.

> I cannot find your citatinon nor in RFC5322 nor in RFC5321, which RFC do 
> you mean?

The "MUST accept" is in the first paragraph of section 4., and is
repeated for emphasis in the immediately following Note.

The "SHOULD combine multiple headers" is in section 4.5.3.

> IMO, do not send multiple addressing headers, the both RFC are here for 
> about 25 years, and here is no reason to use syntax which was obsoleted 
> 25 years ago nowadays.

5322 is dated October 2008, which is 14 years. In something as
critical as mail, that's a short time. I might agree that we don't
need to accept bang addresses any more, but that's about as far as I'd
go :)

Anyway, the point is that (as I've seen), modern MTAs (the message in
question went through Postfix, then Sendmail) do not rewrite messages
with multiple addressing headers. The user has no way of knowing that
multiple CC: headers are deprecated, and it's a natural thing to
write if you're adding several distinct groups of people in cc.

An obsessively educational sysadmin could send a warning about it,
but rejecting messages that MUST be accepted remains clearly wrong!


-- 
## 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] multiple cc: headers

2022-05-09 Thread Julian Bradfield via Exim-users
I've just had a bounce from the MTA running on mx1.solardns.com, which
advertises itself as  Exim 20220503.1020

The bounce was:

550 Messages should have one or no Cc headers, not 2

I'd never seen this before, so I went off to check RFC5822, and I see
that in the 5822 version, only one of the To:, CC: or BCC: headers is
allowed to be generated.

However, the RFC says that implementations MUST accept the (now)
obsolete syntax, and SHOULD treat multiple destination address headers
in the obvious way.

Coming to the point: is the bounce message coming from some (hopefully
experimental) part of Exim, or must it have been maliciously
hand-crafted in a config file by the solardns administrators?

I can't find anything relevant in the 4.95 docs.

-- 
## 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] greylisting and spf

2022-03-11 Thread Julian Bradfield via Exim-users
I wonder if any of you have done any analysis of how much spam email
is SPF-valid?

For many years, one of my main spam defences has been a reasonably
aggressive greylisting strategy. This works well at never seeing the
spam from the "fire-and-forget" spambots, but it has the downside of
occasionally delaying genuine mail by a few minutes (or up to an hour,
depending on the sending MTA's retry strategy), which is particularly
annoying when the genuine mail is sending me a one-time code.

Of course, the greylisting doesn't work on any spambot that works like
a real MTA and retries.

So I was wondering what difference it would make if I exempted
SPF-valid mail from greylisting. Does one see lots of fire-and-forget
but SPF-valid spam?

(And the reason I'm asking rather than measuring is that I would have
to go to the trouble of setting up SPF - I run Debian, and haven't yet
found the need to switch to stock Exim where SPF is a simpler setup.)

Julian.

-- 
## 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] converting from debian package to source

2022-01-08 Thread Julian Bradfield via Exim-users
On 2022-01-08, Slavko (tblt) via Exim-users  wrote:
>>So I suppose the question is: if I drop the master-source-built binary
>>on top of the Debian one, what can I expect to break?

> AFAIK spfquery is used in debian's exim for years, thus i am confused, why it 
> is problem for you right now,

Because today I wanted to log the spf status in order to look at issues with
other sites. 
I haven't until now bothered with SPF on incoming mail at all.
I do record the DKIM status in incoming mail for the MUA to look at,
and I wanted to do the same with SPF.

-- 
## 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] converting from debian package to source

2022-01-08 Thread Julian Bradfield via Exim-users
On 2022-01-08, Andreas Barth via Exim-users  wrote:
> * Julian Bradfield via Exim-users (exim-users@exim.org) [220108 15:18]:
>> The pain of dealing with Debian's antiquated versions (4.92) and
>> gratuitous messing around with upstream's configuration (most recent
>> annoyance, not supporting built-in SPF) is prompting me to think about
>> switching to using the primary source.
>
> Debian stable uses 4.94, as well as oldstable-backports.

True. I hadn't thought of installing from backports. (My servers are
on buster.) But I'm not sure whether there's anything in 4.94+ that I
need now, it's just all the warnings I see about 4.92 being very obsolete.

> If you could elaborate on your problems, perhaps there is an fix
> available. Otherwise it's of course trivial to build your own debian
> package, but I never felt the need to do so for exim.

Specifically, I don't like the idea of installing an external tool
spfquery and using the slightly clunky config snippet to use it,
rather than using the built-in spf - I like things in the exim4 manual
to work in my installation!

However, I also don't like fiddling with systems more than necessary -
sysadmin is not my job, it's just what I have to do to make things
work. If I have to go the trouble of building my own Debian package, I
might as well lose all the debian changes and just install exim from
source, which is easy to repeat on all systems I might use.

But there are things I know I might need to watch for: UIDs
(Debian-exim vs exim), for example.

So I suppose the question is: if I drop the master-source-built binary
on top of the Debian one, what can I expect to break? (Tainting is the
main thing I'm aware of as a risk.)

I guess I could just try it and see on a quiet day :)


-- 
## 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] converting from debian package to source

2022-01-08 Thread Julian Bradfield via Exim-users
My mail servers run, and have run for decades, on Debian, and I've
always used the Debian package for exim4, though I don't use debconf
for my own additions, but just edit the conf.template file as if it
were a .conf file.

The pain of dealing with Debian's antiquated versions (4.92) and
gratuitous messing around with upstream's configuration (most recent
annoyance, not supporting built-in SPF) is prompting me to think about
switching to using the primary source.

I wonder if anybody on this list has done such a conversion recently,
and would have time to share the chief gotchas they encountered.

If you reply to me, I will summarize to the list.

Thanks,
Julian.

-- 
## 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] backup servers and self-pointing MX

2021-07-19 Thread Julian Bradfield via Exim-users
I'm not sure of how to achieve the following aim.

My setup is that I have two mail servers, call them FIRST and SECOND.
Their exim configurations are almost identical, with one difference
conditioned upon the presence of /etc/exim4/BACKUPMX .

Normally, the MXes are FIRST with priority 10, and SECOND with
priority 20.
FIRST takes mail for the hosted domains and delivers it through
procmail to home directories.
SECOND accepts mail for the hosted domains and passes it to the
dnslookup router for delivery - since FIRST has higher priority,
dnslookup doesn't attempt to deliver to the local host.

When, as now, my main server is at risk of disruption, I stop (and
disable at boot) exim on FIRST, sync the home directories to SECOND,
and restart exim on SECOND in main server mode. One DNS change to make
the imap server address point to SECOND instead of FIRST, and I'm
done.

However, I want to be able to get messages generated on FIRST. If I
start exim on FIRST in backup mode, then dnslookup will find FIRST as
the first on the list, so I would have to set  self=send to get
delivery; but then it will just send to itself and loop.

Is there a way I can achieve what I want *without* changing all the MX
records for the hosted domains? (Or without rerouting to a special
backup domain, or other such tricks.)

-- 
## 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 data issues

2020-11-10 Thread Julian Bradfield via Exim-users
I thought it was standard practice in introducing a new feature that
causes major breakage to existing installations, to take a three step
approach. First you provide the feature, and give it an enabling
switch with three levels "off", "warn but don't error", "on".
Then in successive releases you change the default value of the
enabling switch, and ultimately you remove the enabling switch.

I understand that taint protection is considered a security feature,
but it's a feature exim users have done without for decades, so I
can't really see that there was a particularly urgent need to
introduce it in a big bang.

-- 
## 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 grammar help needed

2020-07-16 Thread Julian Bradfield via Exim-users
On 2020-07-16, Phillip Carroll via Exim-users  wrote:
> However, the DMARC example of 58.5 contains a construct that has me 
> totally stumped:
>
> warn !domains = +screwed_up_dmarc_records
>
> In an exhaustive search of the PDF version of the spec, I found exactly 
> 98 occurrences of the symbol "!". Exactly one of those 98 instances (the 
> line quoted above) contains "!domains". None of the other 97 instances 
> appear to satisfactorily explain how to interpret the construct in 
> question.
>
> Presumably the left side of the "=" is negated in some manner, but that 
> is about as much as I think I understand. The right side looks 
> sufficiently close (linguistically speaking) to "foobar" that I think I 
> have some glimmer of understanding of that.  But, maybe not.

It means   warn  !( domains = +screwed_up_dmarc_records)

The meaning of ! is explained in the first line of section 44.20 of
the spec.

-- 
## 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] 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 server, I would suggest set auth_advertise_hosts to a
> 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 a
> webhosting company, I would suggest putting the country that was used to
> either register the account, or the country who did issue the credit card that
> was used to pay for the webhosting, in a database.

Um, some people do occasionally travel, you know.

-- 
## 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] treating moral config errors as serious

2019-07-18 Thread Julian Bradfield via Exim-users
On 2019-07-18, Jeremy Harris via Exim-users  wrote:
> On 18/07/2019 21:00, Julian Bradfield via Exim-users wrote:
>> On 2019-07-18, Jeremy Harris via Exim-users  wrote:
>>> On 18/07/2019 20:03, Julian Bradfield via Exim-users wrote:
>>>> I've just had an embarrassing incident where a system upgrade
>>>> overwrote a customized greylistd, with the result that mail from new
>>>> senders was always deferred because of an invalid condition value, and
>>>> I didn't notice for more than a week.
>>>
>>> What sort of "invalid value" ?
>> 
>> "white", "grey" (instead of the "true" or "false" that would have been
>> correctly emitted by the customized greylistd).
>
> Depending where you use strings indicating truth values,
> the interpretation varies.  Router conditions have a lax
> interpretation: "false" "no" and "0" are false, anything
> else is true.  So "grey" would be true.

I know.

> In others, eg. ACL conditions, tighter rules apply.
> Specifically, for ACLs, you get a defer.  This is
> documented.

I know.

> We're unlikely to change those rules; it would break
> valid configurations.

I didn't suggest changing the rules, I asked whether I'd missed a way
to configure the rules (e.g. to replace "defer" by "panic").
Failing that, any way to grep the logs for things that "shouldn't
happen" would be useful. Of course I can now grep for this particular
error, but I'm sure there are many other ways of accidentally breaking
mail which will result in other log messages that shouldn't happen in
a normally running system. Ideally there would be a list of every
message exim can omit...

-- 
## 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] treating moral config errors as serious

2019-07-18 Thread Julian Bradfield via Exim-users
On 2019-07-18, Jeremy Harris via Exim-users  wrote:
> On 18/07/2019 20:03, Julian Bradfield via Exim-users wrote:
>> I've just had an embarrassing incident where a system upgrade
>> overwrote a customized greylistd, with the result that mail from new
>> senders was always deferred because of an invalid condition value, and
>> I didn't notice for more than a week.
>
> What sort of "invalid value" ?

"white", "grey" (instead of the "true" or "false" that would have been
correctly emitted by the customized greylistd).

-- 
## 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] treating moral config errors as serious

2019-07-18 Thread Julian Bradfield via Exim-users
I've just had an embarrassing incident where a system upgrade
overwrote a customized greylistd, with the result that mail from new
senders was always deferred because of an invalid condition value, and
I didn't notice for more than a week.

On the whole, I feel that if during processing an ACL condition gets
an invalid value, that indicates a configuration error, and I'd like
exim to panic, since I will notice a panic quite quickly :)
Similarly for other run-time config file errors.

I don't see any option to make this kind of error get treated more
seriously - is there one that I've missed, or some other approach?

-- 
## 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] Disclaimer and DKIM

2018-11-08 Thread Julian Bradfield via Exim-users
On 2018-11-08, Heiko Schlittermann via Exim-users  wrote:
> As I mentioned, I setup Exim *checking* if the disclaimer exists and ask
> users to configure their clients to add the disclaimer. It is IMHO there
> responsibility to add it.

Asking thirty thousand users to individually configure their mail
client (something which about twenty-nine thousand of them are
probably not competent to do) rather than having one sysadmin
configure the MTA, is something that no sane organization would
tolerate. 

-- 
## 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] Disclaimer and DKIM

2018-11-07 Thread Julian Bradfield via Exim-users
On 2018-11-07, Heiko Schlittermann via Exim-users  wrote:
> Douglas, Daniel via Exim-users  (Mi 07 Nov 2018 21:46:38
> CST):
[ snip ]

> You should refuse to use your MTA for message alteration.

This is not a useful comment. Many places are required by law to
ensure that every communication from them includes certain text.  If
you don't do it at the outbound MTA, where do you do it? (Unless, of
course you force everybody to use Exchange and absolutely nothing
else...)

> Adding a disclaimer may do a lot of harm. E.g. it will destroy a GPG
> signature, or it will be outside of the GPG signature, and worthless
> then.

A disclaimer is not worthless outside a GPG signature. Nor is the
charity identification number which you would see as a signature if I
were posting this from work.

-- 
## 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] Disclaimer and DKIM

2018-11-07 Thread Julian Bradfield via Exim-users
On 2018-11-07, Douglas, Daniel via Exim-users  wrote:
> We need to add disclaimers to out email and also use DKIM to sign our 
> messages. Each of these things work individually but if they are both 
> configured on a transport then the DKIM check fails because the disclaimer is 
> added after the signature has been added. The disclaimers are added using 
> altermime in a transport filter (see transport below)

Can you do the dkim-signing with opendkim in the transport filter,
after adding the disclaimer?

-- 
## 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] Filter with special characters (!?)

2018-08-23 Thread Julian Bradfield via Exim-users
On 2018-08-22, Emanuel Gonzalez via Exim-users  wrote:
> 2018-08-22 07:48:12 1fsQgL-000554-6N Entrantes y Salientes autenticados - 
> Cuenta_FROM:  - X-Mailer = Microsoft Outlook 
> Express 6.00.2900.2950 - Subject = \277Eres el del video?
>
> discardcondition = ${if match{$header_subject:}{^\277Eres el del 
> video?\$}}   logwrite = Rejected By SPAM - $header_subject - FROM: 
> "$sender_address"


You haven't escaped the ? in your regex.

-- 
## 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] detecting DMARC-protected domain

2018-07-08 Thread Julian Bradfield via Exim-users
On 2018-07-07, Phil Pennock via Exim-users  wrote:
> On 2018-07-07 at 18:56 +0100, Julian Bradfield via Exim-users wrote:
>> Is there a way to detect, in the Exim configuration file, whether a
>> sender domain has a DMARC record?

> ${lookup dnsdb{txt=_dmarc.$sender_address_domain}{yes}{no}}

Ah, thank you. Of course, I should have known that, but the exim
manual is quite big these days :)

Thank you for the further suggestions about trying out the ARC
experimental feature. Interesting to know about.
However, although I'm signed up to this list at work (I should change
that) I'm actually only the mail admin for my family (plus occasional
hangers-on) mail server, and it sounds like a bit more work than I
want to mess with just now! But maybe I'll get bored during my
upcoming sabbatical :)

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-- 
## 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] detecting DMARC-protected domain

2018-07-07 Thread Julian Bradfield via Exim-users
Is there a way to detect, in the Exim configuration file, whether a
sender domain has a DMARC record?
As far as Google tells me, the only mention of DMARC in the Exim spec
is the acknowledgement of the OpenDMARC library.

I suppose I should explain the reason, in case there's a better way:
one of my users forwards her email to gmail (which I do via formail in
her .procmailrc). Unfortunately, she gets mail from domains with a
DMARC reject policy - so when I'm forwarding a DKIM-signed message, I
munge it to come from us (using the percent hack, for old times' sake
- yes, the acceptance of incoming percent-hacked addresses for relaying is
tightly tied down:), and strip the signature.

Unfortunately again, one of the domains sometimes sends unsigned
messsages. When they go directly to people, the From: address will
authenticate against SPF, so will still pass; but since they're not
signed, I don't detect and munge them, and of course they don't pass
when relayed from me. I would prefer to avoid munging *all* her
relayed mail, but could cope with munging all mail relayed from a
DMARC protected domain.




-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-- 
## 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/