2

I'm using Debian stretch (9.4).

I have an office365 account.

Using Evolution, I can successfully download mail via POP3, and also send mail using the Evolution "Sending E-mail" preferences:

Server: smtp.office365.com
Port: 587
Server requires authentication TICKED
Encryption method: STARTTLS after connecting
Authentication: Login
Username: <myid@mydomain>

and Evolution prompted me for my office365 password the first time I used it, and it's been fine since.

So that's great. However:

I also have some crontab scripts which occasionally send email programmatically via sendmail -t as described here. The exim4-config package was configured for "mail sent by smarthost; no local mail" and the outgoing smarthost to smtp.office365.com::587. I also have /etc/exim4/passwd.client containing a smtp.office365.com:<myid@mydomain>:<mypassword> line.

Until around a month ago (I think they stopped working sometime in the first week of June), those scripts were sending email via smtp.office365.com absolutely fine. However, since then, for each email attempted to be sent /var/log/exim4/mainlog now shows a bunch of error messages along the lines of:

2018-06-12 22:04:37 XXXXXX-XXXXXX-XX <= <> R=XXXXXX-XXXXXX-XX U=Debian-exim P=local S=2270
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX H=outlook.ms-acdc.office.com [40.100.174.194] TLS error on connection (recv): The TLS connection was non-properly terminated.
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX H=outlook.ms-acdc.office.com [40.100.174.194] TLS error on connection (send): The specified session has been invalidated for some reason.
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX ** <myid@mydomain> R=hub_user_smarthost T=remote_smtp_smarthost H=outlook.ms-acdc.office.com [40.100.174.194] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no DN="C=US,ST=Washington,L=Redmond,O=Microsoft Corporation,CN=outlook.com": SMTP error from remote mail server after pipelined MAIL FROM:<> SIZE=3347: 530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM [LO2P265CA0067.GBRP265.PROD.OUTLOOK.COM]
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX Frozen (delivery error message)

It's not clear to me whether something has changed at microsoft's end or my end (my machine is vanilla Debian stable amd64; I can't remember if there were any relevant security updates might have been applied around the time things stopped working). I suspect Microsoft might have tightened up authentication in some way, and I need to change something in the exim4 configuration to deal with it (I'll reiterate that Evolution has been sending mail through the same smtp.office365.com:587 channel without issue the whole time). I'm puzzled and grateful for any suggestions how to get the sendmail -t method working again.

Improve this question
4
  • If you are paying them and it stopped worked seemingly at random, why not opening a ticket with Microsoft?
    – Rui F Ribeiro
    Jun 12, 2018 at 22:31
  • MAIL FROM:<> SIZE=3347: 530 5.7.57 SMTP; Client was not authenticated to send anonymous mail: that's the problem. You're sending mail as the empty user, and apparently Microsoft doesn't like that (anymore), which is stupid as it also means you'll never receive bounce messages. Either configure a dummy address (e.g. your own email address) to be used or complain to Microsoft, as Rui already suggested. Unfortunately I can't help right now with the exim config, as it's not really something that should be done. PS: are you sending to the MX for your domain?
    – wurtel
    Jun 13, 2018 at 15:20
  • @wurtel: I do have "From: <myid@mydomain>" in the message piped to sendmail -t. Ah, but maybe that alone is not enough to trigger use of the authentication for <myid@mydomain> in /etc/exim4/passwd.client ? I will investigate along these lines further. (I send these script-generated emails to both myid@mydomain but also duplicate them to things like a gmail account and some other POP3 boxes on domains I hold. It makes no difference).
    – timday
    Jun 13, 2018 at 18:16
  • 1
    A From: header is basically independent of the SMTP envelope sender.
    – wurtel
    Jun 15, 2018 at 12:33

1 Answer 1

Reset to default
3

I have restored my system's sendmail -t functionality:

Studying the section for /etc/exim4/passwd.client in man exim4_passwd_client led me to realize that just because my outgoing mail is sent via smtp.office365.com, listing that DNS name in passwd.client may not actually be sufficient... there's some reverse DNS lookup involved in the process. Doing ping smtp.office365.com actually gets responses from something called outlook.ms-acdc.office.com. So I updated my /etc/exim4/passwd.client file to contain a line

*.office.com:<myid@mydomain>:<mypassword>

and now everything is working again. (I note previously I did actually also have a line *.office365.com in the passwd.client file; my guess is that in early June something changed in MS' setup affecting whether exim4 thought it was connecting to an SMTP server under the office365.com or office.com domains).

Of course the question now is how long it'll be until Microsoft decide on yet another rebrand of the service formerly known as Hotmail and all the DNS names change again :^)

Update 2021-06-10: Over the last week, my sendmail using scripts seem to have become unreliable (not a complete failure; sometimes something gets through anyway). ping smtp.office365.com now gets responses from lhr-mvp.trafficmanager.net; adding a *.trafficmanager.net:<myid@mydomain>:<mypassword> line to the /etc/exim4/passwd.client file seems to have fixed the issue, I think. Apparently trafficmanager.net is part of Azure infrastructure; I guess Microsoft are migrating to that. Script-sent emails which worked may have been sent at times when the new configuration was rolled back for some reason.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .