Re: exim - bad file descriptor
Le 12-06-2023, à 21:25:40 +0200, Michel Verdier a écrit : On 2023-06-11, steve wrote: After a few days with this configuration, same errors are still present. I guess I'll have either to reinstall or go the postfix way. Just to be sure before you reinstall can you provide exim -bP | grep syslog syslog_duplication Docs indicate it "controls duplicate log lines on syslog". So adding syslog don't resolve the problem. Sorry I don't have exim installed here and I can't help you more. Try a purge+install. Perhaps after upgrading to bookworm :) I've been a happy bookworm user for months already :) Will give postfix a try one of these days. Have a nice day
Re: exim - bad file descriptor
On 2023-06-11, steve wrote: >>> After a few days with this configuration, same errors are still present. >>> >>> I guess I'll have either to reinstall or go the postfix way. >> >>Just to be sure before you reinstall can you provide >>exim -bP | grep syslog > > syslog_duplication Docs indicate it "controls duplicate log lines on syslog". So adding syslog don't resolve the problem. Sorry I don't have exim installed here and I can't help you more. Try a purge+install. Perhaps after upgrading to bookworm :)
Re: exim - bad file descriptor
Hi Michel, Le 10-06-2023, à 11:19:25 +0200, Michel Verdier a écrit : On 2023-06-10, steve wrote: Hi Michel and al, After a few days with this configuration, same errors are still present. I guess I'll have either to reinstall or go the postfix way. Just to be sure before you reinstall can you provide exim -bP | grep syslog syslog_duplication syslog_facility = syslog_pid syslog_processname = exim syslog_timestamp
Re: exim - bad file descriptor
On 2023-06-10, steve wrote: > Hi Michel and al, > > After a few days with this configuration, same errors are still present. > > I guess I'll have either to reinstall or go the postfix way. Just to be sure before you reinstall can you provide exim -bP | grep syslog
Re: exim - bad file descriptor
Hi Michel and al, After a few days with this configuration, same errors are still present. I guess I'll have either to reinstall or go the postfix way. Have a nice day, steve Le 05-06-2023, à 10:50:00 +0200, Michel Verdier a écrit : Le 5 juin 2023 Steve a écrit : if one succeed without message and with code 0, add in /etc/logrotate.d/exim4-base and /etc/logrotate.d/exim4-paniclog postrotate systemctl exim4-base endscript if you add reload but still get the error try restart, I don't know if the reload free the files Since this is a vanilla setup, I might as well uninstall and purge exim4 and re-install it (or postfix), what do you think? Yes I wonder why debian don't add the postrotate. But there is a specific package exim4-config. So you can do dpkg-reconfigure exim4-config you should ask to use syslog and not direct logging it will add log_file_path in config files (you can check after) I only use postfix for me and clients for a long time, so don't ask me : postfix rules :)
Re: exim - bad file descriptor
Le 05-06-2023, à 10:50:00 +0200, Michel Verdier a écrit : Le 5 juin 2023 Steve a écrit : if one succeed without message and with code 0, add in /etc/logrotate.d/exim4-base and /etc/logrotate.d/exim4-paniclog postrotate systemctl exim4-base endscript if you add reload but still get the error try restart, I don't know if the reload free the files Since this is a vanilla setup, I might as well uninstall and purge exim4 and re-install it (or postfix), what do you think? Yes I wonder why debian don't add the postrotate. But there is a specific package exim4-config. So you can do dpkg-reconfigure exim4-config Just did that, left unchanged except for the minimize DNS request, which I enabled. you should ask to use syslog and not direct logging I did. it will add log_file_path in config files (you can check after) Now: log_file_path = /var/log/exim4/%slog I only use postfix for me and clients for a long time, so don't ask me : postfix rules :) Maybe another story later… :)
Re: exim - bad file descriptor
Le 5 juin 2023 Steve a écrit : >>if one succeed without message and with code 0, add in >>/etc/logrotate.d/exim4-base and /etc/logrotate.d/exim4-paniclog >> >>postrotate >>systemctl exim4-base >>endscript >> >>if you add reload but still get the error try restart, I don't know if >>the reload free the files > > Since this is a vanilla setup, I might as well uninstall and purge exim4 > and re-install it (or postfix), what do you think? Yes I wonder why debian don't add the postrotate. But there is a specific package exim4-config. So you can do dpkg-reconfigure exim4-config you should ask to use syslog and not direct logging it will add log_file_path in config files (you can check after) I only use postfix for me and clients for a long time, so don't ask me : postfix rules :)
Re: exim - bad file descriptor
Le 05-06-2023, à 10:21:52 +0200, Michel Verdier a écrit : Le 5 juin 2023 Steve a écrit : Merci pour ton aide Michel. De rien :) Let's continue in english for the list Sure. log_file_path = /var/log/exim4/%slog log_selector = +smtp_protocol_error +smtp_syntax_error +tls_certificate_verified +tls_peerdn exim writes directly to the logfiles. If you get the error almost every day it can be because of the rotation. This error appears everyday. I boot my machine every morning at 6 am. I don't know it exim provide a reload command, so try systemctl reload exim4-base systemctl reload exim4-base.service Failed to reload exim4-base.service: Job type reload is not applicable for unit exim4-base.service. systemctl status exim4-base.service ○ exim4-base.service - exim4-base housekeeping Loaded: loaded (/lib/systemd/system/exim4-base.service; static) Active: inactive (dead) TriggeredBy: ● exim4-base.timer Docs: man:exim4(8) it should be exim4-base but if the service is not found type exim and TAB to find the actual service name if it fails try systemctl restart exim4-base I stopped and restarted the service. Now I get: systemctl status exim4-base.service ○ exim4-base.service - exim4-base housekeeping Loaded: loaded (/lib/systemd/system/exim4-base.service; static) Active: inactive (dead) since Mon 2023-06-05 10:29:02 CEST; 35s ago TriggeredBy: ● exim4-base.timer Docs: man:exim4(8) Process: 41181 ExecStart=/etc/cron.daily/exim4-base systemd-timer (code=exited, status=0/SUCCESS) Main PID: 41181 (code=exited, status=0/SUCCESS) CPU: 63ms jun 05 10:29:02 box.lan systemd[1]: Starting exim4-base.service - exim4-base housekeeping... jun 05 10:29:02 box.lan systemd[1]: exim4-base.service: Deactivated successfully. jun 05 10:29:02 box.lan systemd[1]: Finished exim4-base.service - exim4-base housekeeping. if one succeed without message and with code 0, add in /etc/logrotate.d/exim4-base and /etc/logrotate.d/exim4-paniclog postrotate systemctl exim4-base endscript if you add reload but still get the error try restart, I don't know if the reload free the files Since this is a vanilla setup, I might as well uninstall and purge exim4 and re-install it (or postfix), what do you think?
Re: exim - bad file descriptor
Le 5 juin 2023 Steve a écrit : > Merci pour ton aide Michel. De rien :) Let's continue in english for the list > log_file_path = /var/log/exim4/%slog > log_selector = +smtp_protocol_error +smtp_syntax_error > +tls_certificate_verified +tls_peerdn exim writes directly to the logfiles. If you get the error almost every day it can be because of the rotation. I don't know it exim provide a reload command, so try systemctl reload exim4-base it should be exim4-base but if the service is not found type exim and TAB to find the actual service name if it fails try systemctl restart exim4-base if one succeed without message and with code 0, add in /etc/logrotate.d/exim4-base and /etc/logrotate.d/exim4-paniclog postrotate systemctl exim4-base endscript if you add reload but still get the error try restart, I don't know if the reload free the files
Re: exim - bad file descriptor
Le 05-06-2023, à 09:09:05 +0200, Michel Verdier a écrit :
Le 5 juin 2023 Steve a écrit :
Yes, nothing is done after rotation. But I don't remember the default
exim logging mechanism. Can you provide
grep -r log_file_path /etc/exim*
This gives nothing.
Then can you provide
exim -bP
(snip ip adresses if you want)
See attached file.
Merci pour ton aide Michel.
accept_8bitmime
acl_not_smtp =
acl_not_smtp_start =
acl_smtp_auth =
acl_smtp_connect =
acl_smtp_data = acl_check_data
acl_smtp_data_prdr = accept
acl_smtp_dkim =
acl_smtp_etrn =
acl_smtp_expn =
acl_smtp_helo =
acl_smtp_mail = acl_check_mail
acl_smtp_mailauth =
acl_smtp_notquit =
acl_smtp_predata =
acl_smtp_quit =
acl_smtp_rcpt = acl_check_rcpt
acl_smtp_starttls =
acl_smtp_vrfy =
add_environment =
admin_groups =
no_allow_domain_literals
no_allow_mx_to_ip
no_allow_utf8_domains
auth_advertise_hosts = *
auto_thaw = 0s
bi_command =
bounce_message_file =
bounce_message_text =
bounce_return_body
bounce_return_linesize_limit = 998
bounce_return_message
bounce_return_size_limit = 100K
bounce_sender_authentication =
callout_domain_negative_expire = 3h
callout_domain_positive_expire = 1w
callout_negative_expire = 2h
callout_positive_expire = 1d
callout_random_local_part = $primary_hostname-$tod_epoch-testing
check_log_inodes = 100
check_log_space = 10M
check_rfc2047_length
check_spool_inodes = 100
check_spool_space = 10M
chunking_advertise_hosts = *
no_commandline_checks_require_admin
daemon_smtp_ports = smtp
daemon_startup_retries = 9
daemon_startup_sleep = 30s
no_debug_store
delay_warning = 1d
delay_warning_condition = ${if or {{
!eq{$h_list-id:$h_list-post:$h_list-subscribe:}{} }{
match{$h_precedence:}{(?i)bulk|list|junk} }{
match{$h_auto-submitted:}{(?i)auto-generated|auto-replied} }} {no}{yes}}
no_deliver_drop_privilege
deliver_queue_load_max =
delivery_date_remove
no_disable_ipv6
dkim_verify_hashes = sha256:sha512
dkim_verify_keytypes = ed25519:rsa
dkim_verify_min_keysizes = rsa=1024 ed25519=250
no_dkim_verify_minimal
dkim_verify_signers = $dkim_signers
dns_again_means_nonexist =
dns_check_names_pattern = (?i)^(?>(?(1)\.|())[^\W](?>[a-z0-9/_-]*[^\W])?)+(\.?)$
dns_cname_loops = 1
dns_csa_search_limit = 5
dns_csa_use_reverse
dns_dnssec_ok = 1
dns_ipv4_lookup =
dns_retrans = 0s
dns_retry = 0
dns_trust_aa =
dns_use_edns0 = -1
no_drop_cr
dsn_advertise_hosts =
dsn_from = Mail Delivery System
envelope_to_remove
errors_copy =
errors_reply_to =
event_action =
exim_group = Debian-exim
exim_path = /usr/sbin/exim4
exim_user = Debian-exim
exim_version = 4.96
extra_local_interfaces =
extract_addresses_remove_arguments
finduser_retries = 0
freeze_tell = postmaster
gecos_name = $1
gecos_pattern = ^([^,:]*)
no_gnutls_allow_auto_pkcs11
no_gnutls_compat_mode
header_line_maxsize = 0
header_maxsize = 1048576
headers_charset = UTF-8
helo_accept_junk_hosts =
helo_allow_chars =
helo_lookup_domains = @ : @[]
helo_try_verify_hosts =
helo_verify_hosts =
hold_domains =
host_lookup = *
host_lookup_order = bydns:byaddr
host_reject_connection =
hosts_connection_nolog =
hosts_require_alpn =
hosts_require_helo = *
hosts_treat_as_local =
ignore_bounce_errors_after = 2d
ignore_fromline_hosts =
no_ignore_fromline_local
keep_environment =
keep_malformed = 4d
no_local_from_check
local_from_prefix =
local_from_suffix =
local_interfaces = <; 127.0.0.1 ; ::1
local_scan_path =
local_scan_timeout = 5m
local_sender_retain
localhost_number =
log_file_path = /var/log/exim4/%slog
log_selector = +smtp_protocol_error +smtp_syntax_error
+tls_certificate_verified +tls_peerdn
no_log_timezone
lookup_open_max = 25
max_username_length = 0
no_message_body_newlines
message_body_visible = 500
message_id_header_domain =
message_id_header_text =
message_logs
message_size_limit = 50M
no_move_frozen_messages
no_mua_wrapper
never_users =
notifier_socket = $spool_directory/exim_daemon_notify
openssl_options =
percent_hack_domains =
pid_file_path = /run/exim4/exim.pid
pipelining_advertise_hosts = *
pipelining_connect_advertise_hosts = *
prdr_enable
no_preserve_message_logs
primary_hostname = box.lan
no_print_topbitchars
process_log_path = /var/spool/exim4/exim-process.info
prod_requires_admin
qualify_domain = box.lan
qualify_recipient = box.lan
queue_domains =
no_queue_fast_ramp
queue_list_requires_admin
no_queue_only
queue_only_file =
queue_only_load =
queue_only_load_latch
queue_only_override
no_queue_run_in_order
queue_run_max = 5
queue_smtp_domains =
receive_timeout = 0s
received_header_text = Received: ${if def:sender_rcvhost {from
$sender_rcvhost\n\t}{${if def:sender_ident {from
${quote_local_part:$sender_ident} }}${if def:sender_helo_name
{(helo=$sender_helo_name)\n\tby $primary_hostname ${if
def:received_protocol {with $received_protocol }}${if def:tls_in_ver{
($tls_in_ver)}}${if def:tls_in_cipher_std { tls $tls_in_cipher_std\n\t}}(Exim
$version_number)\n\t${if def:sender_address {(envelope-from
<$sender_
Re: exim - bad file descriptor
Le 5 juin 2023 Steve a écrit : >>Yes, nothing is done after rotation. But I don't remember the default >>exim logging mechanism. Can you provide >> >>grep -r log_file_path /etc/exim* > > This gives nothing. Then can you provide exim -bP (snip ip adresses if you want)
Re: exim - bad file descriptor
Le 04-06-2023, à 19:11:57 +0200, Michel Verdier a écrit : Le 4 juin 2023 Steve a écrit : Does this help? Yes, nothing is done after rotation. But I don't remember the default exim logging mechanism. Can you provide grep -r log_file_path /etc/exim* This gives nothing.
Re: exim - bad file descriptor
Le 4 juin 2023 Steve a écrit : > Does this help? Yes, nothing is done after rotation. But I don't remember the default exim logging mechanism. Can you provide grep -r log_file_path /etc/exim*
Re: exim - bad file descriptor
Le 04-06-2023, à 14:30:08 +0200, Michel Verdier a écrit :
Le 4 juin 2023 Steve a écrit :
2023-06-04T06:30:54.117016+02:00 box exim[24894]: 2023-06-04 06:30:54
1q5fOD-0006TT-2C failed to write to main log: length=91 result=-1 errno=9 (Bad
file descriptor)
2023-06-04T06:30:54.150516+02:00 box exim[24894]: write failed on panic log:
length=116 result=-1 errno=9 (Bad file descriptor)
jun 04 06:30:54 box.lan exim[24894]: 2023-06-04 06:30:54 1q5fOD-0006TT-2C
failed to write to main log: length=91 result=-1 errno=9 (Bad file descriptor)
jun 04 06:30:54 box.lan exim[24894]: write failed on panic log: length=116
result=-1 errno=9 (Bad file descriptor)
6h25 is the usual hour for cron.daily launching logrotate.
Check in /etc/logrotate.d/ if exim is reloaded/restarted after rotation.
cat /etc/logrotate.d/exim4-base
/var/log/exim4/mainlog /var/log/exim4/rejectlog {
daily
missingok
rotate 10
compress
delaycompress
notifempty
nocreate
}
cat /etc/logrotate.d/exim4-paniclog
/var/log/exim4/paniclog {
size 10M
missingok
rotate 10
compress
delaycompress
notifempty
nocreate
}
Does this help?
Re: exim - bad file descriptor
Le 4 juin 2023 Steve a écrit : > 2023-06-04T06:30:54.117016+02:00 box exim[24894]: 2023-06-04 06:30:54 > 1q5fOD-0006TT-2C failed to write to main log: length=91 result=-1 errno=9 > (Bad file descriptor) > 2023-06-04T06:30:54.150516+02:00 box exim[24894]: write failed on panic log: > length=116 result=-1 errno=9 (Bad file descriptor) > jun 04 06:30:54 box.lan exim[24894]: 2023-06-04 06:30:54 1q5fOD-0006TT-2C > failed to write to main log: length=91 result=-1 errno=9 (Bad file descriptor) > jun 04 06:30:54 box.lan exim[24894]: write failed on panic log: length=116 > result=-1 errno=9 (Bad file descriptor) 6h25 is the usual hour for cron.daily launching logrotate. Check in /etc/logrotate.d/ if exim is reloaded/restarted after rotation.
exim - bad file descriptor
Hi, Running Debian bookworm fully updated. Since a couple of weeks, i see strange lines in the logs: 2023-06-04T06:30:54.117016+02:00 box exim[24894]: 2023-06-04 06:30:54 1q5fOD-0006TT-2C failed to write to main log: length=91 result=-1 errno=9 (Bad file descriptor) 2023-06-04T06:30:54.150516+02:00 box exim[24894]: write failed on panic log: length=116 result=-1 errno=9 (Bad file descriptor) jun 04 06:30:54 box.lan exim[24894]: 2023-06-04 06:30:54 1q5fOD-0006TT-2C failed to write to main log: length=91 result=-1 errno=9 (Bad file descriptor) jun 04 06:30:54 box.lan exim[24894]: write failed on panic log: length=116 result=-1 errno=9 (Bad file descriptor) Exim seems to work ok for internal mail. Looked for information on the Net but didn't find anything that helped. The setup must be Debian standard since I haven't tweaked any config files (I don't know how to do that and I don't have any reason to do it, I'm just using exim as internal mta). It seems that /var/log/exim4/mainlog is filling up normally. I don't see any panic log file in there though (what is a panic log). /var has enough space left. Why am I receiving the bad file desciptor log? Thanks. s.
Re: exim failure
On Sun 26 Mar 2023 at 12:47:45 (-0700), pe...@easthope.ca wrote: > > (4) "TLS on connect is not natively supported." OK but the test > confirmed that it can work. Documentation could tell how to > configure. Otherwise link to instructions at least. > > (5) > https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html > states "There is also a -tls-on-connect command line option. This > overrides tls_on_connect_ports; it forces the TLS-only behaviour for > all ports." Connection from the local MUA to exim isn't encrypted. > The command line option will block that? > > What ideas are there to configure TLS-on-connect for localhost to > smarthost and leave MUA to localhost unencrypted on port 25? Just above that paragraph is the example for tls_on_connect_ports, ie tls_on_connect_ports = 465 I assume this goes into the configuration rather than the command line. I've never had to configure at this level without the benefit of a MACRO_PARAMETER to set. For example, I turn off certificate stuff on my LAN with: $ cat /etc/exim4/exim4.conf.localmacros # /etc/exim4/exim4.conf.localmacros MAIN_TLS_ADVERTISE_HOSTS = # $ Lacking a macro, you could try editing either /var/lib/exim4/config.autogenerated (rather like editing grub.cfg, in that reconfiguring Grub will overwrite it), or /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost which is more permanent (keep a backup of original). You might try adding the setting after the first active line in 30_exim4-config_remote_smtp_smarthost, or test it by adding it after line 857 in config.autogenerated (the same text). That assumes that the exim in bullseye supports what's documented for the latest version. Cheers, David.
Re: exim failure
In-reply-to: References: <5319ac62b1294b2290d3d14a6cd8b...@easthope.ca> From: David Wright Date: Sat, 25 Mar 2023 23:34:54 -0500 In the first instance, just try sending a test message using the commands I gave, except starting off with: $ openssl s_client -crlf -connect mail.easthope.ca:465 After the certificate stuff, you should then see lines like: ... And you carry on from there with: AUTH PLAIN encodedstring The test message was transmitted. Good! (1) Section 1. in https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html has "email submission but with TLS immediately upon connect instead of using STARTTLS" is officially blessed by the IETF, and recommended by them in preference to STARTTLS. From the tests, my conclusion is that Island Hosting requires TLS-on-connect & STARTTLS won't work. Consistent with the IETF recommendation. Now all that's needed is to configure exim properly. /usr/share/doc/exim4-base/README.Debian.gz should be a good starting point for documentation but leaves several questions. (2) 2.1.1. The Debconf questions "Since you can usually read this file only after having answered the questions ..." What file? I infer as central concept of the paragraph, "Command 'dpkg-reconfigure exim4-config' takes as input /usr/share/doc/exim4-base/exim4.conf.template and responses from the user and produces as output /usr/share/doc/exim4-base/update-exim4.conf.conf." (3) "Both exim4-daemon-heavy and exim4-daemon-light support TLS/SSL using the GnuTLS library." Isn't openssl the default in Debian? What is the purpose of this sentence about GnuTLS? (4) "TLS on connect is not natively supported." OK but the test confirmed that it can work. Documentation could tell how to configure. Otherwise link to instructions at least. (5) https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html states "There is also a -tls-on-connect command line option. This overrides tls_on_connect_ports; it forces the TLS-only behaviour for all ports." Connection from the local MUA to exim isn't encrypted. The command line option will block that? What ideas are there to configure TLS-on-connect for localhost to smarthost and leave MUA to localhost unencrypted on port 25? Thanks,... P.
Re: exim failure
On Sat 25 Mar 2023 at 19:47:35 (-0700), pe...@easthope.ca wrote: > > That looks fine, and shows that you're going to send through their > > port 465, which will require TLS and authentication. So first you need > > to encode your username and password with: > > > > $ echo -e -n '\0username\0password' | base64 > > ... > > I logged in at https://islandhosting.com/login , dug down a few layers > and lucked onto this. > > "Mail Client Manual Settings > ... > Secure SSL/TLS Settings (Recommended) > Username: pe...@easthope.ca > Password: Use the email account¶s password. > Incoming Server: mail.easthope.ca > > IMAP Port: 993 POP3 Port: 995 > > Outgoing Server: mail.easthope.ca > > SMTP Port: 465 > > IMAP, POP3, and SMTP require authentication." Yes, I got similar but unpersonalised information at: https://islandhosting.com/knowledgebase/21/How-do-I-configure-my-email-client.html > No mention of STARTTLS or TLS on connect. No, just the bit above here: "Secure SSL/TLS Settings (Recommended)" > Tried this > interactive run. > > $ openssl s_client -starttls smtp -crlf -connect mail.easthope.ca:465 In the first instance, just try sending a test message using the commands I gave, except starting off with: $ openssl s_client -crlf -connect mail.easthope.ca:465 After the certificate stuff, you should then see lines like: --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 5093 bytes and written 409 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: EFD2B3AEAA0931063329DA3A26017182365DAA6C5EDC7298FBBB291B8A02752E Session-ID-ctx: Master-Key: +89062342EF919B2EA24ABCBB5C66D643553A888C430BC18E5B764431F31BAC4B949E72DE0910ACB367ADC6B0F9337133 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1679801072 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- 220 hornby.islandhosting.com ESMTP server ready at Sat, 25 Mar 2023 21:33:16 -0700 → EHLO dalton.invalid 250-hornby.islandhosting.com Hello ip12-345-678-90.ks.ks.cox.net [12.345.678.90] 250-SIZE 52428800 250-8BITMIME 250-PIPELINING 250-PIPECONNECT 250-AUTH PLAIN LOGIN 250-SMTPUTF8 250 HELP And you carry on from there with: AUTH PLAIN encodedstring and so on. Cheers, David.
Re: exim failure
In-reply-to: References: <9ef536feee6ec3ae2e3032d22e06d...@easthope.ca> From: David Wright Date: Fri, 24 Mar 2023 23:18:47 -0500 That looks fine, and shows that you're going to send through their port 465, which will require TLS and authentication. So first you need to encode your username and password with: $ echo -e -n '\0username\0password' | base64 ... I logged in at https://islandhosting.com/login , dug down a few layers and lucked onto this. "Mail Client Manual Settings ... Secure SSL/TLS Settings (Recommended) Username: pe...@easthope.ca Password: Use the email account¶s password. Incoming Server:mail.easthope.ca IMAP Port: 993 POP3 Port: 995 Outgoing Server:mail.easthope.ca SMTP Port: 465 IMAP, POP3, and SMTP require authentication." No mention of STARTTLS or TLS on connect. Tried this interactive run. $ openssl s_client -starttls smtp -crlf -connect mail.easthope.ca:465 CONNECTED(0003) Didn't find STARTTLS in server response, trying anyway... write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 341 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- $ The server is using TLS on connect rather than STARTTLS? TLS is seriously broken here? Before trying the interactive process, checked a bunch of details including instructions in https://wiki.debian.org/Exim. Generated fresh /etc/exim4/exim.crt and /etc/exim4/exim.key. Requested delivery of the last message in the queue. $ exim -M 1pgCEl-00010a-4l $ tail -n 1 /var/log/exim4/mainlog 2023-03-25 16:59:30 1pgCEl-00010a-4l == pe...@easthope.ca R=smarthost T=remote_s mtp_smarthost defer (-37) H=easthope.ca [158.69.159.172]: TLS session: (certific ate verification failed) == Notes from reviewing additional details. Noticed that dnsmasq was absent. =8~/ Installed it. Also found this. root@imager:/home/root# cat /etc/resolv.conf domain hitronhub.home search hitronhub.home nameserver 192.168.0.1 https://wiki.debian.org/dnsmasq gave a hint to add 127.0.0.1 as first line. So now this. root@imager:/home/root# cat /etc/resolv.conf nameserver 127.0.0.1 domain hitronhub.home search hitronhub.home nameserver 192.168.0.1 I didn't submit "hitronhub.home". https://en.wikipedia.org/wiki/Top-level_domain#Rejected_domains suggests, to me, that hitronhub.home is a contrivance of the Hitron manufacturer. Came to resolv.conf during system installation? From DHCP? Allows the Hitron box to intercept name resolution requests? Necessary? A source of confusion? Isn't "nameserver 192.168.0.1" enough? Checked a few lookups for interest. $ nslookup easthope.ca Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: Name: easthope.ca Address: 158.69.159.172 $ nslookup mail.easthope.ca Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: mail.easthope.cacanonical name = easthope.ca. Name: easthope.ca Address: 158.69.159.172 $ nslookup islandhosting.com Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: Name: islandhosting.com Address: 192.99.111.180 Name: islandhosting.com Address: 2607:5300:60:925e:: $ nslookup hornby.islandhosting.com Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: Name: hornby.islandhosting.com Address: 158.69.159.172 Name: hornby.islandhosting.com Address: 2607:5300:203:66b5:: $ whois 192.99.111.180 | grep island $ whois 158.69.159.172 | grep island $ Neither IP gets islandhosting.com? Thx,... P.
Re: exim failure
On Thu 23 Mar 2023 at 11:27:17 (-0700), pe...@easthope.ca wrote: > > # /etc/exim4/update-exim4.conf.conf > # > # Most of the heading comments removed. > # > # This is a Debian specific file > > dc_eximconfig_configtype='smarthost' > dc_other_hostnames='' > dc_local_interfaces='127.0.0.1' > dc_readhost='dalton.invalid' > dc_relay_domains='' > dc_minimaldns='false' > dc_relay_nets='' > dc_smarthost='hornby.islandhosting.com::465' > CFILEMODE='644' > dc_use_split_config='false' > dc_hide_mailname='true' > dc_mailname_in_oh='true' > dc_localdelivery='mail_spool' That looks fine, and shows that you're going to send through their port 465, which will require TLS and authentication. So first you need to encode your username and password with: $ echo -e -n '\0username\0password' | base64 You'll need to cut and paste that string in a moment. Bear in mind that you should not reveal or post that string as it's easily decoded. Start your test session with something more like: $ openssl s_client -starttls smtp -crlf -connect hornby.islandhosting.com:465 EHLO dalton.invalid AUTH PLAIN encodedstring where encodedstring is the output from running the echo…base64 command. Note that it's sent encrypted. Unlike the test of exim that you conducted with: > root@dalton:/home/root# exim -bh 142.103.107.137.465 this one will send a real email, which you should get back as recipient. This will be testing your new smarthost, and if it doesn't like you, you should get the error message straightaway, rather than having to decode what exim would have written in its log. There's an example at the bottom. > SMTP testing session as if from host 142.103.107.137 > but without any ident (RFC 1413) callback. > This is not for real! > > > > > host in hosts_connection_nolog? no (option unset) > > > > host in host_lookup? yes (matched "*") > > > > looking up host name for 142.103.107.137 > > > > IP address lookup yielded "dalton.invalid" > > > > checking addresses for dalton.invalid > > > > 127.0.1.1 > > > > 142.103.107.137 OK [ … ] > > > > end of ACL "acl_check_rcpt": not OK > 550 relay not permitted > LOG: H=dalton.invalid [142.103.107.137] F= rejected > RCPT pe...@easthope.ca: relay not permitted Fair enough—exim is configured to send to a "real" smarthost on the Internet: almost no sites allow relaying nowadays (spam). (My exims are set up very differently from yours.) > root@dalton:/home/root# head -n 3 /etc/hosts (BTW you shouldn't need to be root for exim or any of this.) > # dalton:/etc/hosts > 127.0.0.1 localhost.localdomain localhost > 127.0.1.1 dalton.invalid dalton > > Whereas above, exim says this. > > > > > checking addresses for dalton.invalid > > > > 127.0.1.1 > > > > 142.103.107.137 OK > > Seems incorrect to mention 127.0.1.1 and not 127.0.0.1. You started exim with 142.103.107.137. AIUI exim looks that up and gets dalton.invalid (presumably with a local DNS server?). It then looks up dalton.invalid and gets 127.0.1.1 from /etc/hosts. You'd need to start exim with 127.0.0.1 to use localhost. > Eventually exim complains about relaying whereas the test is from > localhost. Here's the example session, suitably mangled: $ openssl s_client -starttls smtp -crlf -connect hornby.islandhosting.com:465 ← CONNECTED(0003) [certificate stuff] --- 250 OK ehlo dalton.invalid ← 250-blablahornby.islandhosting.com hello [158.69.159.172], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 28672000 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 OK auth plain abcdefghijklmnopqrstuvwxyz== ← 235 2.7.0 ... authentication succeeded mail from: pe...@easthope.ca ← 250 2.1.0 sender ok rcpt to: pe...@easthope.ca ← 250 2.1.5 recipient ok data ← from: ← to: ← subject: hand written test 01 ← (blank line) ← 354 enter mail, end with "." on a line by itself Hand written test 01
Re: exim failure
Header lines not handled by Web interface.
In-reply-to:
References: <5674e986a67af53a04b27f08cd161...@easthope.ca>
From: David Wright
Date: Wed, 22 Mar 2023 17:06:20 -0500
What are the contents of /etc/exim4/update-exim4.conf.conf, the
configuration file?
# /etc/exim4/update-exim4.conf.conf
#
# Most of the heading comments removed.
#
# This is a Debian specific file
dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost='dalton.invalid'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='hornby.islandhosting.com::465'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
I assumed you just stared at the screen until this timeout appeared.
My thought was "broken configuration".
You've now got to type something. It will then talk back to you.
Try typing (ignore my indentation):
ehlo dalton.invalid ← that's not a typo
mail from: pe...@easthope.ca
rcpt to: pe...@easthope.ca
data
from: pe...@easthope.ca
to: pe...@easthope.ca
subject: hand written test 01
← that's a blank line
Hand written test 01
.← that's nothing but a fullstop
Return
quit
root@dalton:/home/root# exim -bh 142.103.107.137.465
SMTP testing session as if from host 142.103.107.137
but without any ident (RFC 1413) callback.
This is not for real!
host in hosts_connection_nolog? no (option unset)
host in host_lookup? yes (matched "*")
looking up host name for 142.103.107.137
IP address lookup yielded "dalton.invalid"
checking addresses for dalton.invalid
127.0.1.1
142.103.107.137 OK
host in host_reject_connection? no (option unset)
host in sender_unqualified_hosts? no (option unset)
host in recipient_unqualified_hosts? no (option unset)
host in helo_verify_hosts? no (option unset)
host in helo_try_verify_hosts? no (option unset)
host in helo_accept_junk_hosts? no (option unset)
host in pipelining_connect_advertise_hosts? yes (matched "*")
220 dalton.invalid ESMTP Exim 4.94.2 Thu, 23 Mar 2023 10:45:12 -0700
ehlo dalton.invalid
host in dsn_advertise_hosts? no (option unset)
host in pipelining_advertise_hosts? yes (matched "*")
host in auth_advertise_hosts? yes (matched "*")
host in chunking_advertise_hosts? yes (matched "*")
host in tls_advertise_hosts? yes (matched "*")
host in smtputf8_advertise_hosts? no (end of list)
250-dalton.invalid Hello dalton.invalid [142.103.107.137]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-PIPE_CONNECT
250-CHUNKING
250-STARTTLS
250-PRDR
250 HELP
mail from: pe...@easthope.ca
using ACL "acl_check_mail"
processing "accept" (/var/lib/exim4/config.autogenerated 265)
accept: condition test succeeded in ACL "acl_check_mail"
end of ACL "acl_check_mail": ACCEPT
250 OK
rcpt to: pe...@easthope.ca
using ACL "acl_check_rcpt"
processing "accept" (/var/lib/exim4/config.autogenerated 277)
check hosts = :
host in ":"? no (end of list)
accept: condition test failed in ACL "acl_check_rcpt"
processing "deny" (/var/lib/exim4/config.autogenerated 292)
check domains = +local_domains
easthope.ca in "@:localhost"? no (end of list)
easthope.ca in "+local_domains"? no (end of list)
deny: condition test failed in ACL "acl_check_rcpt"
processing "deny" (/var/lib/exim4/config.autogenerated 301)
check domains = !+local_domains
easthope.ca in "!+local_domains"? yes (end of list)
check local_parts = ^[./|] : ^.*[@%!`#&?] : ^.*/\\.\\./
peter in "^[./|] : ^.*[@%!`#&?] : ^.*/\.\./"? no (end of list)
deny: condition test failed in ACL "acl_check_rcpt"
processing "accept" (/var/lib/exim4/config.autogenerated 307)
check local_parts = postmaster
peter in "postmaster"? no (end of list)
accept: condition test failed in ACL "acl_check_rcpt"
processing "deny" (/var/lib/exim4/config.autogenerated 322)
check !acl = acl_local_deny_exceptions
using ACL "acl_local_deny_exceptions"
processing "accept" (/var/lib/exim4/config.autogenerated 238)
check hosts = ${if
exists{/etc/exim4/host_local_deny_exceptions}{/etc/exim4/host_local_deny_exceptions}{}}
host in ""? no (end of list)
accept: condition test failed in ACL "acl_local_deny_exceptions"
processing "accept" (/var/lib/exim4/config.autogenerated 242)
check senders = ${if
exists{/etc/exim4/sender_local_deny_exceptions}{/etc/exim4/sender_local_deny_exceptions}{}}
pe...@easthope.ca in ""? no (end of list)
accept: con
Re: exim failure
On Wed 22 Mar 2023 at 13:52:00 (-0700), pe...@easthope.ca wrote: > > After configuring exim for a new smarthost, message sending fails. What are the contents of /etc/exim4/update-exim4.conf.conf, the configuration file? > This might help to identify the problem. > > root@dalton:/home/root# exim -bh 142.103.1m.1n I've not used this facility before, but it seems to work: > SMTP testing session as if from host 142.103.1m.1n > but without any ident (RFC 1413) callback. > This is not for real! > > > > > host in hosts_connection_nolog? no (option unset) > > > > host in host_lookup? yes (matched "*") > > > > looking up host name for 142.103.1m.1n > > > > IP address lookup yielded "dalton.invalid" > > > > checking addresses for dalton.invalid > > > > 142.103.1m.1n OK > > > > host in host_reject_connection? no (option unset) > > > > host in sender_unqualified_hosts? no (option unset) > > > > host in recipient_unqualified_hosts? no (option unset) > > > > host in helo_verify_hosts? no (option unset) > > > > host in helo_try_verify_hosts? no (option unset) > > > > host in helo_accept_junk_hosts? no (option unset) > > > > host in pipelining_connect_advertise_hosts? yes (matched "*") > 220 dalton.invalid ESMTP Exim 4.94.2 Wed, 22 Mar 2023 13:02:25 -0700 > > LOG: SMTP syntax error in "" H=dalton.invalid [142.103.1m.1n] ↑↑ So there's a syntax command in the empty string, which would be a reasonable reaction from exim. > unrecognized command > 500 unrecognized command > LOG: SMTP command timeout on connection from dalton.invalid > [142.103.1m.1n] > 421 dalton.invalid: SMTP command timeout - closing connection > root@dalton:/home/root# I assumed you just stared at the screen until this timeout appeared. From man exim: -bh This option runs a fake SMTP session as if from the given IP address, using the standard input and output. The IP address may include a port number at the end, after a full stop. For example: exim4 -bh 10.9.8.7.1234 You've now got to type something. It will then talk back to you. Try typing (ignore my indentation): ehlo dalton.invalid ← that's not a typo mail from: pe...@easthope.ca rcpt to: pe...@easthope.ca data from: pe...@easthope.ca to: pe...@easthope.ca subject: hand written test 01 ← that's a blank line Hand written test 01 .← that's nothing but a fullstop Return quit How far you get in this conversation depends what it says back. You want to see several 250s, and a 354 after you type DATA. > A test message produces this in /var/log/exim4/mainlog > > 2023-03-22 13:39:10 1pf5Ek-gQ-Dk <= pe...@easthope.ca > H=localhost.localdomain (dalton) [127.0.0.1] P=smtp S=586 Yes, that does look somewhat lacking. > 2023-03-22 13:39:10 1pf5Ek-gQ-Dk == pe...@easthope.ca R=smarthost > T=remote_smtp_smarthost defer (-53): retry time not reached for any host for > 'easthope.ca' Cheers, David.
exim failure
Hi, In case this message is duplicated, apology in advance. After configuring exim for a new smarthost, message sending fails. This might help to identify the problem. root@dalton:/home/root# exim -bh 142.103.1m.1n SMTP testing session as if from host 142.103.1m.1n but without any ident (RFC 1413) callback. This is not for real! host in hosts_connection_nolog? no (option unset) host in host_lookup? yes (matched "*") looking up host name for 142.103.1m.1n IP address lookup yielded "dalton.invalid" checking addresses for dalton.invalid 142.103.1m.1n OK host in host_reject_connection? no (option unset) host in sender_unqualified_hosts? no (option unset) host in recipient_unqualified_hosts? no (option unset) host in helo_verify_hosts? no (option unset) host in helo_try_verify_hosts? no (option unset) host in helo_accept_junk_hosts? no (option unset) host in pipelining_connect_advertise_hosts? yes (matched "*") 220 dalton.invalid ESMTP Exim 4.94.2 Wed, 22 Mar 2023 13:02:25 -0700 LOG: SMTP syntax error in "" H=dalton.invalid [142.103.1m.1n] unrecognized com mand 500 unrecognized command LOG: SMTP command timeout on connection from dalton.invalid [142.103.1m.1n] 421 dalton.invalid: SMTP command timeout - closing connection root@dalton:/home/root# A test message produces this in /var/log/exim4/mainlog 2023-03-22 13:39:10 1pf5Ek-gQ-Dk <= pe...@easthope.ca H=localhost.localdomai n (dalton) [127.0.0.1] P=smtp S=586 2023-03-22 13:39:10 1pf5Ek-gQ-Dk == pe...@easthope.ca R=smarthost T=remote_s mtp_smarthost defer (-53): retry time not reached for any host for 'easthope.ca' How can the origin of "SMTP syntax error" be found? Is the correction known already? Thx, ... P.
Re: exim update not responding to update-rc.d
Am 07.05.21 um 02:12 schrieb Michael Biebl: exim4 is unfortunately still SysV-only and doesn't ship a native systemd .service file. So the correct command is "update-rc.d exim4 disable" For the curious: you can run "systemctl disable exim4" as well. This will just run the above command though via /lib/systemd/systemd-sysv-install It's a thin wrapper to make systemctl more convenient to use and you don't need to remember whether a service has a native .service unit file or still ships only a legacy SysV init script. OpenPGP_signature Description: OpenPGP digital signature
Re: exim update not responding to update-rc.d
exim4 is unfortunately still SysV-only and doesn't ship a native systemd .service file. So the correct command is "update-rc.d exim4 disable" "update-rc.d exim4 remove" will remove the symlinks in /etc/rc?.d/ but on the next package update, they will be recreated. So if you want to make this a permanent change, use "disable" man update-rc.d has a section "DISABLING INIT SCRIPT START LINKS" Regards, Michael signature.asc Description: This is a digitally signed message part
Re: exim update not responding to update-rc.d
On Wed, May 05, 2021 at 05:27:13PM +0300, Andrei POPESCU wrote: > On Mi, 05 mai 21, 07:46:03, Greg Wooledge wrote: > > > > You're using a package that has not yet been converted to systemd. It's > > still using an old init.d script, and systemd is performing a conversion > > on the fly. > > > > The basic start and stop subcommands will work fine, but disable may > > not work. It's not clear from the systemd-sysv-generator man page, but my > > guess is that the auto-generation of systemd units takes place in memory > > at boot time, and applies to all the init.d scripts that systemd sees. > > Doing a "disable" after this would only affect the generated services, > > which are ephemeral and go away when you reboot. > > As far as I recall (but it's been a while since I needed this) > update-rc.d is the correct tool and it should even take care of > synchronizing state between systemd and sysv-rc. Hmm. Well, I suppose it's possible, especially if the OP kept using the wrong filename (exim vs. exim4). I still wouldn't care to try it, personally. Knowing that it's a native init.d service, I would use the appropriate tools for that. > In any case, masking should work as the symlink to /dev/null is in /etc. > > systemctl mask exim4.service That would, of course, prevent "start" and "stop" from working on it in the future. Which makes me wonder why on earth the OP wants to disable exim4 in the first place. I smell an X-Y problem here.
Re: exim update not responding to update-rc.d
On Mi, 05 mai 21, 07:46:03, Greg Wooledge wrote: > > You're using a package that has not yet been converted to systemd. It's > still using an old init.d script, and systemd is performing a conversion > on the fly. > > The basic start and stop subcommands will work fine, but disable may > not work. It's not clear from the systemd-sysv-generator man page, but my > guess is that the auto-generation of systemd units takes place in memory > at boot time, and applies to all the init.d scripts that systemd sees. > Doing a "disable" after this would only affect the generated services, > which are ephemeral and go away when you reboot. As far as I recall (but it's been a while since I needed this) update-rc.d is the correct tool and it should even take care of synchronizing state between systemd and sysv-rc. > To permanently disable the starting of this service, you'll need to > use the actual sysv-rc techniques (either removing or renaming symlinks, > or using Debian's weird update-rc.d tool which relies on parsing comments > inside the init.d script). In any case, masking should work as the symlink to /dev/null is in /etc. systemctl mask exim4.service Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: exim update not responding to update-rc.d
On Wed, May 05, 2021 at 12:07:29PM +0100, Joe wrote: > On Tue, 4 May 2021 18:44:12 -0400 > Greg Wooledge wrote: > > > > Could you kindly tell us what "systemctl status exim4.service" says > > on this buster machine of yours? Perhaps your command is turning up > > one of the automatically converted init.d scripts. If so, this will > > be made clear in the systemctl status report. > > ● exim4.service - LSB: exim Mail Transport Agent >Loaded: loaded (/etc/init.d/exim4; generated) >Active: active (running) since Wed 2021-03-31 08:38:00 BST; 1 months > 4 days ago Docs: man:systemd-sysv-generator(8) > Tasks: 1 (limit: 2062) >CGroup: /system.slice/exim4.service >└─6453 /usr/sbin/exim4 -bd -q30m Yes, that's what I saw on my single buster exim4 system as well. Note the "Loaded:" line which shows that this is using a converted init.d script, and not a native systemd unit. It also tells you which man page to read, to learn more about the automatic conversion of init.d scripts into systemd units. Not that this man page says very much, but at least it's there. (Note that it also tells you the full name of the init.d script, in this case "exim4". Not "exim".) > Probably worth mentioning that this is on a Raspberry Pi, the current > version of RasPiOs (formerly Raspbian) with a default exim4 > installation. Yes, thank you. In this case it looks like they haven't changed the startup configuration from the Debian packages, but you never know. In the future, please refrain from calling non-Debian systems by Debian release names. It just adds another layer of confusion. > all configuration for the Exim MTA (v4) ii exim4-daemon-light > 4.92-8+deb10u5armhf > lightweight Exim MTA (v4) daemon Or they're literally using the Debian packages, and didn't even rebuild them. > I have the same service on my main server (stretch) where it is the > network MTA and also on my sid workstation. Again, I didn't do anything > to achieve this. Presumably it's using an init.d script, but it > certainly works to start and stop exim4 via systemctl. You're using a package that has not yet been converted to systemd. It's still using an old init.d script, and systemd is performing a conversion on the fly. The basic start and stop subcommands will work fine, but disable may not work. It's not clear from the systemd-sysv-generator man page, but my guess is that the auto-generation of systemd units takes place in memory at boot time, and applies to all the init.d scripts that systemd sees. Doing a "disable" after this would only affect the generated services, which are ephemeral and go away when you reboot. To permanently disable the starting of this service, you'll need to use the actual sysv-rc techniques (either removing or renaming symlinks, or using Debian's weird update-rc.d tool which relies on parsing comments inside the init.d script).
Re: exim update not responding to update-rc.d
On Tue, 4 May 2021 18:44:12 -0400 Greg Wooledge wrote: > On Tue, May 04, 2021 at 10:14:45PM +0100, Joe wrote: > > ...and buster. It's exim4.service as stated by: > > systemctl --type=service | grep exim > > According to packages.debian.org[1] there is no such file in any > package. > > Of course, that's not proof of the nonexistence of such a file, > because it might have been created by some postinst script. In > theory. > > Could you kindly tell us what "systemctl status exim4.service" says > on this buster machine of yours? Perhaps your command is turning up > one of the automatically converted init.d scripts. If so, this will > be made clear in the systemctl status report. ● exim4.service - LSB: exim Mail Transport Agent Loaded: loaded (/etc/init.d/exim4; generated) Active: active (running) since Wed 2021-03-31 08:38:00 BST; 1 months 4 days ago Docs: man:systemd-sysv-generator(8) Tasks: 1 (limit: 2062) CGroup: /system.slice/exim4.service └─6453 /usr/sbin/exim4 -bd -q30m > > It would also be helpful to know which of the multiple different exim4 > package sets you're working with. Probably worth mentioning that this is on a Raspberry Pi, the current version of RasPiOs (formerly Raspbian) with a default exim4 installation. sudo dpkg -l | grep exim ii exim4 4.92-8+deb10u5 all metapackage to ease Exim MTA (v4) installation ii exim4-base 4.92-8+deb10u5 armhfsupport files for all Exim MTA (v4) packages ii exim4-config 4.92-8+deb10u5 all configuration for the Exim MTA (v4) ii exim4-daemon-light 4.92-8+deb10u5armhf lightweight Exim MTA (v4) daemon > Perhaps this alleged exim4.service > comes from the -heavy daemon package. All I can tell you is that on > the buster system that I checked, which is using the > exim4-daemon-light package, there is *no* exim4.service, but there > *is* an init.d script, and systemctl status exim4 shows this plainly. > > [1] > https://packages.debian.org/search?searchon=contents&keywords=exim4.service&mode=exactfilename&suite=stable&arch=any > I have the same service on my main server (stretch) where it is the network MTA and also on my sid workstation. Again, I didn't do anything to achieve this. Presumably it's using an init.d script, but it certainly works to start and stop exim4 via systemctl. -- Joe
Re: exim update not responding to update-rc.d
On Tue, May 04, 2021 at 10:14:45PM +0100, Joe wrote: > ...and buster. It's exim4.service as stated by: > systemctl --type=service | grep exim According to packages.debian.org[1] there is no such file in any package. Of course, that's not proof of the nonexistence of such a file, because it might have been created by some postinst script. In theory. Could you kindly tell us what "systemctl status exim4.service" says on this buster machine of yours? Perhaps your command is turning up one of the automatically converted init.d scripts. If so, this will be made clear in the systemctl status report. It would also be helpful to know which of the multiple different exim4 package sets you're working with. Perhaps this alleged exim4.service comes from the -heavy daemon package. All I can tell you is that on the buster system that I checked, which is using the exim4-daemon-light package, there is *no* exim4.service, but there *is* an init.d script, and systemctl status exim4 shows this plainly. [1] https://packages.debian.org/search?searchon=contents&keywords=exim4.service&mode=exactfilename&suite=stable&arch=any
Re: exim update not responding to update-rc.d
On Tue, 4 May 2021 18:27:57 +0100 Joe wrote: > On Tue, 4 May 2021 13:15:51 -0400 > Greg Wooledge wrote: > > > On Tue, May 04, 2021 at 10:03:43AM -0700, John Conover wrote: > > > That was the question, Greg: > > > > > > "Searching for exim in > > > /etc/systemd/system/multi-user.target.wants/* and > > > /lib/systemd/system/* yields nothing." > > > > > > so, it wasn't there. Which service?, (or how to find out?) > > > > So... I looked around for a buster system with exim. It looks like > > exim on buster was never converted to a systemd startup. It's still > > using legacy /etc/init.d/exim4 which is a big ol' honkin' script. > > > > So, you need to apply sysv-rc methods to work with it. Normally > > this means you cd into /etc/rc2.d and rename the S* symlink so that > > it won't start up. > > > > It's a systemd service on stretch and sid. > ...and buster. It's exim4.service as stated by: systemctl --type=service | grep exim -- Joe
Re: exim update not responding to update-rc.d
On Tue, May 04, 2021 at 01:46:29PM -0700, John Conover wrote: > > Try: > > man update-rc.d > man 8 update-rc.d > Please stop top-posting, and please reply to the list. > Greg Wooledge writes: > > On Tue, May 04, 2021 at 01:27:56PM -0700, John Conover wrote: > > > As per the man page for System V init, to disable launching of exim: > > > > > > update-rc.d -f exim remove > > > > What man page is this allegedly from, exactly? unicorn:~$ man update-rc.d | grep exim unicorn:~$ man 8 update-rc.d | grep exim unicorn:~$ I asked what man page it's from, because whatever man page is saying that the name of the init.d script for exim4 is "exim" needs to be fixed. It's obviously "exim4", and a competent sysadmin would verify this by LOOKING IN THE DIRECTORY. But I'm getting the impression that this is *not* in fact a direct quote from any Debian man page, but rather, a failed assumption on the part of the OP.
Re: exim update not responding to update-rc.d
On Tue, May 04, 2021 at 01:27:56PM -0700, John Conover wrote: > As per the man page for System V init, to disable launching of exim: > > update-rc.d -f exim remove What man page is this allegedly from, exactly?
Re: exim update not responding to update-rc.d
For the archives, this issue was created by looking for penetration vulnerabilities during the boot of a Debian Buster machine using tcpdump(1) on a machine between Buster, and the it's Internet facing router. There was exim traffic when exim boots, but exim was SUPPOSED to be disabled during boot by policy. As per the man page for System V init, to disable launching of exim: update-rc.d -f exim remove which would be (re-)enabled with: update-rc.d -f exim defaults which installs the ln -s files in /etc/rc*.d, as appropriate. The correct command on Buster is: update-rc.d -f exim4 remove It was discovered during routine security audit of iptables(1) configuration, (specifically, IPv6.) John john doe writes: > On 5/4/2021 7:28 PM, Erwan David wrote: > > Le 04/05/2021 à 19:26, Joe a écrit : > >> On Tue, 4 May 2021 10:03:43 -0700 > >> cono...@rahul.net (John Conover) wrote: > >> > >>> Greg Wooledge writes: > >>>> On Tue, May 04, 2021 at 09:17:38AM -0700, John Conover wrote: > >>>>> Searching for exim in > >>>>> /etc/systemd/system/multi-user.target.wants/* and > >>>>> /lib/systemd/system/* yields nothing. > >>>>> > >>>>> How do I stop exim from launching across boots? > >>>> Presumably there is a systemd service, which is enabled. You will > >>>> want to disable it. > >>>> > >>> That was the question, Greg: > >>> > >>> "Searching for exim in > >>> /etc/systemd/system/multi-user.target.wants/* and > >>> /lib/systemd/system/* yields nothing." > >>> > >>> so, it wasn't there. Which service?, (or how to find out?) Or, maybe, > >>> it is under /etc/init.d/exim4, which failed to work, so, I was looking > >>> into the systemd control files. > >>> > >> Try exim4.service > >> > > apt-file tells me trhere is a exim4-base.service (from package exim4-base) > > > > You could look in the log for the service name then do 'systemctl > disable '. > > I just want to mention 'inserv' but you should use systemd. > > -- > John Doe -- John Conover, cono...@rahul.net, http://www.johncon.com/
Re: exim update not responding to update-rc.d
On 5/4/2021 7:28 PM, Erwan David wrote: Le 04/05/2021 à 19:26, Joe a écrit : On Tue, 4 May 2021 10:03:43 -0700 cono...@rahul.net (John Conover) wrote: Greg Wooledge writes: On Tue, May 04, 2021 at 09:17:38AM -0700, John Conover wrote: Searching for exim in /etc/systemd/system/multi-user.target.wants/* and /lib/systemd/system/* yields nothing. How do I stop exim from launching across boots? Presumably there is a systemd service, which is enabled. You will want to disable it. That was the question, Greg: "Searching for exim in /etc/systemd/system/multi-user.target.wants/* and /lib/systemd/system/* yields nothing." so, it wasn't there. Which service?, (or how to find out?) Or, maybe, it is under /etc/init.d/exim4, which failed to work, so, I was looking into the systemd control files. Try exim4.service apt-file tells me trhere is a exim4-base.service (from package exim4-base) You could look in the log for the service name then do 'systemctl disable '. I just want to mention 'inserv' but you should use systemd. -- John Doe
Re: exim update not responding to update-rc.d
On Tue, May 04, 2021 at 10:27:17AM -0700, John Conover wrote: > > Thanks, Greg. "update-rc.d -f exim remove" is the command for > /etc/init.d. But its broken. You forgot to reply to the list. Nobody with any sense uses update-rc.d for system admin work. It's there for Debian packages to use, and god only knows what it will do if you actually try to use it. As a sysadmin, you're expected to handle the symlinks yourself. So just go to /etc/rc2.d/ and rename S04exim4 to something that doesn't start with an S. I personally use "disabled.S04exim4" or whatever, so that I have the original name with its sequence number available when I want to put it back to how it was originally.
Re: exim update not responding to update-rc.d
Le 04/05/2021 à 19:26, Joe a écrit : > On Tue, 4 May 2021 10:03:43 -0700 > cono...@rahul.net (John Conover) wrote: > >> Greg Wooledge writes: >>> On Tue, May 04, 2021 at 09:17:38AM -0700, John Conover wrote: >>>> Searching for exim in >>>> /etc/systemd/system/multi-user.target.wants/* and >>>> /lib/systemd/system/* yields nothing. >>>> >>>> How do I stop exim from launching across boots? >>> Presumably there is a systemd service, which is enabled. You will >>> want to disable it. >>> >> That was the question, Greg: >> >> "Searching for exim in >> /etc/systemd/system/multi-user.target.wants/* and >> /lib/systemd/system/* yields nothing." >> >> so, it wasn't there. Which service?, (or how to find out?) Or, maybe, >> it is under /etc/init.d/exim4, which failed to work, so, I was looking >> into the systemd control files. >> > Try exim4.service > apt-file tells me trhere is a exim4-base.service (from package exim4-base)
Re: exim update not responding to update-rc.d
On Tue, 4 May 2021 13:15:51 -0400 Greg Wooledge wrote: > On Tue, May 04, 2021 at 10:03:43AM -0700, John Conover wrote: > > That was the question, Greg: > > > > "Searching for exim in > > /etc/systemd/system/multi-user.target.wants/* and > > /lib/systemd/system/* yields nothing." > > > > so, it wasn't there. Which service?, (or how to find out?) > > So... I looked around for a buster system with exim. It looks like > exim on buster was never converted to a systemd startup. It's still > using legacy /etc/init.d/exim4 which is a big ol' honkin' script. > > So, you need to apply sysv-rc methods to work with it. Normally this > means you cd into /etc/rc2.d and rename the S* symlink so that it > won't start up. > It's a systemd service on stretch and sid. -- Joe
Re: exim update not responding to update-rc.d
On Tue, 4 May 2021 10:03:43 -0700 cono...@rahul.net (John Conover) wrote: > Greg Wooledge writes: > > On Tue, May 04, 2021 at 09:17:38AM -0700, John Conover wrote: > > > Searching for exim in > > > /etc/systemd/system/multi-user.target.wants/* and > > > /lib/systemd/system/* yields nothing. > > > > > > How do I stop exim from launching across boots? > > > > Presumably there is a systemd service, which is enabled. You will > > want to disable it. > > > > That was the question, Greg: > > "Searching for exim in > /etc/systemd/system/multi-user.target.wants/* and > /lib/systemd/system/* yields nothing." > > so, it wasn't there. Which service?, (or how to find out?) Or, maybe, > it is under /etc/init.d/exim4, which failed to work, so, I was looking > into the systemd control files. > Try exim4.service -- Joe
Re: exim update not responding to update-rc.d
On Tue, May 04, 2021 at 10:03:43AM -0700, John Conover wrote: > That was the question, Greg: > > "Searching for exim in > /etc/systemd/system/multi-user.target.wants/* and > /lib/systemd/system/* yields nothing." > > so, it wasn't there. Which service?, (or how to find out?) So... I looked around for a buster system with exim. It looks like exim on buster was never converted to a systemd startup. It's still using legacy /etc/init.d/exim4 which is a big ol' honkin' script. So, you need to apply sysv-rc methods to work with it. Normally this means you cd into /etc/rc2.d and rename the S* symlink so that it won't start up. Good luck.
Re: exim update not responding to update-rc.d
Greg Wooledge writes: > On Tue, May 04, 2021 at 09:17:38AM -0700, John Conover wrote: > > Searching for exim in /etc/systemd/system/multi-user.target.wants/* > > and /lib/systemd/system/* yields nothing. > > > > How do I stop exim from launching across boots? > > Presumably there is a systemd service, which is enabled. You will want > to disable it. > That was the question, Greg: "Searching for exim in /etc/systemd/system/multi-user.target.wants/* and /lib/systemd/system/* yields nothing." so, it wasn't there. Which service?, (or how to find out?) Or, maybe, it is under /etc/init.d/exim4, which failed to work, so, I was looking into the systemd control files. Thanks, John -- John Conover, cono...@rahul.net, http://www.johncon.com/
Re: exim update not responding to update-rc.d
On Tue, May 04, 2021 at 09:17:38AM -0700, John Conover wrote: > Searching for exim in /etc/systemd/system/multi-user.target.wants/* > and /lib/systemd/system/* yields nothing. > > How do I stop exim from launching across boots? Presumably there is a systemd service, which is enabled. You will want to disable it. So, figure out the name of this service (assuming it does in fact exist), and then issue the command: systemctl disable servicename as root, of course. That will make it refrain from starting up at the next boot. To stop it right now, also issue this command: systemctl stop servicename Or, if you prefer, you can combine the two: systemctl --now disable servicename
exim update not responding to update-rc.d
I use either exim or another MTA. When I want to use the other MTA, "update-rc.d -f exim remove" does not remove exim from "ps eax" after today's exim update. Searching for exim in /etc/systemd/system/multi-user.target.wants/* and /lib/systemd/system/* yields nothing. How do I stop exim from launching across boots? Thanks, John -- John Conover, cono...@rahul.net, http://www.johncon.com/
Re: Best practive for TLS/DNS Setup for exim
Rainer Dorsch wrote: > Am Montag, 18. Mai 2020, 19:58:06 CEST schrieb Dan Ritter: > > Rainer Dorsch wrote: > > I think you're overcomplicating it. > > > > Your domain can and should have two or more MX records, with > > different priority levels. The MX records don't even have to > > point to names in your domain. > > > > Since you're using Let's Encrypt, certificates are free. So, > > for each mail server, set up an A and/or record. Add those > > to the MX records for your domain. Have LE produce certificates > > for the mail servers under the names they have assigned. > > > > Any mail sender will try each of your MX records, stopping when > > it gets to a working entry. Some spammers will try in reverse > > order, hoping that you don't have anti-spam measures on your > > secondary mail server. > > > > Just curious, if I have multiple MX records, how would you sync the incoming > emails (*) ? I can see with an NFS mounted home directory with Maildir > mailboxes that could work and dovecot could probably run on multiple hosts > (or > at least it would be possible to switch the imap DNS entry if needed). But > then the NFS server is the single point of failure. Are there better ways to > sync the mail servers behind the MX records than NFS? Yes. dovecot-sync is quite fast relative to most mailservers. -dsr-
Re: Best practive for TLS/DNS Setup for exim
On Tue, May 19, 2020 at 05:10:33PM +0200, Rainer Dorsch wrote: > Just curious, if I have multiple MX records, how would you sync the incoming > emails (*) ? I can see with an NFS mounted home directory with Maildir > mailboxes that could work and dovecot could probably run on multiple hosts > (or > at least it would be possible to switch the imap DNS entry if needed). But > then the NFS server is the single point of failure. Are there better ways to > sync the mail servers behind the MX records than NFS? You're assuming the secondary MX performs actual local deliveries. That's not normally the case. A secondary MX usually just queues up the messages for SMTP delivery to the primary MX.
Re: Best practive for TLS/DNS Setup for exim
Am Montag, 18. Mai 2020, 19:58:06 CEST schrieb Dan Ritter: > Rainer Dorsch wrote: > > Hi, > > > > I am just wondering how a efficient setup for TLS/DNS for exim looks like: > > > > Right now I have an A entry in the DNS server for smtp. and a > > letsencrypt certificate as well. > > > > If I setup a new server and call it SMTP2, I need to reconfigure this in > > all my email clients. If I install the SMTP certificates, testing is > > somewhat limited, since the DNS entry still points to another server and > > I would need to fake this. > > > > Does anybody know if I can have a certificate for . > > and use for smtp a CNAME? > > > > The advantage I would see is that I can have a fully functional config and > > with disabling the SMTP name on the old system and changing the CNAME in > > the DNS system, I could be done. > > > > Does anybody now if the standard email clients can handle the situation in > > which them get as SMTP server a cname and as certificate the > > the > > SMTP cname points to? > > I think you're overcomplicating it. > > Your domain can and should have two or more MX records, with > different priority levels. The MX records don't even have to > point to names in your domain. > > Since you're using Let's Encrypt, certificates are free. So, > for each mail server, set up an A and/or record. Add those > to the MX records for your domain. Have LE produce certificates > for the mail servers under the names they have assigned. > > Any mail sender will try each of your MX records, stopping when > it gets to a working entry. Some spammers will try in reverse > order, hoping that you don't have anti-spam measures on your > secondary mail server. > Just curious, if I have multiple MX records, how would you sync the incoming emails (*) ? I can see with an NFS mounted home directory with Maildir mailboxes that could work and dovecot could probably run on multiple hosts (or at least it would be possible to switch the imap DNS entry if needed). But then the NFS server is the single point of failure. Are there better ways to sync the mail servers behind the MX records than NFS? Thanks Rainer (*) it would be some fun to present to the user multiple mail boxes and emails are "randomly" distributed into them :-D -- Rainer Dorsch http://bokomoko.de/
Re: Best practive for TLS/DNS Setup for exim
Am Dienstag, 19. Mai 2020, 16:15:36 CEST schrieb Dan Ritter: > Rainer Dorsch wrote: > > Am Montag, 18. Mai 2020, 20:50:49 CEST schrieb Dan Ritter: > > > Rainer Dorsch wrote: > > > > I was more concerned about the outgoing server configured in the email > > > > clients and used to send main from my domain (at least so far I did > > > > not > > > > understand that they can make use of the MX record). > > > > > > It depends on the MTA you choose for your email clients, but > > > unless you choose the very simplest systems, they can be > > > configured to look up the MX record and use that. (Postfix has a > > > fallback_relay option, Exim can accept multiple hosts in a > > > route_list statement, and so forth.) > > > > Thanks again for your reply. > > > > But what about a client like Thunderbird, kmail or Android mail clients. > > They need an *outgoing* server. > > > > Do they handle MX records? > > No, if you need high availability for those, you need load > balancing. DNS is not a good way of doing that; consider > ldirectord or haproxy or pound, and remember that you will need > at least two of those machines in a STONITH configuration. > > In any of these cases, you'll configure all your mail servers to > answer as smtp.domain with the same TLS certificate. Many thanks, again. No HA was here not my primary motivation here. It seems I have to 1. Setup exim (done by now) 2. copy TLS certificates for smtp. to new server 3. for testing tweak dns for a client to resolve smtp. to the new server 4. changing the smtp. entry to new server 5. setup certbot to update the copied smtp TLS certificates I hoped I get around copying the TLS certificates and then get certbot running an tweaking DNS of the client by 1. get TLS certificate for smtp2. 2. Setup exim 3. test with smtp2. 4. change DNS entry to e.g. make smtp CNAME smtp2 I see the last step does not work, but it is not a big hassle overall to follow the first procedure (I hope :-) ) Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Best practive for TLS/DNS Setup for exim
Rainer Dorsch wrote: > Am Montag, 18. Mai 2020, 20:50:49 CEST schrieb Dan Ritter: > > Rainer Dorsch wrote: > > > I was more concerned about the outgoing server configured in the email > > > clients and used to send main from my domain (at least so far I did not > > > understand that they can make use of the MX record). > > > > It depends on the MTA you choose for your email clients, but > > unless you choose the very simplest systems, they can be > > configured to look up the MX record and use that. (Postfix has a > > fallback_relay option, Exim can accept multiple hosts in a > > route_list statement, and so forth.) > > Thanks again for your reply. > > But what about a client like Thunderbird, kmail or Android mail clients. They > need an *outgoing* server. > > Do they handle MX records? No, if you need high availability for those, you need load balancing. DNS is not a good way of doing that; consider ldirectord or haproxy or pound, and remember that you will need at least two of those machines in a STONITH configuration. In any of these cases, you'll configure all your mail servers to answer as smtp.domain with the same TLS certificate. -dsr-
Re: Best practive for TLS/DNS Setup for exim
Am Montag, 18. Mai 2020, 20:50:49 CEST schrieb Dan Ritter: > Rainer Dorsch wrote: > > Am Montag, 18. Mai 2020, 19:58:06 CEST schrieb Dan Ritter: > > > I think you're overcomplicating it. > > > > > > Your domain can and should have two or more MX records, with > > > different priority levels. The MX records don't even have to > > > point to names in your domain. > > > > > > Since you're using Let's Encrypt, certificates are free. So, > > > for each mail server, set up an A and/or record. Add those > > > to the MX records for your domain. Have LE produce certificates > > > for the mail servers under the names they have assigned. > > > > > > Any mail sender will try each of your MX records, stopping when > > > it gets to a working entry. Some spammers will try in reverse > > > order, hoping that you don't have anti-spam measures on your > > > secondary mail server. > > > > Thanks, Dan, for your quick reply. I was not concerned about incoming mail > > to my domain using the MX record. > > > > I was more concerned about the outgoing server configured in the email > > clients and used to send main from my domain (at least so far I did not > > understand that they can make use of the MX record). > > It depends on the MTA you choose for your email clients, but > unless you choose the very simplest systems, they can be > configured to look up the MX record and use that. (Postfix has a > fallback_relay option, Exim can accept multiple hosts in a > route_list statement, and so forth.) Thanks again for your reply. But what about a client like Thunderbird, kmail or Android mail clients. They need an *outgoing* server. Do they handle MX records? Thanks Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Best practive for TLS/DNS Setup for exim
Rainer Dorsch wrote: > Am Montag, 18. Mai 2020, 19:58:06 CEST schrieb Dan Ritter: > > I think you're overcomplicating it. > > > > Your domain can and should have two or more MX records, with > > different priority levels. The MX records don't even have to > > point to names in your domain. > > > > Since you're using Let's Encrypt, certificates are free. So, > > for each mail server, set up an A and/or record. Add those > > to the MX records for your domain. Have LE produce certificates > > for the mail servers under the names they have assigned. > > > > Any mail sender will try each of your MX records, stopping when > > it gets to a working entry. Some spammers will try in reverse > > order, hoping that you don't have anti-spam measures on your > > secondary mail server. > > Thanks, Dan, for your quick reply. I was not concerned about incoming mail to > my domain using the MX record. > > I was more concerned about the outgoing server configured in the email > clients > and used to send main from my domain (at least so far I did not understand > that they can make use of the MX record). It depends on the MTA you choose for your email clients, but unless you choose the very simplest systems, they can be configured to look up the MX record and use that. (Postfix has a fallback_relay option, Exim can accept multiple hosts in a route_list statement, and so forth.) Finally, you could set up each of your mail servers to call themselves smtp.domain, and use any number of failover mechanisms to get a single IP to whichever one is live. In practice, you probably should not bother with that. -dsr-
Re: Best practive for TLS/DNS Setup for exim
Am Montag, 18. Mai 2020, 19:58:06 CEST schrieb Dan Ritter: > Rainer Dorsch wrote: > > Hi, > > > > I am just wondering how a efficient setup for TLS/DNS for exim looks like: > > > > Right now I have an A entry in the DNS server for smtp. and a > > letsencrypt certificate as well. > > > > If I setup a new server and call it SMTP2, I need to reconfigure this in > > all my email clients. If I install the SMTP certificates, testing is > > somewhat limited, since the DNS entry still points to another server and > > I would need to fake this. > > > > Does anybody know if I can have a certificate for . > > and use for smtp a CNAME? > > > > The advantage I would see is that I can have a fully functional config and > > with disabling the SMTP name on the old system and changing the CNAME in > > the DNS system, I could be done. > > > > Does anybody now if the standard email clients can handle the situation in > > which them get as SMTP server a cname and as certificate the > > the > > SMTP cname points to? > > I think you're overcomplicating it. > > Your domain can and should have two or more MX records, with > different priority levels. The MX records don't even have to > point to names in your domain. > > Since you're using Let's Encrypt, certificates are free. So, > for each mail server, set up an A and/or record. Add those > to the MX records for your domain. Have LE produce certificates > for the mail servers under the names they have assigned. > > Any mail sender will try each of your MX records, stopping when > it gets to a working entry. Some spammers will try in reverse > order, hoping that you don't have anti-spam measures on your > secondary mail server. Thanks, Dan, for your quick reply. I was not concerned about incoming mail to my domain using the MX record. I was more concerned about the outgoing server configured in the email clients and used to send main from my domain (at least so far I did not understand that they can make use of the MX record). Thanks Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Best practive for TLS/DNS Setup for exim
Rainer Dorsch wrote: > Hi, > > I am just wondering how a efficient setup for TLS/DNS for exim looks like: > > Right now I have an A entry in the DNS server for smtp. and a > letsencrypt certificate as well. > > If I setup a new server and call it SMTP2, I need to reconfigure this in all > my > email clients. If I install the SMTP certificates, testing is somewhat > limited, > since the DNS entry still points to another server and I would need to fake > this. > > Does anybody know if I can have a certificate for . and > use for smtp a CNAME? > > The advantage I would see is that I can have a fully functional config and > with > disabling the SMTP name on the old system and changing the CNAME in the DNS > system, I could be done. > > Does anybody now if the standard email clients can handle the situation in > which them get as SMTP server a cname and as certificate the the > SMTP cname points to? I think you're overcomplicating it. Your domain can and should have two or more MX records, with different priority levels. The MX records don't even have to point to names in your domain. Since you're using Let's Encrypt, certificates are free. So, for each mail server, set up an A and/or record. Add those to the MX records for your domain. Have LE produce certificates for the mail servers under the names they have assigned. Any mail sender will try each of your MX records, stopping when it gets to a working entry. Some spammers will try in reverse order, hoping that you don't have anti-spam measures on your secondary mail server. -dsr-
Best practive for TLS/DNS Setup for exim
Hi, I am just wondering how a efficient setup for TLS/DNS for exim looks like: Right now I have an A entry in the DNS server for smtp. and a letsencrypt certificate as well. If I setup a new server and call it SMTP2, I need to reconfigure this in all my email clients. If I install the SMTP certificates, testing is somewhat limited, since the DNS entry still points to another server and I would need to fake this. Does anybody know if I can have a certificate for . and use for smtp a CNAME? The advantage I would see is that I can have a fully functional config and with disabling the SMTP name on the old system and changing the CNAME in the DNS system, I could be done. Does anybody now if the standard email clients can handle the situation in which them get as SMTP server a cname and as certificate the the SMTP cname points to? Many thanks Rainer -- Rainer Dorsch http://bokomoko.de/
One way to send emails to LAN hosts and to ISP, was Re: Permissions and delivery of LAN email by exim
On Sat 17 Aug 2019 at 07:20:45 (-), Curt wrote: > On 2019-08-16, Greg Wooledge wrote: > > On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote: > >> AIUI exim should be able to deliver emails into a user's mbox, but > >> I'm confused about how exim is meant to do that, because it runs as > >> user Debian-exim, but mailbox permissions are normally group:mail. > > > > I don't know much about exim4, but: > > > > -rwsr-xr-x 1 root root 1241412 Jul 20 07:35 /usr/sbin/exim4 > > > > That setuid bit means it *can* become you in order to deliver a message > > to your inbox. > > > > That's exactly what the docs say is supposed to happen: > > Local message deliveries are normally run in processes that are setuid > to the recipient, and remote deliveries are normally run under Exim’s > own uid and gid. Sure, but "local" messages are those from hostS to hostS, and hostR to hostR; not those from hostS to hostR, which are remote. And that doesn't seem difficult until you realise that with the smarthost configuration on hostS, either all your email by default is sent to hostR, or all is sent to your ISP. It's not very useful to send logwatch reports to debian-user, nor this list's postings to hostR. So the question is really: how to set up a host configured to send email to your ISP's smarthost, but still be able to send emails to other hosts on the LAN; and BTW not to forward all its received LAN emails to the ISP. All this has to happen on a LAN that has no DNS Server at the router (and, of course, no MX records anywhere). (Note that nothing here involves extra-LAN *incoming* email. The LAN is firewalled, and all my email from the world is hosted externally and read through their IMAP server.) My mistake when I posted the OP was trying to overspecify actions in /etc/exim4/hubbed_hosts, rather than using the relaying options. This, plus the fact that the copious exim4 documentation is not applicable directly to Debian systems, and Debian's own documentation doesn't seem to cover this case. Debian focuses (justifiably) on getting email sent out to an ISP smarthost successfully, and (a little less justifiably) getting emails to internal hosts on "real" LANs that have MX records. So there were a few false trails to eliminate in coming up with a solution that works. Rather than bother with these, I'll just post my solution, with a few notes to explain my setup (where necessary for understanding things). My hostnames/IPs don't mean much to others so I mangled them: hostS is the host that Sends emails to the Smarthost, and is IP .5, whereas hostR, .44, is a typical LAN host that's not involved in extra-LAN email at all. (However, hostR must be able to send emails to hostS. And my having a singular hostS is just a personal preference rather than a necessity.) 99% of the configuration information is, as usual, in /etc/exim4/update-exim4.conf.conf and is presented here. Like so much Debian configuration, if you edit the file as shown here, then running sudo /usr/sbin/dpkg-reconfigure exim4-config will show you what to type into the various Q&A screens in order to get that file content. So, these are my files. Note: . The domain name is "corp" and the LAN is a typical 192.168.1.0/24 one. . My external emails appear to come "From: " rather than any host on my LAN. . However, my HELO/EHLO is the LAN host's FQDN, as shown below. . AIUI the minimaldns setting prevents abortive DNS requests interfering with using hubbed_hosts as the resolver instead. . AFAICT no changes are necessary here if you use things like maildrop: exim will use .mailfilter, .forward, etc as it finds them. . Including COMMONOPTIONS='-d' in /etc/default/exim4 will log exim's deliveries in /var/log/daemon.log, in *gruesome* detail. /etc/mailname (on hostS; others are similar, with their own name): hostS.corp /etc/exim4/update-exim4.conf.conf (on hostS only): dc_eximconfig_configtype='smarthost' dc_other_hostnames='hostS.corp;hostS' dc_local_interfaces='127.0.0.1 ; ::1 ; 192.168.1.5' dc_readhost='my-own-domain.tld' dc_relay_domains='' dc_minimaldns='true' dc_relay_nets='192.168.1.0/24' dc_smarthost='smtp.my-own-domain.tld::12345;smtp.my-ISP.net::587' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='true' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' /etc/exim4/update-exim4.conf.conf (on hostR and the other LAN hosts): dc_eximconfig_configtype='internet' dc_other_hostnames='hostR.corp;hostR' dc_local_interfaces='127.0.0.1 ; ::1 ; 192.168.1.44' dc_readhost='' dc_relay_domains='' dc_minimald
Re: Permissions and delivery of LAN email by exim
On 2019-08-16, Greg Wooledge wrote: > On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote: >> AIUI exim should be able to deliver emails into a user's mbox, but >> I'm confused about how exim is meant to do that, because it runs as >> user Debian-exim, but mailbox permissions are normally group:mail. > > I don't know much about exim4, but: > > -rwsr-xr-x 1 root root 1241412 Jul 20 07:35 /usr/sbin/exim4 > > That setuid bit means it *can* become you in order to deliver a message > to your inbox. > That's exactly what the docs say is supposed to happen: Local message deliveries are normally run in processes that are setuid to the recipient, and remote deliveries are normally run under Exim’s own uid and gid. -- “We are all in the gutter, but some of us are looking at the stars.” ― Oscar Wilde, Lady Windermere's Fan
Re: Permissions and delivery of LAN email by exim
On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote: > AIUI exim should be able to deliver emails into a user's mbox, but > I'm confused about how exim is meant to do that, because it runs as > user Debian-exim, but mailbox permissions are normally group:mail. I don't know much about exim4, but: -rwsr-xr-x 1 root root 1241412 Jul 20 07:35 /usr/sbin/exim4 That setuid bit means it *can* become you in order to deliver a message to your inbox.
Permissions and delivery of LAN email by exim
AIUI exim should be able to deliver emails into a user's mbox, but I'm confused about how exim is meant to do that, because it runs as user Debian-exim, but mailbox permissions are normally group:mail. For example, with exim4 on hostR set up as … internet site; mail is sent and received directly using SMTP Domains to relay mail for: hostS;corp Keep number of DNS-queries minimal (Dial-on-Demand)? Yes dc_eximconfig_configtype='internet' dc_relay_domains='hostS;corp' dc_minimaldns='true' … hostS can send an email to foo@hostR without its being rejected. At the receiving end, with these lines in /etc/exim4/hubbed_hosts, … hostR.corp: 192.168.1.18 mail_spool hostR: 192.168.1.18 mail_spool … when exim tries to deliver this email directly, the exim log shows … 1hyefl-0001RE-Up <= f...@some-other.domain.tld H=(hostS.corp) [192.168.1.17] P=esmtp S=711 id=20190816160149.nckhtqfas3tge...@hosts.corp 1hyefl-0001RE-Up == f...@hostr.corp R=hubbed_hosts T=mail_spool defer (-6): mailbox /var/mail/foo has wrong uid (1003 != 111) … and the email remains stuck in /var/spool/exim. Background info: etc/passwd on hostR: mail:x:8:8:mail:/var/mail:/usr/sbin/nologin Debian-exim:x:111:120::/var/spool/exim4:/usr/sbin/nologin foo:x:1003:1003:Mr Chew,,,:/home/foo:/bin/bash ps -ef on hostR: 9659 1 111 ?Ss 0:00 /usr/sbin/exim4 -bd -q30m ls on hostR: drwxrwsr-x 2 rootmail 4096 Aug 16 13:24 /var/mail/ -rw-rw 1 foo mail 19284 Aug 16 12:00 /var/mail/foo -rw-rw 1 Debian-exim mail 670 Aug 16 13:24 /var/mail/root So what piece of the puzzle is missing that would allow exim to deliver such an email to foo's mbox? Exim has no difficulty, for example, delivering locally generated emails from cron … 1hyfaG-00027u-Mt <= r...@hostr.corp U=root P=local S=91975 1hyfaG-00027u-Mt => foo R=local_user T=mail_spool 1hyfaG-00027u-Mt Completed … nor in delivering remotely sent emails to root: 1hygu1-0002c1-A7 <= f...@some-other.domain.tld H=(hostS.corp) [192.168.1.17] P=esmtp S=734 id=20190816182441.gwbbcru46mt7c...@hosts.corp 1hygu1-0002c1-A7 => r...@hostr.corp R=hubbed_hosts T=mail_spool H=192.168.1.18 1hygu1-0002c1-A7 Completed Cheers, David.
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
Hello, On Thu, Jun 20, 2019 at 08:45:13PM +0100, Brian wrote: > At least 2000,000, hosts on the internet. You reckon you will be in > the first tranche of targets? I don't know about "amongst the first" but there are multiple services scanning every port of the entire IPv4 space now and selling access to the results, e.g. Shodan which has already been mentioned. So the idea that you don't need to think about hostile actors connecting to your service because you are 1 in 2bn or whatever, is no longer sound. For example, for over 10 years I have been putting ssh on a port other than 22 where I able to do so, just to cut down on noise in my logs since every hostile knew to check port 22. This year for the first time I am finding that mass scanners have found my alternate port and are now doing dictionary attacks against it. This is because the aforementioned scanning services have scanned every port of my hosts and are selling the information that my host has what looks like an sshd on so and so port. The operators of botnets are buying this information and setting their botnets to try SSH on those alternate ports too. So any new bad actor who wants to scan for this vulnerability is just going to buy access to a list of every host on the Internet that has an open port 25, maybe an open port 25 running the vulnerable versions of Exim if that is offered. That will be a very manageable list of IPs. They won't have to do the scanning themselves. This is only going to get worse. I don't think it's security through obscurity to try to hide yourself from the hostiles if you have already taken steps to protect yourself and it's just to reduce the amount of noise. I think it's only security through obscurity if you don't fix it, try to hide and would get exploited if you were found. Having said that, I am in full agreement that the correct thing to do if concerned about the SMTP banner is to change the SMTP banner, not change the version of the software. I might even go further and try to find a way to identify and log people trying this exploit, so that they can be dealt with the same way persistent SSH dictionary attackers are. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
On Fri 21 Jun 2019 at 21:14:42 +1000, Andrew McGlashan wrote: > On 21/6/19 4:08 pm, Reco wrote: > > What I'm most interested is here is the time distribution. I.e. has > > the number of exploitation attempts lowered after the Exim banner > > change? Stayed the same? > > Not a single one since, so far. > > Although I did blacklist IP addresses. I get the same outcome too when I blacklist offending IPs. -- Brian.
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/6/19 4:08 pm, Reco wrote: > What I'm most interested is here is the time distribution. I.e. has > the number of exploitation attempts lowered after the Exim banner > change? Stayed the same? Not a single one since, so far. Although I did blacklist IP addresses. A. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQy8HAAKCRCoFmvLt+/i +/lFAP44LFIbm+CfWGdHKjXgK5O7ehgzTUnRQzXgR1TMipqz5gEAlIV8sAF9wXZa b+orcH4WobyYdGKGl5mKFWbd/QbC7gs= =Bb7S -END PGP SIGNATURE-
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
Hi.
On Fri, Jun 21, 2019 at 06:36:20AM +1000, Andrew McGlashan wrote:
> On 21/6/19 5:52 am, Reco wrote:
> > Plain old grep is more than enough here. This one:
> >
> > grep 'run{' /var/log/exim4/reject*
> >
> > finds things like these:
> >
> > 2019-06-19 18:54:43 H=(service.com) [107.182.225.42]
> > F= rejected RCPT
> > xxx.xxx.xxx\x22}}@localhost>:
> > Unrouteable address
>
> Okay:
> 21 attempts from 8 different IP addresses on one server
> 1[163.172.157.143]
> 2[188.138.0.205]
> 3[23.129.64.152]
> 4[23.129.64.193]
> 5[27.69.172.214]
> 6[45.55.94.254]
> 7[51.15.227.108]
> 8[89.248.171.57]
>
> 28 attempts on another server
> 1[149.56.142.192]
> 2[163.172.157.143]
> 3[188.138.0.205]
> 4[27.69.172.229]
> 5[51.15.227.108]
> 6[51.77.148.55]
> 7[85.58.114.228]
> 8[89.248.171.57]
>
> 17 attempts on another server
> 1[188.138.0.205]
> 2[89.248.171.57]
> 3[98.158.184.125]
>
>
> 13 unique IP addresses so far (dig -x output)
>
> 1149.56.142.192 192.ip-149-56-142.net.
> 2163.172.157.143 143-157-172-163.rev.cloud.scaleway.com.
> 3188.138.0.205static-ip-188-138-0-205.inaddr.ip-pool.com.
> 423.129.64.152
> 523.129.64.193
> 627.69.172.214localhost.
> 727.69.172.229localhost.
> 845.55.94.254
> 951.15.227.108108-227-15-51.rev.cloud.scaleway.com.
> 1051.77.148.55 55.ip-51-77-148.eu.
> 1185.58.114.228228.pool85-58-114.dynamic.orange.es.
> 1289.248.171.57scanner20.openportstats.com.
> 1398.158.184.125 206.217.215.125.static.midphase.com.
What I'm most interested is here is the time distribution.
I.e. has the number of exploitation attempts lowered after the Exim
banner change? Stayed the same?
Reco
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
On Thu, Jun 20, 2019 at 10:50:08PM +0100, Brian wrote: So? Looks like a normal day. Announcing exim as version 4.92 (or any other value) is most unlikely to reduce the number of these attempts. I'm seeing the same attempts on postfix servers...
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 21/6/19 4:49 am, Reco wrote: >> Thank you, I've changed the banner for now let's hope that >> lessens the problem. > > Please share the results if possible. > > On this particular MTA I've counted whopping 4 attempts to exploit > CVE-2019-10149 so far. One made from France, three from US. I'm > kind of disappointed, I've expected half a million Chineese and > Russian bots at least ;) I've got good logs, what is the easiest string to grep for in the logs to see attempts? Or have you got a more fancy solution? Thanks AndrewM -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQviTwAKCRCoFmvLt+/i +2e1AQCSxSt36JCCw6wxiuUryIIfE1VL4x5Yxi5SqXJpzcmYuQEAlkRfhQSCVQqV KE8V7k4pvHVRHKBWdX1WqRku6CBYjQ8= =tAiE -END PGP SIGNATURE-
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
On Fri 21 Jun 2019 at 04:15:35 +1000, Andrew McGlashan wrote:
> On 20/6/19 11:57 pm, Brian wrote:
> > On Thu 20 Jun 2019 at 23:26:08 +1000, Andrew McGlashan wrote:
> >
> >> # dpkg-query -l|grep \ exim|awk '{print $2,$3}'|column -t exim4
> >> 4.89-2+deb9u4 exim4-base 4.89-2+deb9u4 exim4-config
> >> 4.89-2+deb9u4 exim4-daemon-heavy 4.89-2+deb9u4 exim4-doc-html
> >> 4.89-1
> >>
> >> Is there a way to provide version of "4.92" easily or some other
> >> text to stop the likelihood of outsiders trying to pound on and
> >> exploit the server? Even though they won't be able to do
> >> successfully due to up to date patch status.
> >
> > You really, really think changing a version number increases or
> > decreases the likelihood of automated server probes happening?
>
> Yes, if "candidates" are chosen and then advertised to bots to go and
> do the work, instead of doing the work against any and every server,
> for sure. If this was a quick and simple exploit, the answer would be
> no, but this exploit takes considerable time before a result is known
> or attained from the attempt.
At least 2000,000, hosts on the internet. You reckon you will be in
the first tranche of targets? That's apart from the completely inept and
unintelligent type of exploitation attack that is run.
>
> > Doesn't doing this qualify as security through obscurity?
>
> Yes, but sometimes that simply works.
How can it? As you say
> Even though they won't be able to do successfully due to up to
> date patch status.
You acknowledge your mail server is safe. Are you in the business of
serving up FUD in spite of your updating and declaring the server to
be protected against this particular bug?
By all means alter smtp_banner. Much good will it do.
--
Brian.
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
Hi. On Fri, Jun 21, 2019 at 04:40:11AM +1000, Andrew McGlashan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 20/6/19 11:45 pm, Reco wrote: > > Hi. > > > > On Thu, Jun 20, 2019 at 11:26:08PM +1000, Andrew McGlashan wrote: > >> Is there a way to provide version of "4.92" easily or some other > >> text to stop the likelihood of outsiders trying to pound on and > >> exploit the server? Even though they won't be able to do > >> successfully due to up to date patch status. > > > > # rgrep banner /etc/exim4/ > > /etc/exim4/conf.d/main/02_exim4-config_options:# smtp_banner = > > $smtp_active_hostname ESMTP Exim $version_number $tod_full > > /etc/exim4/exim4.conf.template:# smtp_banner = > > $smtp_active_hostname ESMTP Exim $version_number $tod_full > > > > Replace v$version_number with 4.92 or set "smtp_banner" to whatever > > you like. > > Thank you, I've changed the banner for now let's hope that lessens > the problem. Please share the results if possible. On this particular MTA I've counted whopping 4 attempts to exploit CVE-2019-10149 so far. One made from France, three from US. I'm kind of disappointed, I've expected half a million Chineese and Russian bots at least ;) Reco
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/6/19 11:45 pm, Reco wrote: > Hi. > > On Thu, Jun 20, 2019 at 11:26:08PM +1000, Andrew McGlashan wrote: >> Is there a way to provide version of "4.92" easily or some other >> text to stop the likelihood of outsiders trying to pound on and >> exploit the server? Even though they won't be able to do >> successfully due to up to date patch status. > > # rgrep banner /etc/exim4/ > /etc/exim4/conf.d/main/02_exim4-config_options:# smtp_banner = > $smtp_active_hostname ESMTP Exim $version_number $tod_full > /etc/exim4/exim4.conf.template:# smtp_banner = > $smtp_active_hostname ESMTP Exim $version_number $tod_full > > Replace v$version_number with 4.92 or set "smtp_banner" to whatever > you like. Thank you, I've changed the banner for now let's hope that lessens the problem. Besides the servers that I look after, it would help if others did the same so as to lessen any "scare" campaigns based on false data from Shodan. Obviously many less servers are really vulnerable than the figures are currently suggesting. Kind Regards AndrewM -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQvTBwAKCRCoFmvLt+/i +5i6AQDTFMANdum/LJEdlO/YoWbU6Yq+/Fl72OGnWUdkI84riQD/V+QZV21/8cKw Of9Ob0jKTdTBRPb6ys65dnuwjljH4lQ= =yTQa -END PGP SIGNATURE-
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/6/19 11:57 pm, Brian wrote:
> On Thu 20 Jun 2019 at 23:26:08 +1000, Andrew McGlashan wrote:
>
>> # dpkg-query -l|grep \ exim|awk '{print $2,$3}'|column -t exim4
>> 4.89-2+deb9u4 exim4-base 4.89-2+deb9u4 exim4-config
>> 4.89-2+deb9u4 exim4-daemon-heavy 4.89-2+deb9u4 exim4-doc-html
>> 4.89-1
>>
>> Is there a way to provide version of "4.92" easily or some other
>> text to stop the likelihood of outsiders trying to pound on and
>> exploit the server? Even though they won't be able to do
>> successfully due to up to date patch status.
>
> You really, really think changing a version number increases or
> decreases the likelihood of automated server probes happening?
Yes, if "candidates" are chosen and then advertised to bots to go and
do the work, instead of doing the work against any and every server,
for sure. If this was a quick and simple exploit, the answer would be
no, but this exploit takes considerable time before a result is known
or attained from the attempt.
> Doesn't doing this qualify as security through obscurity?
Yes, but sometimes that simply works.
Kind Regards
AndrewM
-BEGIN PGP SIGNATURE-
iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQvNQQAKCRCoFmvLt+/i
+7KGAQCEkZ/PhssYzKVsJI2yd/cT1B3RMXEAGqNn0vnt/JQxGAD/VPpHgN+rSUbU
Uw+XZdEOZ3kQxkykPGO9bfy8qJRjshc=
=Gs+8
-END PGP SIGNATURE-
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
On Thu 20 Jun 2019 at 23:26:08 +1000, Andrew McGlashan wrote:
> # dpkg-query -l|grep \ exim|awk '{print $2,$3}'|column -t
> exim4 4.89-2+deb9u4
> exim4-base 4.89-2+deb9u4
> exim4-config4.89-2+deb9u4
> exim4-daemon-heavy 4.89-2+deb9u4
> exim4-doc-html 4.89-1
>
> Is there a way to provide version of "4.92" easily or some other text
> to stop the likelihood of outsiders trying to pound on and exploit the
> server? Even though they won't be able to do successfully due to up to
> date patch status.
You really, really think changing a version number increases or
decreases the likelihood of automated server probes happening?
Doesn't doing this qualify as security through obscurity?
--
Brian.
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
On Thu, Jun 20, 2019 at 11:26:08PM +1000, Andrew McGlashan wrote: > Shodan [1] reports loads of vulnerable [2] servers running pre 4.92 > versions of Exim, those include Debian Exim variants reporting 4.89 > even for fully patched servers. General answer: https://www.debian.org/security/faq (especially <https://www.debian.org/security/faq#oldversion>) For this particular issue: https://www.debian.org/security/2019/dsa-4456 https://security-tracker.debian.org/tracker/CVE-2019-10149 And the entry in the Debian changelog for the stretch package: = exim4 (4.89-2+deb9u4) stretch-security; urgency=high * Non-maintainer upload by the Security Team. * Fix remote command execution vulnerability (CVE-2019-10149) -- Salvatore Bonaccorso Tue, 28 May 2019 22:13:55 +0200 =
Re: Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
Hi. On Thu, Jun 20, 2019 at 11:26:08PM +1000, Andrew McGlashan wrote: > Is there a way to provide version of "4.92" easily or some other text > to stop the likelihood of outsiders trying to pound on and exploit the > server? Even though they won't be able to do successfully due to up to > date patch status. # rgrep banner /etc/exim4/ /etc/exim4/conf.d/main/02_exim4-config_options:# smtp_banner = $smtp_active_hostname ESMTP Exim $version_number $tod_full /etc/exim4/exim4.conf.template:# smtp_banner = $smtp_active_hostname ESMTP Exim $version_number $tod_full Replace v$version_number with 4.92 or set "smtp_banner" to whatever you like. Bounce exim. Reco
Exim latest update reports to world as 4.89, which the world thinks is vulnerable.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Shodan [1] reports loads of vulnerable [2] servers running pre 4.92
versions of Exim, those include Debian Exim variants reporting 4.89
even for fully patched servers.
$ telnet mail.example.org 25
Trying ip_add_re_ss...
Connected to mail.example.org.
Escape character is '^]'.
220 mail.example.org ESMTP Exim 4.89 Thu, 20 Jun 2019 22:46:55 +1000
QUIT
221 mail.example.org closing connection
Connection closed by foreign host.
# dpkg-query -l|grep \ exim|awk '{print $2,$3}'|column -t
exim4 4.89-2+deb9u4
exim4-base 4.89-2+deb9u4
exim4-config4.89-2+deb9u4
exim4-daemon-heavy 4.89-2+deb9u4
exim4-doc-html 4.89-1
Is there a way to provide version of "4.92" easily or some other text
to stop the likelihood of outsiders trying to pound on and exploit the
server? Even though they won't be able to do successfully due to up to
date patch status.
[1] This Showdan query needs a login:
https://www.shodan.io/search?query=product%3Aexim+-4.92
[2]
https://www.bleepingcomputer.com/news/security/millions-of-exim-mail-ser
vers-exposed-to-local-remote-attacks/
- --
Kind Regards
AndrewM
Andrew McGlashan
-BEGIN PGP SIGNATURE-
iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQuJagAKCRCoFmvLt+/i
+zdHAP9ubOiFuM84l9bTVFGPHxxWqnYh0mEc6sjnj1lGx73r6wD+MHsAojEYeS/H
Dc6QS9fgAliTAqPgf4+dBJ+7lKYdBQM=
=P4iw
-END PGP SIGNATURE-
Re: Severe vulnerability in Exim 4.87 through 4.91
On 2019-06-10, Greg Wooledge wrote: > On Sat, Jun 08, 2019 at 04:50:06PM -, Curt wrote: >> https://lwn.net/Articles/790553/ >> >> I was actually going to point to another article on the subject, but as >> it revealed the exact modus operandi for the (local) exploit (which is >> trivial to an extreme) I thought better of it. > > https://www.debian.org/security/2019/dsa-4456 > > https://security-tracker.debian.org/tracker/CVE-2019-10149 > > Okay, thank you, so fixed in Stretch with the package update to 4.89-2+deb9u4 a few days ago (other releases not vulnerable). -- “Decisions are never really made – at best they manage to emerge, from a chaos of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon
Re: Severe vulnerability in Exim 4.87 through 4.91
On Sat, Jun 08, 2019 at 04:50:06PM -, Curt wrote: > https://lwn.net/Articles/790553/ > > I was actually going to point to another article on the subject, but as > it revealed the exact modus operandi for the (local) exploit (which is > trivial to an extreme) I thought better of it. https://www.debian.org/security/2019/dsa-4456 https://security-tracker.debian.org/tracker/CVE-2019-10149
Severe vulnerability in Exim 4.87 through 4.91
https://lwn.net/Articles/790553/ I was actually going to point to another article on the subject, but as it revealed the exact modus operandi for the (local) exploit (which is trivial to an extreme) I thought better of it. -- “Decisions are never really made – at best they manage to emerge, from a chaos of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon
Re: add IGNORE_SMTP_LINE_LENGTH_LIMIT macro to Exim
On 12/09/18 19:49, Peter Wiersig wrote: I think there is quite a lot of *.Debian.gz documentation in the various exim4 packages. Yes, maybe I got lost. What's the correct way to specify a macro (that one or others) in the Exim configuration? I created /etc/exim4/conf.d/main/00_peter-localmacros for the stuff I need to control via macros. But I don't know if you use split config-file or you like the giant file. Just now I'm using the dpkg default (one big file), but I'm open to suggestions. Can I run "dpkg-reconfigure exim4-config", choose split config and keep current configured options? /usr/share/doc/exim4-config/README.Debian.gz: "2.1.3 Using Exim Macros to control the configuration ... For a non-split configuration, /etc/exim4/exim4.conf.localmacros gets read before /etc/exim4/exim4.conf.template." Yes, I've already tried that too, and it does not output any error message, but update-exim4.conf does not copy anywhere what I write into /etc/exim4/exim4.conf.localmacros either. Is that intended?
Re: add IGNORE_SMTP_LINE_LENGTH_LIMIT macro to Exim
Lucio writes: > > undocumented line IGNORE_SMTP_LINE_LENGTH_LIMIT=1 found in > /etc/exim4/update-exim4.conf.conf, generating exim macro > > and that does not sound good to me. Yeah, remove that. I think there is quite a lot of *.Debian.gz documentation in the various exim4 packages. > What's the correct way to specify a > macro (that one or others) in the Exim configuration? I created /etc/exim4/conf.d/main/00_peter-localmacros for the stuff I need to control via macros. But I don't know if you use split config-file or you like the giant file. /usr/share/doc/exim4-config/README.Debian.gz: "2.1.3 Using Exim Macros to control the configuration ... For a non-split configuration, /etc/exim4/exim4.conf.localmacros gets read before /etc/exim4/exim4.conf.template." Good luck, Peter
add IGNORE_SMTP_LINE_LENGTH_LIMIT macro to Exim
I need to add the IGNORE_SMTP_LINE_LENGTH_LIMIT macro to my Exim, but I don't know which is the configuration file where I have to write it and I don't know the correct syntax. I've already tried appending IGNORE_SMTP_LINE_LENGTH_LIMIT='1' to /etc/exim4/update-exim4.conf.conf and then running # update-exim4.conf but it replies undocumented line IGNORE_SMTP_LINE_LENGTH_LIMIT=1 found in /etc/exim4/update-exim4.conf.conf, generating exim macro and that does not sound good to me. What's the correct way to specify a macro (that one or others) in the Exim configuration?
Re: Outgoing email with exim, was Re: Strange LAN IP Address.
On 2018-07-04 04:40, Mike McClain wrote: On Tue, Jul 03, 2018 at 05:42:15PM -0500, David Wright wrote: On Tue 03 Jul 2018 at 08:52:22 (-0700), Mike McClain wrote: > On Mon, Jul 02, 2018 at 03:17:27PM -0400, Stephen P. Molnar wrote: > > Should anyone reading this know hjow to get exim4 to connect to > outbound.att.net I'd love to hear about it. Curt got the wiki, and my googling landed on https://www.att.com/esupport/article.html#!/dsl-high-speed/KM1010523 and https://www.att.com/esupport/article.html#!/email-support/KM1240308 It looks as though these are more up to date than the wiki. In the first, I assume that the table rows are labelled wrongly, but it seems to show SMTP on smtp.mail.att.net ports 465 or 587 as well as the hostname you gave. I would also try port 587 on both hostnames: it won't be the first to give the wrong one. The second shows how to get a suitable password for your userID. (I would use this approach merely because I don't know anything about oath.) Anyway, what doesn't work for you and what response do you get from exim? What doesn't work? Can't send mail. Long before Verizon and Oath were involved with Yahoo. When I switched from dialup AT&T had me using port 465 and at that time I was getting some kind of authorization error but couldn't find out what. # /etc/exim4/update-exim4.conf.conf dc_eximconfig_configtype='smarthost' dc_local_interfaces='127.0.0.1' dc_smarthost='outbound.att.net::465' Here's an excerpt from current exim's log: 2018-07-03 19:51:29 1faXd0-0008Gb-JB Remote host smtp.att.mail.fy4.b.yahoo.com [67.195.228.97] closed connection in response to initial connection 2018-07-03 19:51:59 1faXd0-0008Gb-JB == nialccm.e...@gmail.com R=smarthost T=remote_smtp_smarthost defer (-18): Remote host smtp.att.mail.fy4.b.yahoo.com [98.136.96.82] closed connection in response to initial connection Switching update-exim4.conf.conf to read: dc_smarthost='outbound.att.net::587' exim's log now shows: 2018-07-03 20:15:24 1faYFl-6U-4d ** mikemcclain...@att.net R=smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<> SIZE=2464: host smtp.att.mail.fy4.b.yahoo.com [67.195.228.97]: 550 Request failed; Mailbox unavailable This last message shows a further complication. I have a primary email account with ATT as well as several aliases,. I also have a Yahoo account, likewise gmail and am likely to use any of them as the source (From:, ReplyTo: headers) in outgoing mail depending on where it's going. I only have one, the primary, in /etc/exim4/passwd.client for ATT. My dialup doesn't care what I call myself when I send email but perhaps ATT/Yahoo does. No I haven't tried to get that special password. What I've got works, I guess I'll leave it rather than jump through hoops for Verizon. Thanks for the references. Mike think with yahoo you have to login on their web site and register the sending email address to use their SMTP mick -- Key ID4BFEBB31
Re: Outgoing email with exim, was Re: Strange LAN IP Address.
On Tue, Jul 03, 2018 at 05:42:15PM -0500, David Wright wrote: > On Tue 03 Jul 2018 at 08:52:22 (-0700), Mike McClain wrote: > > On Mon, Jul 02, 2018 at 03:17:27PM -0400, Stephen P. Molnar wrote: > > > > Should anyone reading this know hjow to get exim4 to connect to > > outbound.att.net I'd love to hear about it. > > Curt got the wiki, and my googling landed on > https://www.att.com/esupport/article.html#!/dsl-high-speed/KM1010523 > and > https://www.att.com/esupport/article.html#!/email-support/KM1240308 > It looks as though these are more up to date than the wiki. > > In the first, I assume that the table rows are labelled wrongly, > but it seems to show SMTP on smtp.mail.att.net ports 465 or 587 > as well as the hostname you gave. I would also try port 587 on > both hostnames: it won't be the first to give the wrong one. > > The second shows how to get a suitable password for your userID. > (I would use this approach merely because I don't know anything > about oath.) > > Anyway, what doesn't work for you and what response do you get > from exim? What doesn't work? Can't send mail. Long before Verizon and Oath were involved with Yahoo. When I switched from dialup AT&T had me using port 465 and at that time I was getting some kind of authorization error but couldn't find out what. # /etc/exim4/update-exim4.conf.conf dc_eximconfig_configtype='smarthost' dc_local_interfaces='127.0.0.1' dc_smarthost='outbound.att.net::465' Here's an excerpt from current exim's log: 2018-07-03 19:51:29 1faXd0-0008Gb-JB Remote host smtp.att.mail.fy4.b.yahoo.com [67.195.228.97] closed connection in response to initial connection 2018-07-03 19:51:59 1faXd0-0008Gb-JB == nialccm.e...@gmail.com R=smarthost T=remote_smtp_smarthost defer (-18): Remote host smtp.att.mail.fy4.b.yahoo.com [98.136.96.82] closed connection in response to initial connection Switching update-exim4.conf.conf to read: dc_smarthost='outbound.att.net::587' exim's log now shows: 2018-07-03 20:15:24 1faYFl-6U-4d ** mikemcclain...@att.net R=smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<> SIZE=2464: host smtp.att.mail.fy4.b.yahoo.com [67.195.228.97]: 550 Request failed; Mailbox unavailable This last message shows a further complication. I have a primary email account with ATT as well as several aliases,. I also have a Yahoo account, likewise gmail and am likely to use any of them as the source (From:, ReplyTo: headers) in outgoing mail depending on where it's going. I only have one, the primary, in /etc/exim4/passwd.client for ATT. My dialup doesn't care what I call myself when I send email but perhaps ATT/Yahoo does. No I haven't tried to get that special password. What I've got works, I guess I'll leave it rather than jump through hoops for Verizon. Thanks for the references. Mike -- Where man is there will be trouble to the end of time, if not of one sort, then of another." - Louis L'Amour
Outgoing email with exim, was Re: Strange LAN IP Address.
On Tue 03 Jul 2018 at 08:52:22 (-0700), Mike McClain wrote: > On Mon, Jul 02, 2018 at 03:17:27PM -0400, Stephen P. Molnar wrote: > > > When I ran ifconfig on the Linux platform it showed the unet > > connection to be 162.237.98.238!!? The LAN modem employs DCHP > > set with allowed IP range as 192.168.1.64 through 192.168.1.253, > > which was set by the T&T installer when we switched to a fiber optic > > network. > > > > Further examination of the modem settings showed IP Passthrough > > status as on (Public IP Address), which was, in fact the IP. > > ATT tech support demonstrated to me that they can change the > settings remotely. > If they can so can some one else. > > > I spent 40 minutes, on hold for 28 of those minutes, with an AT&T > > UVVerse technical () person without hearing any reasons why the > > IP was what it was. > > When I signed up with ATT Uverse I accumulated hours on the phone > trying to get email out through their server. I gave up and used my > dialup account. > Their tech support -- isn't. Many of those people didn't grow up > with computers and have no idea what goes on under the hood. Even when > you get someone in Dallas rather than Manila answers and understanding > can be lacking. > > Should anyone reading this know hjow to get exim4 to connect to > outbound.att.net I'd love to hear about it. Curt got the wiki, and my googling landed on https://www.att.com/esupport/article.html#!/dsl-high-speed/KM1010523 and https://www.att.com/esupport/article.html#!/email-support/KM1240308 It looks as though these are more up to date than the wiki. In the first, I assume that the table rows are labelled wrongly, but it seems to show SMTP on smtp.mail.att.net ports 465 or 587 as well as the hostname you gave. I would also try port 587 on both hostnames: it won't be the first to give the wrong one. The second shows how to get a suitable password for your userID. (I would use this approach merely because I don't know anything about oath.) Anyway, what doesn't work for you and what response do you get from exim? Cheers, David.
Re: [linux.debian.user] question about exim.
On Wed, 2018-05-09 at 09:52 +0200, Kamil Jońca wrote: > kjo...@poczta.onet.pl (Kamil Jońca) writes: > > [...] > > > > Hmm. Good point. There are two options: > > 1. onet (my isp) is broken > > 2. fetchmail is broken > > Well, quick look into fetchmail manual and we have: > --8<---cut here---start->8--- > -n | --norewrite > (Keyword: no rewrite) > Normally, fetchmail edits RFC-822 address headers (To, From, > Cc, Bcc, and Reply-To) in fetched mail so that any mail IDs local to the > server are expanded to full addresses (@ and the mailserver hostname are > appended). > This enables replies on the client to get addressed correctly > (otherwise your mailer might think they should be addressed to local users on > the client machine!). This option disables the rewrite. (This option is pro‐ > vided to pacify people who are paranoid about having an MTA > edit mail headers and want to know they can prevent it, but it is generally > not a good idea to actually turn off rewrite.) When using ETRN or ODMR, the > re‐ > write option is ineffective. > --8<---cut here---end--->8--- > So it looks like that fetchmail do translation > "Undisclosed-Recipients:;" -> Undisclosed-Recipients:;@imap.onet.pl" > I do not know if word "broken" is proper in my previous post, since this > is rather "feature" than "bug". I'd say it's a bug as it doesn't understand that the syntax of an 'address' in headers can be a 'group' as well as a 'mailbox'. (Using 'quotes' for the terms in RFC-822). -- Tixy
Re: [linux.debian.user] question about exim.
kjo...@poczta.onet.pl (Kamil Jońca) writes: [...] > > Hmm. Good point. There are two options: > 1. onet (my isp) is broken > 2. fetchmail is broken Well, quick look into fetchmail manual and we have: --8<---cut here---start->8--- -n | --norewrite (Keyword: no rewrite) Normally, fetchmail edits RFC-822 address headers (To, From, Cc, Bcc, and Reply-To) in fetched mail so that any mail IDs local to the server are expanded to full addresses (@ and the mailserver hostname are appended). This enables replies on the client to get addressed correctly (otherwise your mailer might think they should be addressed to local users on the client machine!). This option disables the rewrite. (This option is pro‐ vided to pacify people who are paranoid about having an MTA edit mail headers and want to know they can prevent it, but it is generally not a good idea to actually turn off rewrite.) When using ETRN or ODMR, the re‐ write option is ineffective. --8<---cut here---end--->8--- So it looks like that fetchmail do translation "Undisclosed-Recipients:;" -> Undisclosed-Recipients:;@imap.onet.pl" I do not know if word "broken" is proper in my previous post, since this is rather "feature" than "bug". KJ -- http://wolnelektury.pl/wesprzyj/teraz/ Batteries not included.
Re: [linux.debian.user] question about exim.
Tixy writes: [..]] > > is a valid way of specifying a group in a field that expects an address > > But the log snippet the OP posted had: > > ... failing address in "To:" header is: > ): "@" or "." expected after > "Undisclosed-Recipient": failing address in "To:" header is: > > > which does look suspect. The header should be > > Undisclosed-Recipient:; > > or > > > Hmm. Good point. There are two options: 1. onet (my isp) is broken 2. fetchmail is broken KJ -- http://wolnelektury.pl/wesprzyj/teraz/ You're using a keyboard! How quaint!
Re: [linux.debian.user] question about exim.
On Tue, 2018-05-08 at 20:41 +0200, deloptes wrote: > Kamil Jońca wrote: > > > How can I achieve this? > > I looks like I have write custom acl, but it is not obvious to me how to > > write proper condition in such acl. > > hi, > where is the recipient? It's specified as part of the SMTP protocol, not the TO: header in the actual email. > why would you want to receive for "Undisclosed-Recipient". It's a common method of indicating there was no address specified for the TO: field, e.g. when all recipients we're BCC'd. > I suggest you look deeper and see where it is coming from. In the end you > may drop or reject this mail as it does not go anywhere. > To me it looks like something is broken A quick look at RFC 5322 seems to indicate to me that Undisclosed-Recipient:; is a valid way of specifying a group in a field that expects an address But the log snippet the OP posted had: ... failing address in "To:" header is: ): "@" or "." expected after "Undisclosed-Recipient": failing address in "To:" header is: which does look suspect. The header should be Undisclosed-Recipient:; or Looks like something is using the group name 'Undisclosed-Recipient:;' as LOCAL-PART of an address specification. But I'm no expert and could be talking rubbish... -- Tixy
Re: [linux.debian.user] question about exim.
Kamil Jońca wrote: > How can I achieve this? > I looks like I have write custom acl, but it is not obvious to me how to > write proper condition in such acl. hi, where is the recipient? why would you want to receive for "Undisclosed-Recipient". I suggest you look deeper and see where it is coming from. In the end you may drop or reject this mail as it does not go anywhere. To me it looks like something is broken regards
[linux.debian.user] question about exim.
(onet was blocked, second try)
Hello.
Recently I found, that some mails (fetched witch fetchmail) does not reach my
mailbox.
Done some check and:
--8<---cut here---start->8---
2018-05-07 11:44:14.306 [9516] 1fFcgn-0002TU-Pb H=(alfa.kjonca)
[127.0.0.1]:53574 I=[127.0.0.1]:25 F= rejected after DATA:
header syntax ("@" or "." expected after "Undisclosed-Recipient": failing
address in "To:" header is: ): "@"
or "." expected after "Undisclosed-Recipient": failing address in "To:" header
is:
--8<---cut here---end--->8---
If I am not wrong default configuration changed in
/etc/exim4/conf.d/acl/40_exim4-config_check_data (now headers are
syntactically checked by default)
Unfortunately I got quite a lot "Undisclosed-Recipient:;" mails from
outlook users, and this is not going to be changed :(
How can I made exim accept these emails?
Temporarily I defined NO_CHECK_DATA_VERIFY_HEADER_SYNTAX macro (to
disable header syntax check) , but I
would prefer configure exim for accept "Undisclosed-Recipient:;" as only
exeption from header check.
How can I achieve this?
I looks like I have write custom acl, but it is not obvious to me how to write
proper condition in such acl.
KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
He who is good for making excuses is seldom good for anything else.
Re: root@localhost mail not forwarding in Exim
Yes, this indeed was the problem! For some reason the mail was being sent to "user" even though I had no user named that. Thanks a bunch! I have had this problem for quite a while and never could figure out how to fix it. On Thu, Mar 2, 2017 at 5:34 AM, Bonno Bloksma wrote: > Hi, > > >[] > > so, if I want to use mail.example.com as my fqdn, and the old fqdn was > something.else and r...@something.else was redirecting mail to > m...@something.else ... then what do I need to change in Exim to make this > happen? > > Is it maybe the aliases setting? > Probably you edited the \etc\aliases file, it defines where to forward > mail to. There will be a line like: > root: me > or > root: m...@mail.example.com > After saving the file it needs to be processed by the command > newaliases > If you skip this file then mail to root will go to the old forward address > and will fail if that no longer exists. > > Bonno Bloksma > >
RE: root@localhost mail not forwarding in Exim
Hi, >[] > so, if I want to use mail.example.com as my fqdn, and the old fqdn was > something.else and r...@something.else was redirecting mail to > m...@something.else ... then what do I need to change in Exim to make this > happen? Is it maybe the aliases setting? Probably you edited the \etc\aliases file, it defines where to forward mail to. There will be a line like: root: me or root: m...@mail.example.com After saving the file it needs to be processed by the command newaliases If you skip this file then mail to root will go to the old forward address and will fail if that no longer exists. Bonno Bloksma
Re: root@localhost mail not forwarding in Exim
Have you tried sudo dpkg-reconfigure exim4-config Which Settings you have there? Am 01.03.2017 um 21:40 schrieb Jiangsu Kumquat: > I changed my server name and fqdn and now the mail to root@localhost is > bouncing. > > I went into every file that had the old name and changed it to the new name > but it still > doesn't work. I did "grep -r something.else /etc" to find all the files. > > so, if I want to use mail.example.com <http://mail.example.com> as my fqdn, > and the old > fqdn was something.else and r...@something.else was redirecting mail to > m...@something.else ... then what do I need to change in Exim to make this > happen? > > root@localhost is bouncing > r...@mail.example.com <mailto:r...@mail.example.com> is bouncing > m...@mail.example.com <mailto:m...@mail.example.com> is working > > /etc/mailname is this line: > mail.example.com <http://mail.example.com> > > I would also like to be able to send mail to me@mail instead of > m...@mail.example.com > <mailto:m...@mail.example.com> ... if this is possible. > > I did "grep -r something.else /etc" and changed all the files to the > mail.example.com > <http://mail.example.com> name and then ran the "update-exim4.conf" > > if you reply, please CC me directly because it is hard to find messages in > this list > because of the high volume. > > Thanks Good Luck, -- -=== Jan-Peter Rühmann & Kuma ===- Gubkower Str.7 [ Tel.: +49 (38205) 65484 ] jan-pe...@ruehmann.name 18195 Prangendorf[ FAX: +49 (38205) 65212 ] http://www.ruehmann.name [ Tel.: +49 (38205) 65215 ] [ Mobil: +49 (162) 1316054 ] IT-Servicetechniker Skype: jan-peter_ruehmann / ICQ: 288192920 / WhatsApp: 491621316054 / Twitter: @JPRuehmann -- Die Verwendung der Daten zu Werbezwecken ist verboten.
root@localhost mail not forwarding in Exim
I changed my server name and fqdn and now the mail to root@localhost is bouncing. I went into every file that had the old name and changed it to the new name but it still doesn't work. I did "grep -r something.else /etc" to find all the files. so, if I want to use mail.example.com as my fqdn, and the old fqdn was something.else and r...@something.else was redirecting mail to m...@something.else ... then what do I need to change in Exim to make this happen? root@localhost is bouncing r...@mail.example.com is bouncing m...@mail.example.com is working /etc/mailname is this line: mail.example.com I would also like to be able to send mail to me@mail instead of m...@mail.example.com ... if this is possible. I did "grep -r something.else /etc" and changed all the files to the mail.example.com name and then ran the "update-exim4.conf" if you reply, please CC me directly because it is hard to find messages in this list because of the high volume. Thanks
root@localhost mail not forwarding in Exim
I changed my server name and fqdn and now the mail to root@localhost is bouncing. I went into every file that had the old name and changed it to the new name but it still doesn't work. I did "grep -r something.else /etc" to find all the files. so, if I want to use mail.example.com as my fqdn, and the old fqdn was something.else and r...@something.else was redirecting mail to m...@something.else ... then what do I need to change in Exim to make this happen? root@localhost is bouncing r...@mail.example.com is bouncing m...@mail.example.com is working /etc/mailname is this line: mail.example.com I would also like to be able to send mail to me@mail instead of m...@mail.example.com ... if this is possible. I did "grep -r something.else /etc" and changed all the files to the mail.example.com name and then ran the "update-exim4.conf" if you reply, please CC me directly because it is hard to find messages in this list because of the high volume. Thanks
$spam_score value change in exim + spamassassin
Would anyone know offhand what might be changing the value of variable $spam_score in the acl/40_exim4-config_check_data section of the exim4 configuration file exim4.conf.template? It's an idle question but I'm curious why I would be getting a header like this: X-Spam_score: 10.8 X-Spam_score_int: 108 X-Spam_bar: ++ Subject: ***SPAM (score:8.3)*** Is Donald Trump Headed For A Heart Attack? when the text of the config file looks like this: warn spam = Debian-exim:true add_header = X-Spam_score: $spam_score\n\ X-Spam_score_int: $spam_score_int\n\ X-Spam_bar: $spam_bar\n\ X-Spam_report: $spam_report # add second subject line with *SPAM* marker when message # is over threshold warn spam = nobody add_header = Subject: ***SPAM (score:$spam_score)*** $h_Subject: So something changes the value of $spam_score between the two warnings. How does that happen? Thanks for looking. Mark
Re: Configuring Exim for mail delivery
On 2016-10-02, Brian wrote: > On Sun 02 Oct 2016 at 21:41:50 +0900, Mark Fletcher wrote: > >> On Sun, Oct 02, 2016 at 12:52:44PM +0100, Brian wrote: >> > >> > I have the same setup and all customisations (apart from hubbed_hosts) >> > have been done via debconf. TBH, I cannot see why /etc/hosts should be >> > consulted because I thought there is first a check for an MX record and >> > then an attempt to resolve the host *using the DNS* if there was none. >> > >> > Your instructions are clear so I can continue to try more customising >> > via debconf. >> > >> > mo appears to have had no more success than I have. Don't know about >> > Mark. >> > >> > -- >> > Brian >> > >> >> That's twice you've mentioned conf.d now, bear in mind in a >> defaults-accepting Debian installation of exim4, it's not used. > > It shouldn't make any difference whether the split configuration is used > or not for what we are doing. > > A defaults-accepting installation would use "local delivery only; not on > a network". Obviously this would not suit testing mail delivery to other > machines on the LAN. It was at this first page I made my mistake! > > I chose "Internet site.." because that is the way I always send > mail. No wonder I got "Unrouteable address". Was it clear that I should > have used "mail sent by smarthost.." (Liam?)?. Mystery solved. I've > not tested extensively but I can get mail to go to a user on another > machine. §2.1 of /usr/share/doc/exim4-base/README.Debian.html (from exim4-base) provides some assistance. > > I'm not enamoured of this technique because it does not suit my mail > setup. So I will stick with the more versatile hubbed_hosts. > > Thanks for all the clues. > At least your curiosity has been satisfied. :) -- Liam
Re: Configuring Exim for mail delivery
On Sun, Oct 02, 2016 at 09:17:58AM -0400, Gene Heskett wrote: > On Sunday 02 October 2016 08:41:50 Mark Fletcher wrote: > > > On Sun, Oct 02, 2016 at 12:52:44PM +0100, Brian wrote: > > > [Some snipping. Not too much, I hope]. > > > > > > On Sun 02 Oct 2016 at 01:05:20 +0100, Liam O'Toole wrote: > > > > On 2016-10-01, Brian wrote: > > > > > Exim's default behaviour, as has been mentioned a couple of > > > > > times in this thread, is to use DNS; nsswitch is not involved. > > > > > > > > Doing an strace on the exim command shows that /etc/nsswitch is > > > > consulted first, then /etc/resolv.conf (followed by a DNS lookup > > > > of the smarthost). > > > > > > This is what I cannot get round. I'm prepared to accept that my > > > understanding may be defective but when I see "driver = dnslookup" > > > in router/200_exim4-config_primary it fits what I observe. Which is > > > why I use a hubbed_hosts file to manually route mail to machines on > > > the LAN. > > > > > > > > This is a default > > > > > exim install; no files in conf.d altered. How about you? > > > > > > > > No alterations I can remember, and 'dpkg --verify' reports no > > > > changes to exim4-related files. All customisations have been done > > > > via debconf. I am reluctant to divulge those customisations here, > > > > but I can tell you that the settings are not particularly exotic. > > > > One host on the local network is configured to use my ISP's SMTP > > > > server as its smarthost, while the other hosts in turn use the > > > > former as their smarthost. > > > > > > I have the same setup and all customisations (apart from > > > hubbed_hosts) have been done via debconf. TBH, I cannot see why > > > /etc/hosts should be consulted because I thought there is first a > > > check for an MX record and then an attempt to resolve the host > > > *using the DNS* if there was none. > > > > > > Your instructions are clear so I can continue to try more > > > customising via debconf. > > > > > > mo appears to have had no more success than I have. Don't know about > > > Mark. > > > > > > -- > > > Brian > > > > That's twice you've mentioned conf.d now, bear in mind in a > > defaults-accepting Debian installation of exim4, it's not used. > > > > Mark > > Uuh, Mark, here on an up to date wheezy install, with exim4's default > config untouched, it does indeed exist, as /etc/exim4/conf.d, and its > populated with quite a few subdirs. > = Yup, here too. But it is not being used. Mark
Re: Configuring Exim for mail delivery
On Sun 02 Oct 2016 at 21:41:50 +0900, Mark Fletcher wrote: > On Sun, Oct 02, 2016 at 12:52:44PM +0100, Brian wrote: > > > > I have the same setup and all customisations (apart from hubbed_hosts) > > have been done via debconf. TBH, I cannot see why /etc/hosts should be > > consulted because I thought there is first a check for an MX record and > > then an attempt to resolve the host *using the DNS* if there was none. > > > > Your instructions are clear so I can continue to try more customising > > via debconf. > > > > mo appears to have had no more success than I have. Don't know about > > Mark. > > > > -- > > Brian > > > > That's twice you've mentioned conf.d now, bear in mind in a > defaults-accepting Debian installation of exim4, it's not used. It shouldn't make any difference whether the split configuration is used or not for what we are doing. A defaults-accepting installation would use "local delivery only; not on a network". Obviously this would not suit testing mail delivery to other machines on the LAN. It was at this first page I made my mistake! I chose "Internet site.." because that is the way I always send mail. No wonder I got "Unrouteable address". Was it clear that I should have used "mail sent by smarthost.." (Liam?)?. Mystery solved. I've not tested extensively but I can get mail to go to a user on another machine. I'm not enamoured of this technique because it does not suit my mail setup. So I will stick with the more versatile hubbed_hosts. Thanks for all the clues. -- Brian.
Re: Configuring Exim for mail delivery
On Sunday 02 October 2016 08:41:50 Mark Fletcher wrote: > On Sun, Oct 02, 2016 at 12:52:44PM +0100, Brian wrote: > > [Some snipping. Not too much, I hope]. > > > > On Sun 02 Oct 2016 at 01:05:20 +0100, Liam O'Toole wrote: > > > On 2016-10-01, Brian wrote: > > > > Exim's default behaviour, as has been mentioned a couple of > > > > times in this thread, is to use DNS; nsswitch is not involved. > > > > > > Doing an strace on the exim command shows that /etc/nsswitch is > > > consulted first, then /etc/resolv.conf (followed by a DNS lookup > > > of the smarthost). > > > > This is what I cannot get round. I'm prepared to accept that my > > understanding may be defective but when I see "driver = dnslookup" > > in router/200_exim4-config_primary it fits what I observe. Which is > > why I use a hubbed_hosts file to manually route mail to machines on > > the LAN. > > > > > > This is a default > > > > exim install; no files in conf.d altered. How about you? > > > > > > No alterations I can remember, and 'dpkg --verify' reports no > > > changes to exim4-related files. All customisations have been done > > > via debconf. I am reluctant to divulge those customisations here, > > > but I can tell you that the settings are not particularly exotic. > > > One host on the local network is configured to use my ISP's SMTP > > > server as its smarthost, while the other hosts in turn use the > > > former as their smarthost. > > > > I have the same setup and all customisations (apart from > > hubbed_hosts) have been done via debconf. TBH, I cannot see why > > /etc/hosts should be consulted because I thought there is first a > > check for an MX record and then an attempt to resolve the host > > *using the DNS* if there was none. > > > > Your instructions are clear so I can continue to try more > > customising via debconf. > > > > mo appears to have had no more success than I have. Don't know about > > Mark. > > > > -- > > Brian > > That's twice you've mentioned conf.d now, bear in mind in a > defaults-accepting Debian installation of exim4, it's not used. > > Mark Uuh, Mark, here on an up to date wheezy install, with exim4's default config untouched, it does indeed exist, as /etc/exim4/conf.d, and its populated with quite a few subdirs. = gene@coyote:~$ ls -l /etc/exim4/conf.d total 28 drwxr-xr-x 2 root root 4096 Apr 4 21:35 acl drwxr-xr-x 2 root root 4096 Apr 4 21:35 auth drwxr-xr-x 2 root root 4096 Apr 4 21:35 main drwxr-xr-x 2 root root 4096 Apr 4 21:35 retry drwxr-xr-x 2 root root 4096 Apr 4 21:35 rewrite drwxr-xr-x 2 root root 4096 Apr 4 21:35 router drwxr-xr-x 2 root root 4096 Apr 4 21:35 transport == Based on the dates, I have to assume exim4 was pulled in as a dependency of something else I installed recently since this wheezy install is around 2 years old now. It's installation did not effect how my machine runs that I am aware of. According to htop, no daemon of that name is currently running. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
Re: Configuring Exim for mail delivery
On Sun, Oct 02, 2016 at 12:52:44PM +0100, Brian wrote: > [Some snipping. Not too much, I hope]. > > On Sun 02 Oct 2016 at 01:05:20 +0100, Liam O'Toole wrote: > > > On 2016-10-01, Brian wrote: > > > > > > Exim's default behaviour, as has been mentioned a couple of times in > > > this thread, is to use DNS; nsswitch is not involved. > > > > Doing an strace on the exim command shows that /etc/nsswitch is > > consulted first, then /etc/resolv.conf (followed by a DNS lookup of the > > smarthost). > > This is what I cannot get round. I'm prepared to accept that my > understanding may be defective but when I see "driver = dnslookup" in > router/200_exim4-config_primary it fits what I observe. Which is why I > use a hubbed_hosts file to manually route mail to machines on the LAN. > > > > This is a default > > > exim install; no files in conf.d altered. How about you? > > > > No alterations I can remember, and 'dpkg --verify' reports no changes to > > exim4-related files. All customisations have been done via debconf. I am > > reluctant to divulge those customisations here, but I can tell you that > > the settings are not particularly exotic. One host on the local network > > is configured to use my ISP's SMTP server as its smarthost, while the > > other hosts in turn use the former as their smarthost. > > I have the same setup and all customisations (apart from hubbed_hosts) > have been done via debconf. TBH, I cannot see why /etc/hosts should be > consulted because I thought there is first a check for an MX record and > then an attempt to resolve the host *using the DNS* if there was none. > > Your instructions are clear so I can continue to try more customising > via debconf. > > mo appears to have had no more success than I have. Don't know about > Mark. > > -- > Brian > That's twice you've mentioned conf.d now, bear in mind in a defaults-accepting Debian installation of exim4, it's not used. Mark
Re: Configuring Exim for mail delivery
[Some snipping. Not too much, I hope]. On Sun 02 Oct 2016 at 01:05:20 +0100, Liam O'Toole wrote: > On 2016-10-01, Brian wrote: > > > > Exim's default behaviour, as has been mentioned a couple of times in > > this thread, is to use DNS; nsswitch is not involved. > > Doing an strace on the exim command shows that /etc/nsswitch is > consulted first, then /etc/resolv.conf (followed by a DNS lookup of the > smarthost). This is what I cannot get round. I'm prepared to accept that my understanding may be defective but when I see "driver = dnslookup" in router/200_exim4-config_primary it fits what I observe. Which is why I use a hubbed_hosts file to manually route mail to machines on the LAN. > > This is a default > > exim install; no files in conf.d altered. How about you? > > No alterations I can remember, and 'dpkg --verify' reports no changes to > exim4-related files. All customisations have been done via debconf. I am > reluctant to divulge those customisations here, but I can tell you that > the settings are not particularly exotic. One host on the local network > is configured to use my ISP's SMTP server as its smarthost, while the > other hosts in turn use the former as their smarthost. I have the same setup and all customisations (apart from hubbed_hosts) have been done via debconf. TBH, I cannot see why /etc/hosts should be consulted because I thought there is first a check for an MX record and then an attempt to resolve the host *using the DNS* if there was none. Your instructions are clear so I can continue to try more customising via debconf. mo appears to have had no more success than I have. Don't know about Mark. -- Brian
Re: Configuring Exim for mail delivery
On 2016-10-02, Mark Fletcher wrote: > On Sat, Oct 01, 2016 at 11:22:06PM +0100, Brian wrote: >> >> We all know a hubbed_hosts file works. Mark Fletcher has written >> extensively about it and I have said a thing or too also. What I want to >> know is why following the advice from Liam O'Toole doesn't work for me, >> even though I have followed the instructions exactly. >> > > I think Liam is describing a situation where the only mail-capable > machine is the server, in your example gnome.monet. He configured it to > be the end-point for *.monet. But for mo's original use-case, gnome > should only be the end-point for gnome.monet and desktop should be the > end-point for desktop.monet. Then, if gnome.monet gets handed a mail for > desktop.monet, it doesn't try to deliver it, but instead tries to pass > it on, and that's when you need hubbed_hosts populated so it can find > desktop.monet to pass it on to. > > So Liam has consistently been describing a solution that, while > perfectly valid, is the solution to a slightly different problem than > the one mo originally asked about. > > Mark > > My setup is more or less as you describe. The only difference is that all machines are mail capable and use the local server as their smarthost, while the server in turn uses an external smarthost. Brian seems to be experiencing a more fundamental issue, where exim refuses to resolve domain names in the expected manner. That one has me stumped. -- Liam
