SMTP-gebruik Microsoft 365

[Melvin.P]

Eind vorig jaar heb ik een kennis met een kleine onderneming geholpen zijn e-mail onder te brengen in Microsoft 365. In grote lijnen werkt alles naar wens. Zijn boekhoudpakket biedt de mogelijkheid om e-mails te sturen. Het maakt daarvoor gebruik van SMTP. Dat ligt met Microsoft 365 natuurlijk een beetje complex.

De fabrikant van de boekhoudsoftware noemt twee oplossingen;

- In Microsoft 365 een Connector aanmaken. Daarin denk ik vast te lopen omdat dan een IP-reeks moet worden opgegeven waar vandaan e-mail verstuurd mag worden. Als ik het goed begrijp, is dat dan gewoon het IP-adres van de internetverbinding van meneer, waarachter de computer online is. Maar dat is geen vast IP-adres en dus geen stabiele oplossing.

- In Microsoft 365 de Legacy SMTP inschakelen en smtp-legacy.office365.com gebruiken als server met SSL en authenticatie. Dan moet ook SMTP ingeschakeld zijn als toegestane mail-app voor de gebruiker. Dat krijg ik niet aan de praat; steeds een authenticatiefout. Ik vermoed dat het samenhangt met het gebruik van MFA.

Zou iemand mij kunnen helpen? Klopt mijn interpretatie van deze twee opties? Zie ik iets over het hoofd? Zijn er andere, betere oplossingen? Heb ook al gedacht aan uitwijken naar (bijvoorbeeld) Mailjet.

[SVMartin]

In het eerste geval: weet je zeker dat smtp verkeer niet gestart wordt vanuit een server omgeving van het boekhoudpakket? En hoe dynamisch is het ip adres van de gebruiker in de praktijk?

Voor die tweede zou je MFA natuurlijk tijdelijk uit kunnen schakelen voor een test, of even een testgebruiker aanmaken. Eerst zonder en daarna met MFA. Dan weet je dat het door de MFA komt.

[Melvin.P]

Dank voor je reactie. Ik ben vrij zeker dat het SMTP-verkeer niet vanuit een server van de software gestart wordt. Het is echt een lokale applicatie.

MFA even uitschakelen zou ik inderdaad kunnen proberen. Een test-gebruiker aanmaken is minder eenvoudig omdat we over een omgeving met maar één licentie spreken.

Eigenlijk hoopte ik dat iemand zou kunnen uitsluiten wat wel en niet kan in deze situatie. En of uitwijken naar (bijvoorbeeld) Mailjet voor de hand ligt of echt te ver gezocht.

[ldiy]

Je kan misschien proberen om gebruik te maken van een app password: https://support.microsoft...63-e681-128a-a6f2979a7944

[Melvin.P]

Bedankt! Dat schoot me gisteren door het hoofd omdat ik het ken van Apple en Google, maar niet meer bij stilgestaan om het te proberen. Doen we morgenochtend. Hopelijk is het zo simpel.

[DJMaze]

Vroeger kwam ik er achter dat niemand de Office365 omgevingen correct inricht.

Stel... Piet logged in via SMTP en verstuurt als jan@bedrijfsnaam
Dit zou niet mogen, maar goed... Foutje bedankt

Nu heeft Microsoft het allemaal moeilijker gemaakt en zo dat niet jan en alleman zomaar SMTP kan gebruiken.
Probleem omzeilt, niet opgelost.

Nadeel is dat derden niet kunnen inloggen, maar dat is totaal geen probleem.

Als je SPF, DKIM en DMARC juist instelt, kan je boekhoudpakket prima zelf emailen buiten Office365 om.

Iedereen kan dan gewoon de mail ontvangen en werkt als een zonnetje.
Helaas, Microsoft heeft een "smart" filter die geen rekening houdt met SPF, DKIM, en DMARC.
Hierdoor komt mail daar niet aan of in de spam map.

Stap je over op Google Gsuite, dan zijn alle problemen verholpen.
Moet je kennis dat wel willen.

[Pharos1985]

Ik zou eens proberen te versturen via SMTP diag tookit
https://adminkit.net/smtp_diag_tool.aspx

Daar krijg je gedetailleerde foutmelding retour die 365 terugstuurde, dan kan je daarmee Googlen, zo doe ik het altijd en dan kom ik er meestal vrij snel uit.

