Re: [exim] Google SMTP Timeouts on large mails
On Fri, 2022-04-29 at 10:56 +0100, Graeme Coates via Exim-users wrote: > Hi all, > > > > I've seen this issue raised in: > > > > https://lists.exim.org/lurker/message/20220216.071725.892984cd.en.html > > and > > https://lists.exim.org/lurker/message/20220313.200645.624cc373.en.html > > > > but haven't seen a definite resolution as yet. > > > > As per other reports, I have a Debian Bullseye (11.3) system running > This is likely to be the result of a known issue with Google's TCP Fast Open setup - see e.g. https://blog.apnic.net/2021/07/05/tcp-fast-open-not-so-fast/ Exim 4.93 changed the default for the "hosts_try_fastopen" transport option to be "*", and the default for the net.ipv4.tcp_fastopen_blackhole_timeout_sec sysctl changed from 3600 (i.e. an hour) to 0 at some point between the kernel versions in Debian buster (10) and bullseye (11). A workaround is to add something similar to "hosts_try_fastopen = ! *.l.google.com" to your SMTP transports. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] exim.org still incorrectly configured
On Sat, 2021-10-16 at 18:44 +0200, Heiko Schlittermann via Exim-users wrote: > Adam D. Barratt via Exim-users (Sa 16 Okt 2021 > 17:43:57 CEST): > > > This hh.schlittermann.de runs the latest Exim, and probaby sends > > > you > > > an SNI your server for some reason doesn't accept? > > > > FWIW, I've also seen two of these, at 23:53:41UTC yesterday and > > 11:08:41UTC today. The server in question is running Debian's 4.92- > > 8+deb10u6 exim4-daemon-heavy package and has "tls_sni" set in the > > log > > selector. > > > > The log entries for the second failed connection are: > > > > 2021-10-16 11:08:40 SMTP connection from [213.128.132.49] (TCP/IP > > connection count = 1) > > 2021-10-16 11:08:41 TLS error on connection from > > hh.schlittermann.de [213.128.132.49] (gnutls_handshake): A > > disallowed SNI server name has been received. > > 2021-10-16 11:08:41 SMTP connection from hh.schlittermann.de > > [213.128.132.49] closed by EOF > > 2021-10-16 11:08:41 no MAIL in SMTP connection from > > hh.schlittermann.de [213.128.132.49] D=0s C=EHLO,STARTTLS > > > > The same server has received 21 successful connections from > > hh.schlittermann.de in the past couple of days. > > Interesting. Can you tell *what* SNI the server hh sent? Unfortunately the above appears to be all that's logged. > That's what the hh server uses as the transport: > [...] > So, it sends you *your* hostname as an SNI. That's indeed what I see for successful connections. I've hopefully enabled TLS debug logging for connections from hh, so we'll see if that provides any useful information if it happens again. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] exim.org still incorrectly configured
On Sat, 2021-10-16 at 17:22 +0200, Heiko Schlittermann via Exim-users wrote: > Slavko via Exim-users (Sa 16 Okt 2021 11:14:45 > CEST): > > I am not sure if it is related to migration, but recently i start > > to see > > something as this in my exim log: > > > > TLS error on connection from hh.schlittermann.de > > [213.128.132.49] > > (gnutls_handshake): A disallowed SNI server name has been > > received. > > > > The recent one was today at 2021-10-16 01:51:16. > > While it is related to the migration, it seems to be a side effect of > mitigating (hotmail/live/outlook)'s blacklist for the IP the "new > exim site" is using now. We're sending the mails via a server that > has better reputation at MS. > > This hh.schlittermann.de runs the latest Exim, and probaby sends you > an SNI your server for some reason doesn't accept? FWIW, I've also seen two of these, at 23:53:41UTC yesterday and 11:08:41UTC today. The server in question is running Debian's 4.92- 8+deb10u6 exim4-daemon-heavy package and has "tls_sni" set in the log selector. The log entries for the second failed connection are: 2021-10-16 11:08:40 SMTP connection from [213.128.132.49] (TCP/IP connection count = 1) 2021-10-16 11:08:41 TLS error on connection from hh.schlittermann.de [213.128.132.49] (gnutls_handshake): A disallowed SNI server name has been received. 2021-10-16 11:08:41 SMTP connection from hh.schlittermann.de [213.128.132.49] closed by EOF 2021-10-16 11:08:41 no MAIL in SMTP connection from hh.schlittermann.de [213.128.132.49] D=0s C=EHLO,STARTTLS The same server has received 21 successful connections from hh.schlittermann.de in the past couple of days. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Strange problem with the communication to ClamAV
On Mon, 2021-07-12 at 10:41 +0200, Luca Bertoncello via Exim-users wrote: > Am 12.07.2021 09:56, schrieb Andrew C Aitchison: [...] > > I had not noticed that this was paniclog. > > Do you need some sort of defer option so that exim handles clamav > > timeouts > > gracefully ? > > Not of all... > I'm using ClamAV 0.102.4+dfsg-0+deb10u1 from Debian 10 repositories. In that case you're missing security fixes from 0.103.2+dfsg-0+deb10u1, along with the graceful reload functionality that Andrew mentioned. That version has been in stable-updates since late April, and stable itself since the 10.10 point release a few weeks ago. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Exim and Sophos command line AV wrong exit codes?
On Sat, 2020-11-07 at 20:29 +, Mike Tubby via Exim-users wrote:
>
> On 07/11/2020 20:10, Adam D. Barratt via Exim-users wrote:
> > On Sat, 2020-11-07 at 17:45 +, Mike Tubby via Exim-users wrote:
> > > 2. the return value 512 (really 2) is tripping on a password
> > > encrypted ZIP file for which there is no right thing to do:
> > >
> > > a) accept it because we can't decrypt it [might still
> > > have a virus]; or
> > >
> > > b) reject it because we can't decrypt it [might not
> > > have a virus but might be confidential customer data]
> > >
> > > appears to be a loose-loose ;-(
> > fwiw what we do for $dayjob is to freeze them and get a human to
> > make the delivery decision. It's not foolproof, and depends on how
> > many such mails you're dealing with, but it works well enough for
> > us.
> >
> > Regards,
> >
> > Adam
> >
>
> Do you have a recipe that you can share?
We use a (mostly working still AFIACS) body match rather than relying
on the AV scanner to detect them, but effectively:
warn log_message = XH_WARN: Encrypted zip attachments are not allowed
condition = ${if match{$message_body:}{ UEsDB[Q-Za-fw-z0-9\+/]}}
[some local exceptions]
control = freeze
add_header = XH_WARN: Encrypted zip attachments are not allowed
(where XH_WARN is a macro that expands to a custom header name).
Regards,
Adam
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Exim and Sophos command line AV wrong exit codes?
On Sat, 2020-11-07 at 17:45 +, Mike Tubby via Exim-users wrote: > 2. the return value 512 (really 2) is tripping on a password > encrypted ZIP file for which there is no right thing to do: > > a) accept it because we can't decrypt it [might still have > a > virus]; or > > b) reject it because we can't decrypt it [might not have a > virus but might be confidential customer data] > > appears to be a loose-loose ;-( fwiw what we do for $dayjob is to freeze them and get a human to make the delivery decision. It's not foolproof, and depends on how many such mails you're dealing with, but it works well enough for us. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Temporary internal error
On 17/09/2020 20:56, Yves Goergen via Exim-users wrote: >PGSQL new connection: socket=/var/run/postgresql database=) > user=dfctl >lookup deferred: PGSQL invalid filename for socket: > /var/run/postgresql > > I'm not sure what's exactly invalid here. On Thu, 2020-09-17 at 22:43 +0200, Yves Goergen via Exim-users wrote: > It does the same, just without the trailing slash. Note that this > path is a directory, not a file. A UNIX domain socket is simply a special kind of file. The error message refers to a filename, and the example in the documentation uses a filename. So why are you passing it a directory name, rather than a filename? :-) Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] dsearch
On Thu, 2020-06-25 at 15:09 +0300, Evgeniy Berdnikov via Exim-users wrote: > On Thu, Jun 25, 2020 at 12:23:46PM +0100, Jeremy Harris via Exim- > users wrote: > > On 25/06/2020 11:42, Evgeniy Berdnikov via Exim-users wrote: > > > Isn't it easier to remove "." and ".." from dsearch scan list et > > > al? > > > Really they are special built-in items in majority of file > > > systems, > > > so it's pointless to put real data into such "files" and > > > consequently > > > no sense to lookup it. > > > > That would be a change in behaviour. We try try to avoid them > > whenever possible as they upset people. > > I'm sure nobody will be touched, and "dsearch" is very new lookup > type. The filters for dsearch are new, dsearch itself really isn't. (Pre-4.0) Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] quick question to ipv6 and "not a valid ip address for the interface"
On 2020-02-21 09:42, Cyborg via Exim-users wrote: i have a ipv6 ip running, which starts with 2a02: as soon as i set a "interface = 2a02:." in the remote transport, it get this: R=remoteusers T=remote_smtp defer (-1): "2a02" is not a valid IP address for the "interface" option for remote_smtp transport exim cuts the ip to the first block. Is there any special syntax for ipv6 ips to give in that option or do we need BOTH, an ipv4 and an ipv6 ip together on a 4/6 system? Yes, you'll have that issue anywhere you're using IPv6 addresses in the configuration: source="https://www.exim.org/exim-html-current/doc/html/spec_html/ch-starting_the_daemon_and_the_use_of_network_interfaces.html;> The default list separator in both cases is a colon, but this can be changed as described in section 6.21. When IPv6 addresses are involved, it is usually best to change the separator to avoid having to double all the colons. Which approach you take is up to you. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] sending e-mail through a directnic server
On Thu, 2019-11-28 at 14:00 +, Andrew C Aitchison via Exim-users wrote: > On Thu, 28 Nov 2019, Gary Dale via Exim-users wrote: [...] > > It looks like the remote smarthost thinks I'm not using TLS. > > No. TLS is about encryption. The 1iaJ5F-00053v-JS log says that the > remote smarthost thinks you are not *authenticating* (which should, > but may or may not be, encrytped). Given the configuration in the original mail, this is likely due to the fact that mail.rossland.dental is a CNAME, and reverse DNS for the eventual target resolves to "web152.dnchosting.com". Debian's Exim packaging describes the use of the passwd.client file in exim4-config-files(5), which in part says (with apologies for the longish quote): Please note that target.mail.server.example is currently the value that exim can read from reverse DNS: It first follows the host name of the target system until it finds an IP address, and then looks up the reverse DNS for that IP address to use the outcome of this query (or the IP address itself should the query fail) as index into /etc/exim4/passwd.client. This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one. Currently, you need to manually lookup all reverse DNS names for all IP addresses that your SMTP server host name points to, for example by using the host command. You may minimize this trouble by using a wild card entry or regular expressions, thus reducing the risk of divulging the password to the wrong SMTP server while reducing the number of necessary lines. For a deeper discussion, see the Debian BTS #244724. Thus, the hostname in passwd.client wants to be web152.dnchosting.com, not mail.rossland.dental. (Or potentially a regex or wildcard if the "152" is expected to change.) Regards Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Send mail to specific domains via smart host
On Fri, 2019-03-08 at 22:14 +, Jasen Betts via Exim-users wrote:
> dns_yahoo_aol:
> > debug_print = "R: dnslookup_yahoo_aol for
> > $local_part@$domain"
> > driver = dnslookup
> > domains = aol.com : yahoo.com
> > transport = remote_smtp_smarthost
> > route_list = mx.localrelay.com byname
> > same_domain_copy_routing = yes
>
> yahoo are tricky, they cover many domains, but I guess if you
> redirect the bulk theough your provider the remainder can pass viar
> direct smtp and be under the rate-limit.
>
> If I wanted to gatch more yahoo traffic I'd leave the domains
> restriction off and used an inverted ignore_target_hosts list with
> the IP addresses of the yahoo and aol MXs
>
> I's create a file called
>
> /etc/exim4/conf.d/routers/175_local_yahoo_warmup
>
> with
>
> NOT_YAHOO_MXEN= !98.137.159.0/24 : !66.218.85/24 : !67.195.229.0/24 :
> !74.6.137/24
>
> dns_yahoo_aol:
> debug_print = "R: dnslookup_yahoo_aol for
> $local_part@$domain"
> driver = dnslookup
>ignore_target_hosts = NOT_YAHOO_MXEN
> transport = remote_smtp_smarthost
> route_list = * mx.localrelay.com byname
> same_domain_copy_routing =
Rather than a) hard-coding a list and b) ignoring a negated list, might
I suggest something more like:
domainlist avoid_oath_mxes = *.yahoodns.net
dns_yahoo_aol:
debug_print = "R: dnslookup_yahoo_aol for $local_part@$domain"
driver = dnslookup
condition = ${if forany{${lookup dnsdb{>:
mxh=$domain}}}{match_domain{$item}{+avoid_oath_mxes}}}
transport = remote_smtp_smarthost
route_list = * mx.localrelay.com byname
Regards,
Adam
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Debian-Bug not stopping exim
On 2019-02-06 22:47, Graeme Fowler via Exim-users wrote: On 6 Feb 2019, at 22:03, Klaus Ethgen via Exim-users wrote: So there was a bug introduced in the last few weeks in start-stop-daemon that I have to find a way around. The current situation is not acceptable. At this point I’m going to be the person who says “this is not an Exim problem”. It’s affecting exim, I don’t doubt that - but start-stop-daemon is a feature of the init system in Debian, so you do need to raise it with them despite your misgivings about doing so. For the record, that's already been done by the exim package maintainer. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Exim 4.91 and eximstats
On Thu, 2018-04-19 at 16:23 +0100, Jeremy Harris via Exim-users wrote: > ".*?" - given the *, the ? is redundant. And then so is the > rest of the line. Apologies if I'm missing some other subtlety, but ".*?" is a non-greedy match - i.e. it will consume the fewest number of characters possible, and in particular in this case won't consume the remainder of the line. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] HostEurope anybody
On Sat, 2018-02-17 at 15:15 +, tech-lists via Exim-users wrote: > An IP *cannot* resolve to a CNAME as per RFC 1034. It must resolve to > an A-record, hence the error "reverse dns failure". Nope, I think you're wrong here. The nearest suggestion that I can find in 1034 (although not quite on the correct topic) is: Domain names in RRs which point at another name should always point at the primary name and not the alias. ... Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. There's absolutely no "must" in there, and indeed a "should not fail". Indeed, the concept of RDNS delegation, as per e.g. RFC 2317 (which is what the original query appears to revolve around) *requires* the immediate target of a reverse lookup to be able to be a CNAME. Regards, Adam -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
