For several weeks now I am unable to send emails to my contact using an email from laposte.net .
I have an error and emails are undelivered.
It was working fine previously.
It has to be noted that it is not only for me, my wife using its own e.email address also has the same issue.
See error message below (of course I changed email addresses for confidentiality):
This is the mail system at host mail2.ecloud.global.
I’m sorry to have to inform you that your message could not be delivered to one or more recipients. It’s attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can delete your own text from the attached returned message.
The mail system
<abc@laposte.net>: host smtpz4.laposte.net[160.92.124.66] said: 550 5.7.1 Service refuse. Veuillez essayer plus tard. service refused, please try later. LPN007_510 (in reply to end of DATA command)
<xyz@laposte.net>: host smtpz4.laposte.net[160.92.124.66] said: 550 5.7.1 Service refuse. Veuillez essayer plus tard. service refused, please try later. LPN007_510 (in reply to end of DATA command)
Thanks in advance for fixing this issue which is blocking for us.
Just performed some quick check : mail.ecloud.global isn’t listed in well-known black/block-lists.
You may try to contact to contact laposte.net admins to get more details : Résultats de recherche laposte.net
I checked in the history of my emails, I have both emails with http and https (only) that were refused.
What is kind of stupid is that in latest ones I didn’t add any link in my reply, the only links come from the email from laposte.net I am replying to.
I encounter this issue from mid-october, and I had some emails that were transmitted until mid-december.
Following your message I sent an email without any link today, and it looks like it went through.
But it’s kind of a big limitation in emails… The main thing about emails is to exchange links, I hope something can be done to lift this restriction…
Except this case, the main issue I encounter with abc@e.email is that a lot of forms are refusing this email as they don’t recognize it has a valid email. So I have to use another one for these services.
Otherwise I use my e.email as my main email (except for these annoying issues with some services…).
If something has to be done, it’s by laposte.net which is applying the filtering here.
It’s unlikely they do something, but it can worth an issue at their support …
As a side note, I disagree with you : email are primarily intended to send text messages, URL links are only a “bonus” sub-part of it.
Anyway, IMHO no email provider should apply message filtering based on content, it’s a user choice & responsibility … (although not displaying links contents by default in email reader is a good idea).
@smu44 while I agree that email links are the new office macros … I checked my own Sent folder for stats: http links are contained in every 2nd outgoing message. This might by like in the ops case html mail links contained from the original sender (message footer, images etc) or really links added by myself in plaintext mail.
laposte.net really should turn this off if it is not user controllable, nor should it be a default…
@Fly is it your own laposte.net email address? if not, can you ask the recipient if some special option (antivirus/antiphishing) is active? I’m in disbelief that any major mail operator would set this as a default
related from another perspective: I just saw Reduce number of links in signup e-mail (#4543) · Issues · e / Backlog · GitLab because of free.fr / laposte users - but it speaks of avoiding to be classified as spam, not being outright rejected at the smtp level. Maybe the description is not accurate and they do get blocked via smtp - anyway, still seems to be a problem the provider needs to solve, not the senders.
I’m afraid I’m experiencing problems with mail to orange.fr (nothing was getting through so I couldn’t use an orange address to create an account here) and free.fr.(already had one warning of a message delayed [host mx1.free.fr[212.27.48.7] said: 451 too many errors detected from your IP (135.181.139.185)]
I know life is hard for new actors and the lesser players in the e-mail jungle and problems take time to solve.
As users of e.foundation services I guess we are all partly responsible for e.email’s reputation and of course we depend on it ourselves for the deliverability of our mail.
@tcecyk Yes, e-mail sources (IPs) that get a bad reputation (many mails getting classified as spam, irregular traffic with sudden bursts, …) are likely to get blocked outright by specific mail service providers like MS (I regularly see such reports in forums). Such blockages can last months, really bad.
You can check the error message, if it’s indeed coming from orange you can contact them so they update their filters.
I did it for laposte and it worked, they replied to say they updated the filters, and now it’s working again. They were really reactive, that was a good surprise.
The real trick is to find where to ask! Thanks again smu44 for the link for laposte!
I just checked with @orange.fr, a test message came through OK, so maybe that’s sorted (though I have to say @orange.fr are not brilliant in general terms … always lots of problems, delays, spam, see below).
However my message to an address @free.fr mentioned in my previous post finally got rejected (by the mx at smtp level) after 5 days with status 4.0.0 and the same diagnostic as in my post above.
I’ve just sent a new test @free.fr which got through [Edit: after 5 minutes or so, had me wondering ]. So now I’m unsure of the quality and dependability of these routes. Maybe they just need to be “worn in”. I have to admit my mail that got rejected had three links in a payload of 7kB, I’ll have to be careful at first!
On the plus side, e.email sending is high quality, SMTP server reception using TLS 1.3, ARC seal for sender’s storage, and DKIM implemented by the MX.
On reception, implementation of SPF.
This seems to me as good as big G and far better than Orange who implement neither DKIM nor SPF. Full marks to e.email.
With Laposte the issue was when an email was containing a URL (even if from a previous email coming from Laposte…). So a simple test can work but it’s not sure that it will work for all email.
@piero : it’s not related, the issue with laposte was several month ago (with emails sent from e.email, not using POP & IMAP from laposte) now we are discussing about a similar issue with orange.
… I checked my own Sent folder for stats: http links are contained in every 2nd outgoing message. This might by like in the ops case html mail links contained from the original sender (message footer, images etc) or really links added by myself in plaintext mail.
]. So now I’m unsure of the quality and dependability of these routes. Maybe they just need to be “worn in”. I have to admit my mail that got rejected had three links in a payload of 7kB, I’ll have to be careful at first!