Utilisation SMTP du registar?

Mon serveur YunoHost

Matériel: Vieil ordinateur
Version de YunoHost: 3.8.4.4
J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran | …
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

Afin de pouvoir envoyer des courriels sur les adresses emails des GAFAM lorsqu’ils leurs prends le désirent de considérer notre serveur SMTP comme inacceptable (malgré de bonne note et réputation selon les sites de tests, passons), nous utilisons parfois le SMTP de notre registar, Gandi.
Lorsque nous retrouvons les bonnes grâce des GAFAM, nous recommençons à envoyer depuis notre propre SMTP. C’est contraignant, on jongle, on s’en sort pas trop mal.

Mais il y a un cas qui pose problème.
Si l’un de nous essaye de nous envoyer un email (à nous, pas à une email GAFAM), via le SMTP de Gandi, alors, notre serveur entrant (IMAP c’est ça?) semble ne pas accepter cet email.
Cela me semble assez logique, j’imagine que l’entrant doit être prévu pour n’accepter des emails avec notre nom de domaine provenant uniquement de notre serveur sortant (et pas celui de Gandi).

L’erreur retourné est la suivante :

xxx@domain.ltd: host domain.ltd[NOTRE IPV4] said 553.5.7.1 yyy@domainl.ltd: Sender address rejected: not logged in (in reply to RCPT TO command)

Est-ce que mon intuition/compréhension de l’erreur/du problème est bonne?
Est-il possible d’autoriser notre serveur entrant à recevoir des emails avec notre @domain.ltd provenant du SMTP de Gandi?

Merci pour votre aide,
Thatoo

Pas sur de piger exactement le setup, mais naivement d’après le message d’erreur, je dirais qu’il faut que l’utilisateur (ou l’entité “expéditrice” - sender) soit authentifié (login/mot de passe) pour pouvoir soumettre un message à l’envoi. Sans ça, n’importe qui pourrait envoyer un mail par le biais de ton serveur.

Donc est-ce que dans ton cas, l’entité expéditrice est correctement authentifiée avant d’envoyer le message ?

If I understand this correctly, the problem may be that your external smarthost tries to deliver a message to your yunohost with plain (non-authenticated) smtp, as it would to any other destination. But yunohost is configured to reject all messages with From:<*@your own domain> that are coming in without a successful account log-in.

I guess you are missing a smarthost setting in yunohost, which would have to whitelist the server and adjust the SPF info.

1 Like

@tmb : yup, the corresponding setting is probably :

(c.f. the permit_mynetworks setting later)

Ah, good. I have not tried, but it could even be that a yunohost smarthost option might only have to add your Gandi SMTP server’s IP to relayhost =. (Asuming that the configured smarthost would internally be also added to mynetworks =)

Then your email clients may all be set up to send and receive with yunohost, while still sending out using the providers SMTP.

Err, configuring only a relayhost and letting all clients send through yunohost’s smtp server should actually avoid above error altogether, as the local messages would then never leave yunohost anymore.

And the SPF record might also not have to be adjusted in the case that one actually uses a domain that is configured by an email provider. The SPF can then remain as configured by the email domain provider (allowing only the providers smtp host as origin).

Experimental setup example (with account and password readable in plain-text in the main config):

Actually, Debian’s debconf system already seems to have an explicit option to configure a smarthost configuration. (Third option, in the second screenshot in that article.)

Seems like a good option for a self hosted server, that could allow emails to continue working, to get help for example even when the server is down, by having a fall-back configuration in the clients that uses the provider’s imap and smtp servers directly.

@Aleks : Setup was as follow :

  • Clean yunohost with DNS zone written as provided by Yunohost.
  • All users send email through SMTP of Yunohost from their @ourdomain.ltd email addresses.
  • It works to everywhere but, time to time some GAFAM (like hotmail or gmail) as you know (they decide to block us for some time for reason we don’t understand).
  • I then offered them to send their email through gandi’s SMTP instead of our Yunohost SMTP server (till GAFAM allow our sever back, maybe in few weeks/month)

The problem is :

  • Their emails reach their friends again even on hotmail and gmail but not us. If one of us try to send an email to one of us, one get this error email back. So one need to switch back his SMTP choice to our SMTP server to be able to send us an email.

I wonder if I should not tell our IMAP server to accept email we send through Gandi’s SMTP server. If yes, how?

