Mail delivery failed: returning message to sender // Sender address rejected: not logged in

A redirected email has been regularly rejected by ecloud. The user [user.name] is obfuscated in the message.

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

user.name@e.email
(generated from redirect@somedomain.com)
SMTP error from remote mail server after RCPT TO:user.name@e.email:
host mail.ecloud.global [135.181.85.105]: 553 5.7.1 user.name@e.email:
Sender address rejected: not logged in

What can a user do about it?

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

It seems to be a result of a restrictive settings reject_sender_login_mismatch or similar on the ecloud mail server

Other fori with similar issues:
https://forum.iredmail.org/topic163-iredmail-support-sender-address-rejected-not-logged-in.html
https://github.com/mailcow/mailcow-dockerized/issues/342#issuecomment-307086103

1 Like

This (the message in the first post) is the typical and normal reaction a mail server sends back to the sender when the given mail address does not exist. (If you get this message it is also an argument that receiving works.)

I guess it’s just a spelling error.

Login problems are not the case here, the sending has already been tried by the server, so the login on the server must have been successful.

If your mail app says that sending and receiving mail servers are correct try sending an email from your mail app to another address to check if the sending mail server can really send.

Dear irrlicht, thank you for the explanation and suggestions. I’m not fully understanding the suggestion, though.

Yes, please, I understand that the redirect@somedomain.com works well.

I do not have an option to see the settings of the redirect@somedomain.com or the server. The admins checked the spelling of the email address and they are sure that the text [mail address] is OK. The redirect@ contains another recipient and they receive the redirected address with no issues.

As I confirmed, redirecting at somedomain[.]com and receiving at ecloud works well, when sending a messages from a different than user.name@e.email address. So, I guess this answer positively the suggested test:

My mail app is Thunderbird. May it be the culprit of the behavior?

My mail app is Thunderbird. May it be the culprit of the behavior?

Good to know!

But this should not matter. Even Thunderbird should be able to send on and receive from the e.email server. I configured Claws Mail for that and it works great.

I see the following reasons

  • probably you just misspelled the receiver’s address or

  • the receiver did close his mail account, this means the mail address does really not exist anymore or

  • the receiver’s mail server is currently down, so the mail address does temporarly not exist.

In any case the sending mail server tried to but could not send the message to the address you gave him. This is what the response from the server says.

I think we are on a wrong track: I tried to send the message from my existing account [user.name], from within the RainLoop app on the ecloud server and I received the same undelivery report.

I confirm the following:

  • The receiver’s address [user.name@e.email] in redirect@ has been checked by admins
  • The user.name@e.email addresses in the undelivery report have been compared by me side by side for encoding and characters, they match 1:1
  • the sending and the receiving account is the same, they are owned by me [user.name] and they exist and work in other aspects just well
1 Like

I’m a little unsure about this redirect thingy, but isn’t the error message pretty obvious?

There is an attempt to send an email from user.name@e.email to user.name@e.email.
In this special situation the SMTP server assumes the sender address needs to be authenticated. Which it isn’t because of the redirection.

Would be interesting to know if that also happens when sending from other.user.name@e.email to user.name@e.email
As far as I understood, it works when sending from somebody@example.com to user.name@e.email

I’d agree with yopixis second post that it’s likely something only the SMTP admins can fix.

The address a message is sent to (the receiver’s address) is not related to the username used for login on a SMTP server. The server will not check this ever. The sender’s address may be related, most servers check this to avoid abuse.

Of course it is possible in any case to send a message to the own email account without any administrator must configure or allow that. The own email address is just as every other email address when used as receiver. I do this all the time.

But as I said, the server reported that it could not send to the given address. The server didn’t say anything about login or authentication problems.

Update: I checked this with my own account - the e.email server works like every other server.

Of course the error message contains a problem with authentication:

I think you’re not understanding yopixi’s setup.

P.S.: I’m not saying I fully understand what’s going on; what I understood is: mails sent to redirect@somedomain.com get redirected to user.name@e.email. Which works when somebody@example.com write to redirect@somedomain.com but not if user.name@e.email sends to redirect@somedomain.com. The SMTP server of somedomain.com gets an error from the SMTP server of e.mail saying “Sender address rejected: not logged in”.

1 Like

Bingo!

The following address(es) failed: user.name@e.email
(generated from redirect@somedomain.com)
SMTP error from remote mail server after RCPT TO:user.name@e.email:
host mail.ecloud.global [135.181.85.105]: 553 5.7.1 other.user.name@e.email: Sender address rejected: not logged in

So, yes, please: other.user.name@e.email > redirect@somedomain.com > user.name@e.email fails, too.

And this is a relevant part of the header:

----- This is a copy of the message, including all the headers. ------
Return-path: other.user.name@e.email
Received: from mail.ecloud.global ([135.181.85.105]) by somedomain.com with esmtp (Exim 4.69) (envelope-from other.user.name@e.email) id 1kQ7rt-0004st-OO for redirect@somedomain.com; Wed, 07 Oct 2020 13:44:30 +0200
Received: from authenticated-user (mail.ecloud.global [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.ecloud.global (Postfix) with ESMTPSA id 912FC10001E8503B for redirect@somedomain.com;

Not entirely correct. The attempt is to use a redirect / forward / group alias at another mail server.

Sending a direct email from user.name@e.email to user.name@e.email works just fine. Tried now, and was working well also in the past.

Sending a direct email from user.name@e.ecloud to user.name@e.ecloud works just fine. Tried now, and was working well also in the past.

OK, now we know that. But what’s now the problem? The other mail server does not forward correctly?

Forwarded/redirected messages fails to be delivered:
other.user.name@e.email > redirect@somedomain.com > user.name@e.email fails

It is a certain problem with this specific somedomain.com redirect. I have found another redirect, which I can setup on a user level and that works well.
EDIT: This does not solve my problem, though. I’m required to use the redirect@somedomain.com