> Now I would like to configure this server as a smarthost, so it will
> forward emails from my desktop computers (without static IP or DNS).
> Also, I'd like to have unique mailnames for each desktop, like
> .mydomain.org, to better identify where the mail originated
> from. But these domains do n
> This is a very interesting and valid point! I could actually quite
> easily create MX entries for the host's subdomains on mydomain.org,
> so that MX .mydomain.org points to mydomain.org.
>
> But does that mean that in turn, each of these subdomains would need
> to be added as a local domain in e
> > So for me, the exim email system on the desktop computers is
> > exclusively used by the Linux operating system. I do not enable
> > incoming email, so all mails are generated by the various services
> > that come with Linux. Some of these services are operated
> > intentionally by me, like log
> I think the PostgreSQL recommendation seems reasonable, but the doc leaves
> me with some questions/ambiguities.
>
> Mainly, that I'm having trouble parsing the documentation's explanation of
> dkim_sign_headers entries [0]. I can see 4 cases:
>
> * no prefix: sign the first instance of the na
> I have an Exim installation where I just setup aliases.
[...]
> In other words, if I send a message to miham...@myfoobar.com, it gets
> forwarded to rakotomandi...@gmail.com.
> When I test, the sender is miham...@atscom.io and the receiver is
> miham...@myfoobar.com.
> The message is effectivel
> The man page wasn't helpful for this.
>
> I'm going to be replacing our mail nodes over the next few weeks and
> I've been sequencing events in the move. It would be very handy if it were
> possible to tell one of my nodes to keep accepting mail but to stop trying
> to deliver it. Can t
> On 16/05/2024 22:32, Ian Z via Exim-users wrote:
> > But my question is about verification, and in
> > particular about the situation where a RCPT stage ACL will have verify
> > = recipient. The filter can't be evaluated at that stage.
>
> Verification consists of running the routing process; the
> > The corollary and implication of this is that if you have routers
> > that will only work properly once the message is fully received
> > (because they require headers or ACL variables only set then), you
> > need to mark them as no_verify, and possibly write verify_only
> > versions that do ad
> My goal is getting informations, which of the presented certs during
> the TLS handshake exim takes into account for verifing the DANE RR.
> Furthermore if exim compares hostname against CN or one of the
> additional SANs embedded in the cert.
You may want to try using an external tool (not Exim
> On 14/08/2024 15:27, Kurt Jaeger via Exim-users wrote:
> > So: user1@domain1 has an autoreply, and the autoreply
> > should be signed with dkim for domain1.
>
> I do not agree.
> The DKIM RFC says that anyone can sign a message.
As a practical matter, we[*] have observed GMail rejecting email
me
> On 2024-08-14 Chris Siebenmann via Exim-users
> wrote:
> > > On 14/08/2024 15:27, Kurt Jaeger via Exim-users wrote:
> > > > So: user1@domain1 has an autoreply, and the autoreply
> > > > should be signed with dkim for domain1.
>
> > > I do not
> > As a practical matter, we[*] have observed GMail rejecting email
> > messages with claims that they are doing so because the DKIM signature
> > domain didn't match the From: domain. After observing this, we switched
> > to signing messages with a domain that matched the From: (and generally
> >
> I am not 100% sure what the best/correct dependencies for Debian's
> systemd unit (Type=exec) are.
>
> For reference exim git has:
> Requires=network.target
> After=networking.target
As a general note, 'Requires=' is potentially dangerous, because it
means 'if the other unit is shut down, so wil
> On Thu, Apr 10, 2025 at 09:06:34PM +0100, Jeremy Harris via Exim-users wrote:
> > On 2025/04/10 8:19 PM, Johnnie W Adams via Exim-users wrote:
> > > 14:16:37 121712 re-binding with user= password=foo
> > >
> > > 14:16:37 121712 Bind succeeded: ldapauth returns OK
> >
> > OK, I see two possibl
> > In that case, PQ
> > keyshares aren't sent and STARTTLS works with "boeing.com" (still
> > hangs with default TLS 1.3 connections under OpenSSL 3.5).
>
> anyone using tls 1.2 only servers in 2025 ( 7y after 1.3 introduction )
> deserves to not get mails anymore.
It appears that roughly 20% of
15 matches
Mail list logo