If I’m asking is because I’m tired of begging every 6 month or so for GAFAM to accept our SMTP server again… It was working, then they blocked, I begged, it worked again, they blocked, I begged a second time, it worked and for the third time, gmail blocked us again without, obviously, warning neither explaining why (not this time, not ever)… I feel small and weak at the idea of begging again. That’s why I decided to explain the Gandi’s SMTP solution to my family members explaining them that they needed to trust Gandi instead of me when they send email.
I didn’t think they could not write to me then because they send through Gandi’s SMTP server.

Ans so I’m not hear to ask for help to find a solution.

Hi, could you please mention how you configured that (assuming an outgoing smtprelay configuration here)?

One solution then would be listing the external email provider’s smtp server(s) in mynetworks, as already posted by @Aleks.

Another solution yunohost hints about, that would even work without using an external smtp server, would be to let yunohost send from a static IP by using a VPN, but I don’t know how to configure that.

By the way, I find calling the configuration “smarthost” (as in the linked docs) does not make it understandable. Simply saying “to configure an external smtp relay” is much better. (And apparently such a yunohost configuration option would always have to cover both directions, incoming and outgoing.)

Thought about that, why are you getting back your emails from the relay host then? These should get delivered locally, right away.

My nextcloud has a static IP behind a VPN.

I didn’t configured anything, I only told my relatives to change their smtp setting in their email client (Thunderbird…). That’s all.
smtp serveur : mail.gandi.net
id : email registered in Gandi
pass : registered in Gandi

Should I write

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mail.gandi.net

?

Indeed, that was/os working fine.
The problem is only happening when one send an email through Gandi’s SMTP server instead of our Yunohost SMTP server.

I’m afraid I don’t explain well and I’m not sure to understand your answers…

Ok, no problem. Yeah, I think you could try to simply add the gandi server as you wrote. The other way would be to configure yunohost to pass on all outgoing emails to gandi, as in the linked article above (starting with installing pluggable authentication modules), and letting the email clients connect to your own server again, to send out emails.

I have tested to change the config

relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mail.gandi.net
mailbox_command = procmail -a "$EXTENSION"

The good news, I don’t receive back error messages.
The two bad news :

  • sent messages have never reached their destination…
  • our server became very slow and no app were responding so I checked on Glances and I found this warning. (it has been gone now…)
    CRITICAL on CPU_IOWAIT (Min:51.2 Mean:57.6 Max:69.5): scsi_tmf_7, imap, lua5.1

Any idea?

Well, I was wrong, I received error messages…

The mail system [<recipient@domain.ltd>](mailto:recipient@domain.ltd): host domain.ltd[IPv4 of our server] said: 553 5.7.1 [<sender@domain.ltd>](mailto:sender@domain.ltd): Sender address rejected: not logged in (in reply to RCPT TO command)

Reporting-MTA: dns; relay1-d.mail.gandi.net X-Postfix-Queue-ID: 933EE24000E X-Postfix-Sender: rfc822; [sender@domain.ltd](mailto:sender@domain.ltd) Arrival-Date: Fri, 29 May 2020 19:08:22 +0000 (UTC) Final-Recipient: rfc822; [recipient@domain.ltd](mailto:recipient@domain.ltd) Original-Recipient: [rfc822;recipient@domain.ltd](mailto:rfc822;recipient@domain.ltd) Action: failed Status: 5.7.1 Remote-MTA: dns; domain.ltd Diagnostic-Code: smtp; 553 5.7.1 [<sender@domain.ltd>](mailto:sender@domain.ltd): Sender address rejected: not logged in

Sending through our own Yunohost SMTP works fine but the problem remain when sending through Gandi’s SMTP…
I might ask a stupid question but would there not be something to modify in the MX DNS? Now it is as it was originally given at install.

What should I do with that? It is for now :

# Requirements for the connecting server
smtpd_client_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client zen.spamhaus.org,
    permit

Nothing, it was just to point out the line “permit_mynetworks” which suggests that stuff listed in “mynetwork” is allowed and bypasses the other restrictions.

But I’m not even sure that’s the right way to proceed because I didn’t read the entire discussion to know wether or not the goal is a classical relay or a more tweaked/specific setup

I don’t think there is any very specific setup…

One user of our Yunohost email server wants to send emails.

Sending with our Yunohost SMTP server it works (except GAFAM recipient time to time).

Sending with Gandi’s SMTP sever to an email address that doesn’t belong to our Yunohost server (including GAFAM), it works.

Howrever, Sending with Gandi’s SMTP server to an other user of our Yunohost email server, it fails. We receive the error email I wrote. That is what I would like to solve.

writing

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mail.gandi.net

didn’t seem to help.