Re: [exim] interface and greylistning
On 2022-11-21, Laura Williamson via Exim-users wrote:
> Have a bit of an issue. When sending out emails out exim select an
> interface like this
>
> interface = ${lookup sqlite {SQLITE_Q_USERINTERFACE select ip from
> interface where active='Y' order by random() limit 1}{$value}}
> helo_data = ${lookup
> dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}}
>
> Which works perfectly fine, however, if the server we send to has
> greylisting it will try again but every time it will select a new
> interface IP and therefore might get greylisted again (as the IP now is
> different), is there a way around this?
don't use random, use somethign repeatable instead eg:
${listextract{${eval:1+(${base62d:${substr_14_2:$message_exim_id}}%5)}}{\
10.0.0.1:10.0.0.2:10.0.0.3:10.0.0.4:10.0.0.5}{$value}{10.0.0.1}}
Here the feactional-seconds part of $message_exim_id is used as a
repeatable pseudo-random number. the range is (0..499)
you can possibly use the sha1 function to get repeatable pseudo-random
values by salting the ip-address with the exim-id of the message.
interface = ${lookup sqlite {SQLITE_Q_USERINTERFACE select ip from \
interface where active='Y' \
order by sha1(ip || '${quote_sqlite:$message_exim_id}' ) \
limit 1}{$value}}
--
Jasen.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] debugging tls handshake failure
On 21/11/2022 21:41, Julian Bradfield via Exim-users wrote: I should like to know what's happening here: 2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk [130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received. However, I can't see how to get any more information. I've tried setting add_environment = GNUTLS_DEBUG_LEVEL=3 in the exim4 config file, but it doesn't appear to do anything. Is there a way to get more information? The gnutls library helpfully (I infer) reads the environment at process startup, too early for the config-driven addition of that variable. Try having the thing firing off the exim process adding to the environment instead. You'll need to add it to keep_environment. I go up to 9 on occasion, but 3 is reasonably detailed. Alternatively, since you know there's an alert involved, go down the packet capture route. You'll need to add_environment = SSLKEYLOGFILE=/sslkeys and tell wireshark where to pick them up (edit/pref/protocols/tls/ Master Secret Log filename) -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] debugging tls handshake failure
On Mon, Nov 21, 2022 at 09:41:12PM +, Julian Bradfield via Exim-users wrote: > I should like to know what's happening here: > > 2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk > [130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received. OpenSSL would usually log the alert number (and associated text string), from which one could infer more information about what the remote client is unhappy about. I'd hope that GnuTLS could also log this (or make the alert info available to Exim to optionally log). That said, the most common issues that remote clients are unhappy about are untrusted certificates and expired certificates. Perhaps you have a Let's Encrypt certificate chain that includes a cross cert to the now expired DST Root CA (for Android compatibility). You can configure certbot et. al. to build a chain that skips the cross cert, expecting clients to support the ISRG root. https://www.mail-archive.com/postfix-users@postfix.org/msg94314.html -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] debugging tls handshake failure
On Mon, Nov 21, 2022 at 09:41:12PM +, Julian Bradfield via Exim-users wrote: > I should like to know what's happening here: > > 2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk > [130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received. > If the server in question is "london.jcbradfield.org", then another potential issue is a missing intermediate issuer certificate. Your certificate chain has only the leaf server certificate without the required "R3" intermediate issuer certificate. If using certbot, use "fullchain.pem" not "cert.pem" (or the equivalent for a different setup). -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] debugging tls handshake failure
I should like to know what's happening here: 2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk [130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received. However, I can't see how to get any more information. I've tried setting add_environment = GNUTLS_DEBUG_LEVEL=3 in the exim4 config file, but it doesn't appear to do anything. Is there a way to get more information? -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] interface and greylistning
Hi,
Have a bit of an issue. When sending out emails out exim select
an interface like this
interface = ${lookup sqlite {SQLITE_Q_USERINTERFACE select ip
from interface where active='Y' order by random() limit
1}{$value}}
helo_data = ${lookup
dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}}
Which works perfectly fine, however, if the server we send to
has greylisting it will try again but every time it will select
a new interface IP and therefore might get greylisted again (as
the IP now is different), is there a way around this?
Depending on what goals you were trying to achieve with the
multiple-interfaces, one option might be to swap the "random()" for
something based on a consistent hash of message properties.
That way you could still get load balanced over the interfaces but a given
message would always select the same interface and you wouldn't have to
store any extra state.
Best wishes,
@ndy
--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
--
## 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] interface and greylistning
On Mon, Nov 21, 2022 at 08:14:41AM +, Laura Williamson via Exim-users wrote:
> interface = ${lookup sqlite {SQLITE_Q_USERINTERFACE select ip from interface
> where active='Y' order by random() limit 1}{$value}}
> helo_data = ${lookup
> dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}}
>
> Which works perfectly fine, however, if the server we send to has
> greylisting it will try again but every time it will select a new interface
> IP and therefore might get greylisted again (as the IP now is different), is
> there a way around this?
The counter-question is "Why do you do it?" Probably you want to use
IP-address randomization as a tool to overcome connectivity problems.
I don't know other reasons to use rotary IP pools (but they may exist).
However, if connection was successful and host replies with 4xx status code,
there is no connectivity problem. Hence IP rotation should be stopped or
suspended for some reasonable time (~ 30m-2h).
--
Eugene Berdnikov
--
## 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] interface and greylistning
On 21/11/2022 08:14, Laura Williamson via Exim-users wrote:
Have a bit of an issue. When sending out emails out exim select an interface
like this
interface = ${lookup sqlite {SQLITE_Q_USERINTERFACE select ip from interface
where active='Y' order by random() limit 1}{$value}}
helo_data = ${lookup dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}}
Which works perfectly fine, however, if the server we send to has greylisting
it will try again but every time it will select a new interface IP and
therefore might get greylisted again (as the IP now is different), is there a
way around this?
Nothing built-in.
You'd have to craft something involving remembering what interface you last
tried, and preferring it after a defer. That probably requires using an
event to write a DB entry on defer.
Or set up a static mapping from destination (host or domain) to
interface.
Or, stop trying to be clever with these multiple interfaces.
--
Cheers,
Jeremy
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] interface and greylistning
Have a bit of an issue. When sending out emails out exim select an
interface like this
interface = ${lookup sqlite {SQLITE_Q_USERINTERFACE select ip from
interface where active='Y' order by random() limit 1}{$value}}
helo_data = ${lookup
dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}}
Which works perfectly fine, however, if the server we send to has
greylisting it will try again but every time it will select a new
interface IP and therefore might get greylisted again (as the IP now is
different), is there a way around this?
--
## 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/
