When a user sets an autoreply in Pegasus, and an email comes in from a Gmail address (@gmail.com), the autoreply always fails with:

550-5.7.26 This mail has been blocked because the sender is unauthenticated.

This has puzzled me for a while, since it appears Google is expecting Mercury to authenticate to send mail. But, sending messages to gmail users works fine, just not the autoreplies.

Today I found the reason for the failures. When Mercury sends the autoreply, the envelope sender ( MAIL FROM: ) is empty, actually <>. Google rejects the email because of the empty envelope since it can't apply DMARC rules to the empty envelope sender.

I can't find any way to set an address to use for that. Does anybody know of a way to set an address for Mercury's autoreply messages?

Regards,
Tony

I know that in Pegasus Mail, <> will replace where the email address should be if the "My Internet e-mail address is" field is blank in Tools > Internet Options. I can't recall whether It has been a few years since I have worked with Mercury so I don't recall whether I populated that field when setting up Pegasus Mail with Mercury but your reference to "<>" made this pop into my head.

I've looked through all the settings screens in Mercury. I haven't seen anything like that in Mercury.

Sadly, all of the other mail servers accept the autoreply messages without a problem. I believe that Google is handling the autoreplies incorrectly, but I doubt they would fix it, even if they know/knew it was wrong.

Regards,
Tony

The setting I mentioned is in Pegasus Mail. You mentioned that the autoreplies were being set in Pegasus Mail which is what made me think of it. Although, now the I think that through a little further, if the setting I referred to was indeed the problem, I suspect it would be affecting all outgoing messages, not just autoreplies. I'll go crawl back under my rock now.

I did a test from a Gmail account and autoreply was returned without any problems. SMTP Mail from was postmaster@ [domainname], and Google confirms spf=pass. Autoreply was set in Mercury though, Pegasus was not used.

Thanks for that. Not sure what type of autoreply users can set up in Mercury. I'm talking about the Pegasus out of office autoreply that users set themselves. For that, Mercury sends the autoreply with the mail from address empty, which is actually legal, but not acceptable to gmail.

Regards,
Tony

@Rolf Lindby

where did you set Autoreply in Mercury ? I am not able to find any settings. I get only Auto-forward in the user managment and according to Mercury Help there is an option of Autoresponders.

I did a test from a google account as well and got the same "not authorized...." response which Tony got. I had set the Autoreply with your little tool, Rolf. It is creating the AREPLY.PM file in the users mailbox.

It was not send with the postmaster@[domain] address.

Looking at the email source, "Return-Path: <> " and I think that this is causing the problem.
Here is the full source of an autoreply. It was not send from a gmail account to my hosted email. This way I got the result. And here it is:

.................................................
Return-Path: <>
Received: from zm-mta1.myaccess.ca (LHLO mail.myaccess.ca) (192.168.84.30)
by zm-mailstr2.myaccess.ca with LMTP; Thu, 25 Jan 2024 20:55:24 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
by mail.myaccess.ca (Postfix) with ESMTP id 4CBA33E1312
for xxxx@myaccess.ca; Thu, 25 Jan 2024 20:55:24 -0600 (CST)
X-Virus-Scanned: amavis at zm-mta1.myaccess.ca
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 required=4 tests=[BAYES_05=-0.5,
SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.myaccess.ca ([127.0.0.1])
by localhost (zm-mta1.myaccess.ca [127.0.0.1]) (amavis, port 10024)
with ESMTP id lB7OwggiWLV7 for xxxx@myaccess.ca;
Thu, 25 Jan 2024 20:55:23 -0600 (CST)
Received: from mail.yorktondigital.ca (mail.yorktondigital.ca [74.206.133.146])
by mail.myaccess.ca (Postfix) with ESMTPS id 88B523E11F3
for xxxx@myaccess.ca; Thu, 25 Jan 2024 20:55:23 -0600 (CST)
Received: from Spooler by mail.yorktondigital.ca (Mercury/32 v4.91.226) ID MO000152;
25 Jan 2024 20:55:23 -0600
Received: from spooler by mail.yorktondigital.ca (Mercury/32 v4.91.349); 25 Jan 2024 20:55:13 -0600
X-CLAMWALL: Passed through antiviral test by ClamWall 1.5.0.98 on mail.yorktondigital.ca (27)
X-Autoreply-From: myaccount@yorktondigital.ca
Precedence: Bulk
To: xxxx@myaccess.ca
From: myaccount@yorktondigital.ca
Date: Thu, 25 Jan 2024 20:55:02 -0600
MIME-Version: 1.0
Content-Type: Text/Plain
Subject: [Autoreply] Re: my autoreply
Message-ID: 7BCD50E4.65B31F11.0003@mail.yorktondigital.ca

this is my autoreply
............................................

There is still a From and X-Autoreply-From with the email address hosted by Mercury, but I think that the empty Return-Path is creating the problem with gmails DMARC policy. And I think and empty Return-Path is not good practice anyways. Setting here the postmaster@[domain] would be good practice.

Or did I miss a setting in Mercury ?

Johannes

I contacted David Harris about this. Here is his reply:

GMail, as it frequently is, is in error.

"<>" is the standards-defined notation for an address for notifications to
which no reply should be generated - see RFC5321 sections 3.6.3 and 6.1.
Gmail should definitely not be failing it.

Of course, saying that is kind of pointless - Google is a law unto itself and
can do whatever it wants, while the world follows sheep-like because there's
no alternative.

I have already handled a version of this problem where Gmail handled
automatically-forwarded messages incorrectly: I'll have a look and see if that
code can be applied to automatic replies as well.

Cheers!

-- David --

Regards,
Tony

Since two days our ISP (IONOS Germany, formerly 1&1) handles mail submission more strictly where sender addresses (at least its mail domain) have to be of registered users.
Since then we also experiencing problems with autoreplies because Mercury is sending only <> as sender address or envelope address. Here some extracts from Mercury logs:

mail log:
O 20240131 1018 MG002BF6 <> #####@gmx.de 532

smtp.log
T 20240131 101856 1528 Established ESMTP connection to smtp.ionos.de
T 20240131 101857 1528 Begin processing job MO002BF7 from <>
T 20240131 101857 1528 MAIL FROM:<> SIZE=670
E 20240131 101857 1528 550-Requested action not taken: mailbox unavailable

Since decades we have Pmail/Mercury synonym.mer database in place which is translating local user names in internet email addresses, like e.g.: j.doe@domain.com == jd.
And when I remember correctly, all autoreplies have always been mistakenly sent by Mercury from jd@domain.com, what was wrong (because of using the short local user name instead the full user name) but accepted and welcome, since autoreplies have sometimes also been returned to spammers and so they didn't get the right address.
But now it seems Mercury is sending <> only.

Joerg,

here is an idea as a workaround, if that will work with your situation.

Look at Rolf's post were he says that his mail is sent from postmaster@[domain] and I am assuming that he is using autoforward. I did not see anything from him after my post.
If my assumption is correct and if you could use auto-forward, test it and see if my assumption is correct or not.

If it is indeed using postmaster@[domain], maybe it can be a temporary workaround ?

I am also still waiting for David to get the name.lastname@[domain] username convention fixed. It is nearly a year now that I mentioned this to Support and it is broken since 4.7, as they confirmed. This just as a side note.

Johannes

Thanks Johannes
First, as Tony already said, I do not know any additional autoreply feature directly from Mercury where the postmaster is being set as sender address. Should I set Mercury filters each time a user wants to activate its autoreply? I got about 20 users here. Normally the autoreply is adjusted by Pmail with the sender problems described. Maybe Rolf could advise.

Further I have different problems with the suggested autoforward function. For this feature I have to set one or more adressees into the autoforward file to specify where the mail should be forwarded to. How should it work with unknown sender addresses where the mail should be returned to?

And the other problem is our new ISP security policy where mail bouncer are not longer allowed (https://community.pmail.com/index.php?u=/topic/12005/mercury-mail-forwarding-smtp-restrictions-by-internet-provider-ionos). Any Mercury forwardings will be handled as mail bouncer where the original sender remains in the mail envelope and our ISP refuse it. BTW, also any other adjusted global Mercury rules, where specific sender addresses will be searched for forwarding their mails to other internet addresses, don't work any longer because of mail bouncing.

I would need a way where Mercury is replacing the original sender address within all forwardings or replies with the local user address the mail is addressed to (or at least with postmaster@domain).

I checked Gmail handling of autoreplies a bit closer. MAIL FROM from Mercury is indeed <>, but Google takes the domain used in the preceding HELO/EHLO and verifies the server using the SPF record for that domain:

spf=pass (google.com: domain of postmaster@sendingdomain.com designates 111.111.11.11 as permitted sender) smtp.helo=sendingdomain.com

So apparently, as long as the SPF record clearly authorizes the IP address of the Mercury server to send messages on behalf of the domain autoreplies are allowed by Gmail.

@Joerg As for your ISP problem a small daemon could replace <> in MAIL FROM with for instance noreply@sendingdomain.com in autoreply messages.

Hi Rolf,
Thanks for your reply. But we are not programmers. What do you mean with a "small daemon"? Mercury itself is handling all incoming POP3 retrieves > is analysing any necessary autoreplies > and hands over it to its SMTP client. Where we should get in between these Mercury tasks? It would be helpful if such an adjustable daemon would be integrated in Mercury SMTP client.

Hope, such issues will be recorded for future development of Mercury. Could you tell something about the planned new release?

Greetings from Germany

Daemons are meant to be used for cases like this, when normal behavior for some reason isn't sufficient and something needs to be modified in the message flow.

David is currently working on integrating DKIM in Mercury as that soon may be a requirement. But fortunately daemons can be created by me or someone else with some programming knowledge without David's help. So if you can't find a workaround with your ISP I can probably solve it with a daemon.

Hi Rolf,
Just enforced a Autoreply to log the entire SMTP traffic with our ISP IONOS. BTW, IONOS is a big player here in Germany.
Here we go:

09:39:59.026: --- 5 Feb 2024, 9:39:59.026 ---
09:39:59.120: Connect to 'smtp.ionos.de', timeout 180 seconds.
09:40:00.120: >> 220 kundenserver.de (mreue106) Nemesis ESMTP Service ready<cr><lf>
09:40:00.120: << EHLO ######.com<cr><lf>
09:40:00.135: >> 250-kundenserver.de Hello ######.com [###IP removed###]<cr><lf>
09:40:00.135: >> 250-8BITMIME<cr><lf>
09:40:00.135: >> 250-SIZE 140000000<cr><lf>
09:40:00.135: >> 250 STARTTLS<cr><lf>
09:40:00.135: << STARTTLS<cr><lf>
09:40:00.167: >> 220 OK<cr><lf>
09:40:00.260: [] SSL/TLS session established
09:40:00.260: [] TLS_AES_256_GCM_SHA384, TLSv1.3, Kx=any, Au=any, Enc=AESGCM(256), Mac=AEAD<lf>
09:40:00.260: [] Peer's certificate name is '/C=DE/O=IONOS SE/ST=Rheinland-Pfalz/L=Montabaur/CN=smtp.ionos.de'.
09:40:00.260: << EHLO ######.com<cr><lf>
09:40:00.307: >> 250-kundenserver.de Hello ######.com [###IP removed###]<cr><lf>
09:40:00.307: >> 250-8BITMIME<cr><lf>
09:40:00.307: >> 250-AUTH LOGIN PLAIN<cr><lf>
09:40:00.307: >> 250 SIZE 140000000<cr><lf>
09:40:00.307: << AUTH LOGIN<cr><lf>
09:40:00.338: >> 334 VXNlcm5hbWU6<cr><lf>
09:40:00.338: << c210cEBtYXJzaWcuY29t<cr><lf>
09:40:00.354: >> 334 UGFzc3dvcmQ6<cr><lf>
09:40:00.354: << MiQwRFhYVnFxalNLbTlM<cr><lf>
09:40:00.760: >> 235 Authentication succeeded<cr><lf>
09:40:00.760: << MAIL FROM:<> SIZE=669<cr><lf>
09:40:00.792: >> 550-Requested action not taken: mailbox unavailable<cr><lf>
09:40:00.792: >> 550 Sender address is not allowed.<cr><lf>
09:40:00.854: << QUIT<cr><lf>
09:40:00.870: >> 221 kundenserver.de Service closing transmission channel<cr><lf>
09:40:00.885: [] OpenSSL secure session normally terminated.
09:40:00.885: --- Connection closed at 5 Feb 2024, 9:40:00.885. ---

As you see the authentication succeeded but the sender address "<>" is not longer allowed.
I also studied the Mercury User Manual for "Daemons" and found a general description of daemons and what they are for, only. But no further details how to create, where to add and how to implement such daemons.
Maybe you could advise how to setup a simple daemon which is searching for sender "<>" within autoreplies and replacing it with a standard address like postmaster, before handing-over it to Mercury's SMTP Client again.

The other issue are mail bouncer, where some of our composed Mercury Global Filters are resending (forwarding) incoming mails with specific sender addresses directly back to the Internet to other addressees. But since the sender (or envelope) address will not being changed by Mercury, the ISP SMTP server receive them with original sender address which has no authentication for submitting mails to ISP on our behalf (means with our registered sender mail domain).
Would it be possible to create a daemon for such case, too? Means, if a forward filter triggers, replace the original sender address with the original addressee of the mail before forwarding it.

Thanks

I assume that means that you don't expect to be able solve this by contacting the ISP. I'll have a look at a daemon solution.

As for your earlier question about future development of Mercury please see David's new post here:
https://www.pmail.com/devnews.htm

No, no chance. The ISP has announced this more strict mail submission procedure officially three months ago and sent warning messages to each customer when detecting problematic mail submissions.
In the meantime we could only discover by phone with ISP, that sender addresses of an email must not be exactly the same as the authentication address, but have to be of the same ISP registered mail domain. But in any case an ordinary mail address is expected and not "<>". Sorry for that.

As an alternative I see only the opportunity to change the SMTP server where MercuryC is delivering to. We are not able to change the entire ISP, since other services like websites, are running in this contract, too.
But only to change the submission SMTP server should not be the problem. If anybody knows an affordable SMTP server with excellent reputation at all spammer blacklists, which is accepting all mails as used to until now ...?

Hello Joerg,

let me know what you exactly need and email me.

Johannes

This small daemon will replace the normal MAIL FROM address in autoreplies with something that works better for you.

AreplyMod.zip