Re: [exim] Routing failed deliveries through an ESP
On 17/04/2023 14:08, Bill Cole via Exim-users wrote: There's a rational basis for an exception for 5xx before MAIL FROM, when the target only has the connection parameters and HELO name to use as a basis for rejection. Re-routing via a fallback path isn't entirely unjustifiable in that case, as it changes those elements of the transaction. Exim treats what you're talking of as a "host error" rather than a "message error", and goes on to try the next host in the list of possibles determined by the routing stage. Commonly that would be a lower-priority MX for the domain. -- 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] Dynamic received_header_text
On 17/04/2023 12:26, Jeremy Harris via Exim-users wrote: The documentation does answer these questions. Was some of it unclear? You are absolutely right. I did read the documentation before posting, but I missed the bit where it says received_header_text is expanded each time it is used. Sorry for the noise. -- ## 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] Routing failed deliveries through an ESP
On Mon, Apr 17, 2023 at 08:54:37AM +0100, Graeme Fowler via Exim-users wrote: > > How might I configure my routers to ignore an initial 5xx response from the > > first router and attempt another (and maybe future) deliveries through an > > alternate router? > > If you get a 5xx error from the receiver's MX, you do the right thing and > abide by it. They're telling you they didn't want your message. A mail transaction (transmission of a particular message), begins at the MAIL command and ends at DOT. Any errors outside that context are not message specific. In particular, they might simply reflect the unwillingness of the host in question to accept any mail, which may not be the case with other MX hosts. In decades past, when now popular MTAs (Exim and Postfix) were new and evolving their basic SMTP protocol features, it was not uncommon for for some (IIRC Microsoft Exchange) receiving systems to intermittently return 5XX when their load was too high. Consequently, at least Postfix was then, and is still by default now "tolerant" of 5XX greetings: smtp_skip_5xx_greeting = yes This is limited to just the initial banner, not EHLO or later, so apparently transient misguided 5XX responses to EHLO are not a common problem. Therefore, I'd be inclined to consider also 5XX in response to EHLO as a reason to abandom delivery and bounce the envelope. -- 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] Routing failed deliveries through an ESP
• Lance Lovette via Exim-users [2023-04-16 21:01]: [...] > How might I configure my routers to ignore an initial 5xx response from the > first router and attempt another (and maybe future) deliveries through an > alternate router? Maybe recipient verification callout facility could be used, and ACL setting ACL variables somehow depending on the callout verification result, and later selecting router depending on those ACL variables. See https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTcallver See also https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTaclvariables K. -- ## 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] Routing failed deliveries through an ESP
On 2023-04-17 at 03:54:37 UTC-0400 (Mon, 17 Apr 2023 08:54:37 +0100) Graeme Fowler via Exim-users is rumored to have said: On 17 April 2023 03:08:29 Lance Lovette via Exim-users wrote: How might I configure my routers to ignore an initial 5xx response from the first router and attempt another (and maybe future) deliveries through an alternate router? I'm going to make the very obvious and morally correct answer: you don't. If you get a 5xx error from the receiver's MX, you do the right thing and abide by it. They're telling you they didn't want your message. There's a rational basis for an exception for 5xx before MAIL FROM, when the target only has the connection parameters and HELO name to use as a basis for rejection. Re-routing via a fallback path isn't entirely unjustifiable in that case, as it changes those elements of the transaction. If you've got such a problem with IP or domain reputation that you end up on DNSBLs with any frequency, you need to work on that rather than palming off your messages to a third party. Like it or not, DNSBLs are far from the only reason MTAs use to reject mail. In the case of early 5xx rejections, it is likely that a public DNSBL is not the mechanism in use. Fixing whatever problem caused a particular site to get cranky about Linode or OVH or Digital Ocean or whatever other garbage VPS provider is a problem this month isn't feasible for their individual customers. That said: why not just send via the ESP in the first place? ESPs come with their own reputational issues. Deliverability for modest volume non-bulk mail is a difficult problem. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- ## 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] Dynamic received_header_text
The documentation does answer these questions. Was some of it unclear? -- 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] Routing failed deliveries through an ESP
> I'm going to make the very obvious and morally correct answer: you don't. I truly understand and at a basic level agree with that position. I'm simply trying to balance that with what is analogous to a short-term network outage. I need to have a failover in place to keep the business functioning while I work to resolve the issue. > why not just send via the ESP in the first place? Cost savings. We'd prefer to pay the ESP to deliver only what it must and let our server deliver most of the messages most of the time. This is top of mind now because we're about to stand up a new server and I won't have a good picture of the IP reputation until the bounces start rolling in. It will take weeks to get everything running smoothly. In the meantime, bounces will cause chaos :) The alternative is to implement a process outside of Exim that monitors the reject log and re-attempts delivery, skipping dnslookup, but I'm hoping the right Exim router configuration will save us the (non-trivial) effort. Thanks! Lance -- ## 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] Proxy smtp connections to multiple Exim servers behind proxy
c On 17/04/2023 04:33, Ian Z via Exim-users wrote: On Sun, Apr 16, 2023 at 07:11:51PM +0100, Sebastian Arcus via Exim-users wrote: One thing I have to try and figure out is how Spamassassin does the SPF checks. Does it look at all the Received: headers, and if at least one of them matches one of the SPF records, then it's all fine? Because if that's how it works, SA checks should pass even if done on the back-end Exim server. I don't think it would work by default. SA has a concept of "trusted" Received headers (because, of course, in general spammers can and do forge headers) and by default only the first is trusted, ie. the one added by the MTA that ultimately called SA. I think there is a way to tweak the trusted setting, but Thank you very much for that. It would make sense - all Received: headers before the latest one in the chain could be added by spammers manually. I looked it up and it seems that Exim can be told not to add a Received: header when handling email - by configuring in the corresponding transport: received_header_text = "" I'm not entirely happy with the idea of interfering with the record of message flow - but I guess it remains an option. I might just add a custom header instead, so that I will know the message has been through the front-end machine - for diagnostic purposes. - configuration of SA is complex (though not as much as exim, lol) - I don't know if that would actually change the SPF result. I couldn't agree more. I am permanently scarred emotionally from installing and configuring SpamAssassin for the first time - and even after years of working with it I don't feel like I've managed to tame it :-) -- ## 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] Dynamic received_header_text
This question is related to my other thread which deals with Exim being used in a front-end / back-end configuration, with back-end machines handling separate email domains. I thought it would be better to post a separate thread, in case it would help someone find it one day. I would like the Received header to be set to empty only for incoming emails - so as not to break SPF checks on Spamassassin on back-end servers. Is it possible to either: 1. Set 'received_header_text' to and empty string inside the corresponding router or transport config - or global variables can't be amended inside routers or transports? 2. Otherwise, configure 'received_header_text' to use some conditional statements, which return an empty string if the message is an incoming message. Does 'received_header_text' get re-evaluated every time email is processed - or is it only evaluated once - so this wouldn't work? Any suggestions much appreciated. -- ## 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] Routing failed deliveries through an ESP
On 17/04/2023 02:01, Lance Lovette via Exim-users wrote: How might I configure my routers to ignore an initial 5xx response from the first router and attempt another (and maybe future) deliveries through an alternate router? You can't. A permenent error response for a message is definitive. -- 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] Routing failed deliveries through an ESP
On 17 April 2023 03:08:29 Lance Lovette via Exim-users wrote: How might I configure my routers to ignore an initial 5xx response from the first router and attempt another (and maybe future) deliveries through an alternate router? I'm going to make the very obvious and morally correct answer: you don't. If you get a 5xx error from the receiver's MX, you do the right thing and abide by it. They're telling you they didn't want your message. If you've got such a problem with IP or domain reputation that you end up on DNSBLs with any frequency, you need to work on that rather than palming off your messages to a third party. That said: why not just send via the ESP in the first place? Graeme -- ## 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] log_selector and the reject log
Hello, I think section 53.15 should be explicit that the log_selector only applies to the main log. There are some log messages, namely those from synprot_error in smtp_in.c, that go *both* to main and reject log. It depends on log_selector if it in fact shows up in the main log, but there is not such filtering logic for the reject log; these log lines always show up there. The behavior itself is somewhat counterintuitive to me, but my intuition is weird at times, so I will let that pass. But it should be documented to avoid confusing people who want to minimize log volume. -- Ian -- ## 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/