[MartinMeijerink]

Je kan ook gewoon de smtp-server van de internetprovider gebruiken. Als het bv. om Ziggo gaat, gewoon versturen via smtp.ziggo.nl. Dan wel op de domeinnaam even een SPF- en een DMARC-record aanmaken:

bedrijfsnaam.nl TXT "v=spf1 a mx ip4:212.54.42.9 a:smtp.ziggo.nl -all"
_dmarc.bedrijfsnaam.nl TXT "v=DMARC1; p=none"

Dan testen via mail-tester.com, dit is een hele mooie mailtester die je precies vertelt wat er nog aan je mail mankeert (enige nadeel is dat je per dag maar 3 gratis testen mag doen)

[Melvin.P]

Bedankt allemaal. We zijn er vanmorgen verder mee gegaan.

In eerste instantie ontbrak de mogelijkheid om een app-wachtwoord aan te maken. De optie verscheen, nadat ik MFA voor de gebruiker opnieuw instelde. Opmerkelijk genoeg stond er ook dat MFA uitgeschakeld zou zijn, terwijl meneer toch wel degelijk een SMS-code (dat werkt voor hem het beste) moet opgeven bij een nieuwe login.

Het werkte niet direct met het nieuwe app-wachtwoord. Toen heb ik MFA uitgeschakeld en het met zijn normale wachtwoord geprobeerd. Dat werkte ook niet. Vervolgens vond ik dit artikel. Na het uitschakelen van de 'Standaardinstellingen voor beveiliging', werkte het wel. De andere optie in het artikel, de gebruiker uitsluiten van een policy die Legacy Authentication verbiedt, lijkt niet toepasbaar omdat het een ander abonnement vereist.

Vervolgens MFA weer aangezet en een app-wachtwoord aangemaakt. Het werkte niet meteen, maar even later wel. Ik ben nu geneigd de 'Standaardinstellingen voor beveiliging' weer in te schakelen, maar vermoed dat het dan weer stukgaat aangezien dat ook het gebruik van het normale wachtwoord zonder MFA dwarsboomde.

Alle adviezen neem ik graag te harte, maar ik zie door de bomen het bos niet meer zo goed. Als algemeen advies is om de 'Standaardinstellingen voor beveiliging' te handhaven, en het is een gegeven dat dat het gebruik van deze vorm van SMTP in de weg zit, vraag ik me af of het beter is om de SMTP-server van de internetprovider of bijvoorbeeld Mailjet te gebruiken.

[akimosan]

Ik denk dat het inderdaad verstandiger is om een mailoplossing die nog legacy toestaat ertussen te plaatsen dan rechtstreeks vanaf de endpoint en allerlei beveiligingen uit te schakelen.
Op die manier focus je enkel op dat stukje legacy waar je nog een workaround voor moet gebruiken maar zet je niet andere nuttige beveiligings features verder uit.

Als je later met modernere standaarden of updates die MS doorvoert weer tegenkomt dat je non-standaard instellingen je in de weg zitten moet je er ook weer meer werk voor doen.

Ja, die beveiligingen om maar niet meer allemaal onversleuteld, ongeautoriseerde typen authenticatie toe te staan maken het complexer om verouderde standaarden te gebruiken. Maar die verouderde standaarden veroorzaken veel overlast als ongewenst mailverkeer en zorgen voor misbruik van exploits en hacks die tot vervelende toestanden leiden.

We kunnen allemaal wel volhouden dat partijen als Google en Microsoft, etc het te moeilijk maken maar zij reageren uiteindelijk ook maar op de wensen en eisen van veel andere gebruikers en risico's die ze verder nog zien om de overlast voor iedereen zoveel mogelijk te beperken.

Zelfde geldt voor de MFA. Zo'n authenticator op een smartphone is de moeite ook niet meer echt. Ik snap de SMS methode wel, het zal ongetwijfeld om een "oudere" gebruiker gaan maar uiteindelijk moet ie ook met zijn tijd mee. Het is vaak gewoon een kwestie van doen en stappen een paar keer herhalen...

[Archie_T]

MartinMeijerink schreef op vrijdag 17 februari 2023 @ 10:32:
Je kan ook gewoon de smtp-server van de internetprovider gebruiken. Als het bv. om Ziggo gaat, gewoon versturen via smtp.ziggo.nl. Dan wel op de domeinnaam even een SPF- en een DMARC-record aanmaken:

