Exim keeps sending the same mail

His exim was already configured for IPv6 or else it would be attempting to connect to rpsamd at ::1.

I just looked at my rspamd configuration and see that /etc/rspamd/rspamd.conf has all the bind_socket parameters set to "localhost:1133[2|3|4|5]", in my case that forced it to bind only to IPv4. https://rspamd.com/doc/workers/ says that to bind to both IPv4 and IPv6, it should be "*:113[2|3|4|5]" for the bind_sockets so that it would look more like:
[root@moe rspamd]# grep bind_socket rspamd.conf
bind_socket = "*:11333";
bind_socket = "*:11334";
bind_socket = "*:11332";
bind_socket = "*:11335";
 
Sorry i thought we were speaking of exim

github.com

[BUG] Release 2.3 broke listening on IPv6 · Issue #3254 · rspamd/rspamd

We are running rspamd in an IPv6 only environment, that's the reason we ran into this issue. rspamd is running in a separate container, postfix and dovecot are running in others. Just to clarify ou...
github.com github.com

And yes as you said

Workers documentation | Rspamd Documentation

Rspamd defines several types of worker processes, each designed for specific purposes.
rspamd.com rspamd.com

All workers share a set of common options. Here is a typical example of a normal worker configuration that uses merely common worker options:

worker "normal" {
bind_socket = "*:11333";
}

Here are options available to all workers:

  • bind_socket - a string that defines bind address of a worker. If the port number is omitted, port 11333 is assumed.
  • count - number of worker instances to run (some workers ignore that option, e.g. hs_helper)
  • enabled (1.6.2+) - a Boolean (true or false), enable or disable a worker (true by default)
bind_socket is the mostly common used option. It defines the address where worker should accept connections. Rspamd allows both names and IP addresses for this option:

bind_socket = "localhost:11333";
bind_socket = "127.0.0.1:11333";
bind_socket = "[::1]:11333"; # note that you need to enclose ipv6 in '[]'

Also universal listening addresses are defined:

bind_socket = "*:11333"; # any ipv4 and ipv6 address
bind_socket = "*v4:11333"; # any ipv4 address
bind_socket = "*v6:11333"; # any ipv6 address
Click to expand...
 
Yep!
Code: 
Support for: crypteq IPv6 Perl OpenSSL move_frozen_messages Content_Scanning DKIM DNSSEC Event OCSP PIPE_CONNECT PRDR TCP_Fast_Open Experimental_SRS

/etc/rspamd/rspamd.conf does not exist.
 
I think I found the problem:

Example 1:
Code: 
2021-02-01 08:51:45 1l6Tzt-0007v1-90 <= [REDACTED] H=[REDACTED] P=esmtpa A=login:[REDACTED] S=12210 id=011901d6f86f$16bc0f10$44342d30$@DOMAIN1 T="test 2" from <[REDACTED]> for [REDACTED]
2021-02-01 08:53:10 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1l6Tzt-0007v1-90
2021-02-01 08:53:11 1l6Tzt-0007v1-90 => [REDACTED] F=<[REDACTED]> R=lookuphost T=remote_smtp S=12516 H=[REDACTED] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C="250 2.0.0 36dtwu8997-1 Message accepted for delivery"
2021-02-01 08:53:11 1l6Tzt-0007v1-90 Completed

Example 2:
Code: 
2021-02-03 15:17:06 1l7Ixu-0001kP-F3 <= [REDACTED] H=[REDACTED] P=esmtps X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=60523 DKIM=leica-geosystems.com id=AM6PR06MB51442A2103A752FA67E03671D5B49@AM6PR06MB5144.eurprd06.prod.outlook.com T="Factuur voor huurcontract 46058743" from <[REDACTED]> for [REDACTED]
2021-02-03 15:17:06 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1l7Ixu-0001kP-F3
2021-02-03 15:17:06 1l7Ixu-0001kP-F3 => info <[REDACTED]> F=<[REDACTED]> R=virtual_user T=dovecot_lmtp_udp S=61536 C="250 2.0.0 <[REDACTED]> PW0gKWKwGmDzFgAAuApPFA Saved"
2021-02-03 15:17:06 1l7Ixu-0001kP-F3 Completed

In the first example Exim is taking it's sweet time to get to the second step. This is over a minute which is the default Outlook server time-out if I'm not mistaken. The second mail get's processed way quicker and doesn't give any issues.

Does anyone have an idea why Exim is taking that long?
Since it happens on 4 different servers now, I doubt is has something to do with memory since they are really not that busy.
 
I now get mails from clients that notice the same behaviour in webmail.
The mail takes a long time to sent, anyone an idea how to proceed?
 
Outlook use grey list , so first mail is in "que ..."

If using in test to fast again and again, resending in to short time notice that is no good, while then the blocking mechanisme there is..

guessing..
 
Last edited:
I don't think that is the problem...
In my opinion Exim is taking to long to process the mail which causes Outlook to reach the default time-out for the connection (60 seconds).
Outlook then assumes the sending has failed (which is hasn't) and tries again in a couple of minutes.

Since clients are also noticing the delay while using webmail it doesn't seem to be Outlook who is to blame here.
 
Leap said:
It does not happen if we sent through Exchange...

Rebuilding Exim and dovecot is a start, gonna try it...
Click to expand...
Yes Exchange uhum this is MS so their products.

We have for over 20 years other mail products , and yes to exchange working ... MS is holding kind of monopol, and other products have many many difficulties , so no fair "trade.."

Only the practice some has to change a config or setting at exchange, does such exchange admins and their IT company's that sell saying no good product, they even don't bother to set a right config for those that are using other product MTA's

They are demanding to swicth over to them and use exchange.

So if doing test do them also against no outlook exchange products, then if there all is ok, do tests outlook, exchange, and look further into that, and yes very hard to let them have the right config / settings.

Most easy is asking for kind of white listing at those that are using outlook exchange. Even that is hard to get while they stand above all...

For tls and cypher versions and so on much problems for to old or wrong configs exchange .. but that normally you can see in log files
 
You must log in or register to reply here.
Back
Top