bedrijfsnaam.nl TXT "v=spf1 a mx ip4:212.54.42.9 a:smtp.ziggo.nl -all"
_dmarc.bedrijfsnaam.nl TXT "v=DMARC1; p=none"

Dan testen via mail-tester.com, dit is een hele mooie mailtester die je precies vertelt wat er nog aan je mail mankeert (enige nadeel is dat je per dag maar 3 gratis testen mag doen)

Ik weet niet heel veel van SMTP maar heb je nu niet geregeld dat heel Ziggo uit jouw naam mag mailen?

[holygame]

Gebruik SMTP2GO voor legacy apps die niet met moderne e-mail protocollen om kunnen gaan.

Gebruik bij voorkeur Microsoft Graph OAuth 2.0.

[ Voor 22% gewijzigd door holygame op 17-02-2023 19:52 ]

[MartinMeijerink]

Archie_T schreef op vrijdag 17 februari 2023 @ 19:35:
[...]

Ik weet niet heel veel van SMTP maar heb je nu niet geregeld dat heel Ziggo uit jouw naam mag mailen?

Dat is idd wel een nadeel van het gebruik van een SPF-record (maar dit heb je ook als je de SMTP-server van Microsoft365 zou gebruiken). Het beste is dan ook een eigen mailserver, dan zet je alleen je eigen ipadres in het SPF-record.

[Jazzy]

MartinMeijerink schreef op vrijdag 17 februari 2023 @ 21:20:
[...]

Dat is idd wel een nadeel van het gebruik van een SPF-record (maar dit heb je ook als je de SMTP-server van Microsoft365 zou gebruiken).

Nee hoor, andere Microsoft 365 klanten kunnen niet mailen met jouw domein. Dat kan alleen als je het domein aan jouw tenant toegevoegd hebt.

Sowieso is bovenstaande een slecht advies omdat je niet eerst vraagt welke andere diensten namens het domein mogen zenden. Van geen SPF-record naar dat SPF-record zou je dus een nieuw probleem met de bezorging kunnen introduceren.

Als je dan toch een DMARC-record adviseert, voeg dan een rua= toe zodat je tenminste data gaat vergaren over servers die namens het domein verzenden. Die kennis gebruik je vervolgens om een SPF-record te vullen en uiteindelijk op hardfail te zetten.

[sniper20]

Melvin.P schreef op donderdag 16 februari 2023 @ 17:38:
Eind vorig jaar heb ik een kennis met een kleine onderneming geholpen zijn e-mail onder te brengen in Microsoft 365. In grote lijnen werkt alles naar wens. Zijn boekhoudpakket biedt de mogelijkheid om e-mails te sturen. Het maakt daarvoor gebruik van SMTP. Dat ligt met Microsoft 365 natuurlijk een beetje complex.

Zit dat boekhoudpakket in de cloud of draait het in het lokale netwerk van de klant ? Dat is wel belang.

[Oekiejoekie]

En let er op dat 365 limieten heeft voor het aantal mails wat je per dag mag verzenden. Bij een vereniging waar ik wel eens wat voor doe, verstuurden we de contributiefacturen met een boekhoudpakket wat dat direct via SMTP deed. Bij de eerste 500 mails gaat dat goed, en daarna blokkeert het mailadres.

Microsoft 365 is niet geschikt om in bulk mail te versturen. Dan moet je toch op zoek naar een externe dienst.

[i-chat]

DJMaze schreef op donderdag 16 februari 2023 @ 21:13:
Vroeger kwam ik er achter dat niemand de Office365 omgevingen correct inricht.

en dan lees ik het volgende

Als je SPF, DKIM en DMARC juist instelt, kan je boekhoudpakket prima zelf emailen buiten Office365 om.

TS geeft aan dat hij (of zijn klant) geen vast IP heeft dus waarschijnlijk gaat het niet om een zakelijke verbinding of in ieder geval niet eentje die geent is op zakelijk gebruik, dan weet je al vrij zeker, geen vast ip, dus ook geen port 25, en al helemaal zeker geen reverse-DNS kortom zelf mailen is geen houdbare optie.

bovendien raad ik iedereen ten zeerste af om ooit de ingebouwde doorgaans totaal onbeveiligde smtp-module van een stuk kantoorsoftware in te zetten voor niet-lokale (binnen het lan) toepassingen. je weet immers nooit hoe lang zo'n smtp-module al geen patches meer heeft gehad...

juist om die reden wil je dus gewoon inzetten op mail versturen via een vertrouwde server... en juist voor dit soort pakketten dat slecht onderhouden word heeft ms legacy-app-passwordt features beschikbaar. ik zou dus vooral gewoon voor data ene account / mailadres een app-paswoord maken zodat je om mfa heen kunt.

Stap je over op Google Gsuite, dan zijn alle problemen verholpen.
Moet je kennis dat wel willen.

ook met Gsuite gaan app-paswords lang niet altijd vlekkeloos, het proces werkt overigens precies hetzelfde dus overstappen is eigenlijk nergens voor nodig. Bovendien zijn de kosten voor gsuite tegenwordig ongeveer gelijk aan die van o365 + office dus ook voor de kosten kun je het wel laten.

[Killah_Priest]

i-chat schreef op dinsdag 21 februari 2023 @ 00:22:
[...]
en dan lees ik het volgende
[...]
TS geeft aan dat hij (of zijn klant) geen vast IP heeft dus waarschijnlijk gaat het niet om een zakelijke verbinding of in ieder geval niet eentje die geent is op zakelijk gebruik, dan weet je al vrij zeker, geen vast ip, dus ook geen port 25, en al helemaal zeker geen reverse-DNS kortom zelf mailen is geen houdbare optie.

bovendien raad ik iedereen ten zeerste af om ooit de ingebouwde doorgaans totaal onbeveiligde smtp-module van een stuk kantoorsoftware in te zetten voor niet-lokale (binnen het lan) toepassingen. je weet immers nooit hoe lang zo'n smtp-module al geen patches meer heeft gehad...

juist om die reden wil je dus gewoon inzetten op mail versturen via een vertrouwde server... en juist voor dit soort pakketten dat slecht onderhouden word heeft ms legacy-app-passwordt features beschikbaar. ik zou dus vooral gewoon voor data ene account / mailadres een app-paswoord maken zodat je om mfa heen kunt.


[...]
ook met Gsuite gaan app-paswords lang niet altijd vlekkeloos, het proces werkt overigens precies hetzelfde dus overstappen is eigenlijk nergens voor nodig. Bovendien zijn de kosten voor gsuite tegenwordig ongeveer gelijk aan die van o365 + office dus ook voor de kosten kun je het wel laten.

Boekhoudpakketten die anno 2023 alleen via SMTP kunnen mailen en bv geen gebruik kunnen maken van bv Exchange EWS, MS Graph of de Google APIs om te mailen zouden naar mijn idee ook zsm uitgefaseerd moeten worden.
Het kost mij als developer namelijk bijzonder weinig moeite om een module te maken waarbij het mailen voor bv Office 365 gewoon via bv de Graph API gedaan kan worden. MS en Google bieden gewoon ook alle tools en documentatie inclusief legio voorbeelden om dit te kunnen bouwen.

[i-chat]

Killah_Priest schreef op dinsdag 21 februari 2023 @ 12:19:
[...]


Boekhoudpakketten die anno 2023 alleen via SMTP kunnen mailen en bv geen gebruik kunnen maken van bv Exchange EWS, MS Graph of de Google APIs om te mailen zouden naar mijn idee ook zsm uitgefaseerd moeten worden.
Het kost mij als developer namelijk bijzonder weinig moeite om een module te maken waarbij het mailen voor bv Office 365 gewoon via bv de Graph API gedaan kan worden. MS en Google bieden gewoon ook alle tools en documentatie inclusief legio voorbeelden om dit te kunnen bouwen.

absoluut en 100% mee eens, maar er is al zoveel mis met de buissness-app development dat je dat helaas niet hoeft te verwachten.

ondanks dat we nu al 20 jaar tegen dat probleem lopen bestaat bijvoorbeeld VBA ook nog steeds.
simpel gezegd: als je als heel bedrijf met multi-user gebruik maakt van software dan hoort dat gewoon netjes in een serveromgeving te draaien (bijvoorbeeld webbased of met client-api's...) als je het individueel draait hoort het gewoon individuele data uit te spugen die je vervolgens handmatig kunt mailen of via een plugin in je mail client semi-automatisch kunt doen.

software hoort simpelweg niet zelfstandig emails te versturen, maar moet zich gewoon netjes gedragen als een losstaande client die namens een no-reply-account mail kan sturen via de reedsbestaande (en goed beveiligde mail-infra). de kans echter dat men dit soort duidelijke regels ook daadwerkelijk netjes volgt is helaas kleiner dan de kans dat het morgen gaat sneeuwen in de Sahara.

[IPrange.net]

Je kunt bij Microsoft 365 gewoon nog verzenden via SMTP Auth.

Het volledige artikel van MS is hier te vinden: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission

Dit kun je aanzetten per mailbox of voor je hele tenant. Heb je een tenant die al een tijdje actief is dan kan het zijn dat de instellingen via de Admin Center niet werken.

code:

Bijvoorbeeld aanzetten SMTP Auth voor een enkele mailbox/user:

Connect-ExchangeOnline
Get-CASMailbox -Identity [e-mail]

Indien er geen waarde of True is ingevuld onder SmtpClientAuthenticationDisabled dan is deze uitgeschakeld.

Gebruik deze om het in te schakelen:
Set-CASMailbox -Identity [e-mail] -SmtpClientAuthenticationDisabled $false

Je kunt het controleren door nogmaals dit commando uit te voeren:
Get-CASMailbox -Identity [e-mail]

Staat er bij SmtpClientAuthenticationDisabled nu False dan kun je gebruikmaken van uitgaande SMTP via:
Uitgaande e-mail: smtp.office365.com Poort: 587 (SSL/TLS)

[ZeRoC00L]

Oekiejoekie schreef op vrijdag 17 februari 2023 @ 22:28:
En let er op dat 365 limieten heeft voor het aantal mails wat je per dag mag verzenden. Bij een vereniging waar ik wel eens wat voor doe, verstuurden we de contributiefacturen met een boekhoudpakket wat dat direct via SMTP deed. Bij de eerste 500 mails gaat dat goed, en daarna blokkeert het mailadres.

Microsoft 365 is niet geschikt om in bulk mail te versturen. Dan moet je toch op zoek naar een externe dienst.

Zijn policies, dus die kun je aanpassen….zou wat zijn als je maar 500 mails mag sturen

[nelizmastr]

ZeRoC00L schreef op woensdag 22 februari 2023 @ 13:03:
[...]

Zijn policies, dus die kun je aanpassen….zou wat zijn als je maar 500 mails mag sturen

Ligt natuurlijk aan 500 in een bepaalde tijd. Als je >500 mails in minder dan een uur stuurt dan ben je een spammer en zul je moeten uitwijken naar externe diensten die wél voor grote volumes bedoeld zijn of het netjes throttlen.

[ZeRoC00L]

nelizmastr schreef op maandag 6 maart 2023 @ 08:04:
[...]


Ligt natuurlijk aan 500 in een bepaalde tijd. Als je >500 mails in minder dan een uur stuurt dan ben je een spammer en zul je moeten uitwijken naar externe diensten die wél voor grote volumes bedoeld zijn of het netjes throttlen.

Outbound limieten kun je gewoon verhogen bij MS hoor.

https://learn.microsoft.c...te-outbound-spam-policies

[nelizmastr]

ZeRoC00L schreef op maandag 6 maart 2023 @ 08:56:
[...]

Outbound limieten kun je gewoon verhogen bij MS hoor.

https://learn.microsoft.c...te-outbound-spam-policies

Bij Microsoft ja, maar dat zegt niet wat de ontvangende mailservers ervan vinden. Het gaat om het principe
dat bulk mail met het risico op blokkades komt. In de basis wil je voorkomen dat je in de buurt van de limieten komt. Als je bijv. veel nieuwsbrieven stuurt kun je daar beter niet Exchange voor gebruiken maar externe diensten als Mailchimp.

[Jazzy]

ZeRoC00L schreef op woensdag 22 februari 2023 @ 13:03:
[...]

Zijn policies, dus die kun je aanpassen….zou wat zijn als je maar 500 mails mag sturen

Die limieten zijn wat hoger tegenwoordig maar bestaan wel degelijk: https://learn.microsoft.c...e-limits#sending-limits-1