Maximum connecties SMTP

[kozue]

Aangezien ik hierover niks kan vinden op het grote internet (het zal er allicht staan, maar waar?), hierbij meer een algemene vraag over meningen van anderen die SMTP servers beheren.

Onze SMTP server heeft al jaren een limiet op het aantal connecties per IP. Dit om te voorkomen dat 1 afzender de hele connection pool vol kan maken, wat voornamelijk door spammers en ander onguur volk gedaan zou worden. Het is immers voor zover ik weet de bedoeling, dat als je meerdere mails wilt versturen die nog in je queue staan, dat je die niet allemaal tegelijk probeert af te leveren via allemaal aparte verbindingen in een soort van parallel constructie, maar netjes 1 connectie opent en ze 1 voor 1 aanbiedt via deze connectie. Het zou daarom niet nodig moeten zijn om heel veel connecties per IP toe te staan. De limiet staat momenteel op 2.

Dit gaat al jaren goed, en niemand ooit over horen klagen. Maar nu is er 1 partij die ons facturen stuurt en tegen deze limiet aan loopt. Ze proberen er 10 of meer te versturen en alleen de eerste 2 lukken, de rest geeft een melding terug dat ze teveel connecties open hebben staan. Dat klinkt alsof ze voor iedere mail tegelijk een connectie proberen te openen. Dus als het er 10 zijn, krijgen we 10 parallelle connecties, en als het er een keer 100 zijn, maken ze 100 connecties. Mijn mening daarover is dat hun server niet deugt en ze die moeten fixen. Dit heb ik aangegeven (uiteraard in iets nettere bewoording), met als reactie terug dat hun server prima werkt en het aan onze kant ligt. Dat terwijl we van heel veel partijen facturen ontvangen en het daar allemaal prima werkt.

Dus hierbij dan mijn vraag... is wat ze doen acceptabel en is onze limiet van 2 connecties per IP te laag, of is hun server gewoon aan het spammen en worden ze terecht geblokkeerd? Ik ga ze geen oneindig veel connecties geven (dat levert allicht problemen op), en de limiet voor hun IP ophogen naar 10 lijkt me ook maar een halve oplossing (dan lopen ze er met mail 11 en 12 weer tegenaan). Bovendien ben ik sowieso niet van voorkeursbehandelingen en heb geen zin om voor hun een whitelist te gaan onderhouden...

[SambalBij]

Geen idee of daar echt standaards voor zijn. In principe is het geen groot probleem natuurlijk, omdat mail die tegen jouw limiet aan loopt in de queue blijft staan wordt later opnieuw geprobeerd. (Hoewel dat er van af hangt hoe jouw mailserver reageert. Houdt die gewoon de poort dicht, of doet ie wel open maar stuurt ie een SMTP error code terug? En indien het laatste, welke error code dan? 4xx of 5xx code? Dat bepaalt of de mail bij de afzender in de queue blijft en opnieuw geprobeerd wordt (bij error 4xx) of dat ie direct naar de afzender terug gaat met een NDR (error 5xx))

Denk wel dat je limiet ietsje te laag zet; als je kijkt bij bijvoorbeeld Microsoft Exchange (en daarmee dus ook hoogstwaarschijnlijk Office 365) dan zet die default maximaal 20 gelijktijdige connecties op per domein.
(https://docs.microsoft.co...mits?view=exchserver-2019)

[markvt]

Microsoft SMTP server op windows server:

"Limit number of connections per domain to
Configure this setting to specify the maximum number of concurrent outbound connections to any single remote domain. By default, the value is set to 100. The value should be less than or equal to the value that you set for Limit number of connections to."

[kozue]

@SambalBij De server geeft een SMTP error terug. "Too many concurrent connections from this IP address" ofzo, waarschijnlijk een 421. Dus dat was ook mijn gedachte: waarom is het een probleem, ze zouden toch later opnieuw geprobeerd moeten worden? En "later" is dan voor een eerste poging mogelijk nog in dezelfde minuut, of binnen een paar minuten, en dan zouden ze er alle 10 binnen een paar minuten doorheen moeten zijn.

Maar ze hebben een of ander vaag systeem met een dashboard waarin ze de status van mails kunnen zien, en die geeft aan dat ze mislukt zijn. Alsof ze geen retry functie hebben ofzo. Of 2 te laag is of niet laat ik nog even in het midden (even kijken wat anderen er van vinden), maar hun systeem rammelt sowieso op bepaalde vlakken. Met een normale mail server zou je denk ik niks hiervan moeten zien.

[SambalBij]

Dat zou inderdaad op zich geen problemen moeten opleveren; hij zou die mail dan in de queue moeten houden en later opnieuw proberen. Misschien gevalletje systeembeheerder die zich verveeld en de hele dag dan maar de mailqueue voor zich heeft

(En wat moet die arme jongen (m/v/x) dan wel niet met een greylisting ontvanger...Dan krijgt ie eerst helemaal geen connectie tot aan de eerste retry... )

[Rolfie]

SambalBij schreef op donderdag 31 maart 2022 @ 12:58:
Dat zou inderdaad op zich geen problemen moeten opleveren; hij zou die mail dan in de queue moeten houden en later opnieuw proberen. Misschien gevalletje systeembeheerder die zich verveeld en de hele dag dan maar de mailqueue voor zich heeft

Hangt van de applicatie af. Dit is waarschijnlijk een applicatie waarbij de applicatie direct verbinding naar de SMTP server maakt en blijkbaar meerdere processen heeft draaien waardoor er meerdere SMTP verbindingen tegelijkertijd gemaakt worden. Niet een heel vreemde opzet.

[Question Mark]

kozue schreef op donderdag 31 maart 2022 @ 11:30:

Onze SMTP server

Welke SMTP software wordt hiervoor gebruikt? Kan het ook zijn dat je last hebt van tarpitting, wat Exchange óók als anti-spam maatregel gebruikt?

[kozue]

Het is exim 4 op Ubuntu 20.04. Tarpitting zegt me niks, wat houdt dat in?

Ik had bewust geen software genoemd omdat m'n vraag meer algemeen en conceptueel is en ik antwoorden over software-specifieke configuratie wilde voorkomen, of het aantrekken van exim-specifieke antwoorden. Ik doe niks met enige vorm van Windows, maar weten wat Exchange in z'n standaard configuratie doet, zoals hierboven genoemd, kan ook van pas komen

[kozue]

Rolfie schreef op donderdag 31 maart 2022 @ 17:48:
[...]

Hangt van de applicatie af. Dit is waarschijnlijk een applicatie waarbij de applicatie direct verbinding naar de SMTP server maakt en blijkbaar meerdere processen heeft draaien waardoor er meerdere SMTP verbindingen tegelijkertijd gemaakt worden. Niet een heel vreemde opzet.

Hoort zo'n applicatie de mail niet gewoon aan een lokale SMTP te geven ipv zelf het wiel opnieuw uit te vinden met een eigen SMTP implementatie vol beperkingen en eigenaardigheden? Er komt best veel kijken bij het versturen van mail (DNS, SPF, DKIM, etc) en met het direct verbinden naar SMTP servers van anderen loop je al snel tegen problemen aan.

[Brahiewahiewa]

kozue schreef op donderdag 31 maart 2022 @ 11:30:
...
Onze SMTP server heeft al jaren een limiet op het aantal connecties per IP. Dit om te voorkomen dat 1 afzender de hele connection pool vol kan maken, wat voornamelijk door spammers en ander onguur volk gedaan zou worden...

Kwenie hoor. Ik ben geneigd te zeggen dat dit klinkklare onzin is. Spammers moet je gewoon weren van je servers, niet toelaten en dan enigszins frustreren

[kozue]

Als we zo makkelijk onderscheid konden maken tussen een spammer en normale verzenders, bestond spam al niet meer he

[Rolfie]

kozue schreef op vrijdag 1 april 2022 @ 11:40:
Hoort zo'n applicatie de mail niet gewoon aan een lokale SMTP te geven ipv zelf het wiel opnieuw uit te vinden met een eigen SMTP implementatie vol beperkingen en eigenaardigheden? Er komt best veel kijken bij het versturen van mail (DNS, SPF, DKIM, etc) en met het direct verbinden naar SMTP servers van anderen loop je al snel tegen problemen aan.

Dat is een mogelijkheid. Die SMTP server zou alles weer kunnen doorsturen richting jullie SMTP server, welke DNS/SPF/DKIM regeled.
Maar dan moet die lokale SMTP server weer niet toevallig meerdere threads gebruiken, al zal dat met een retry weer opgelost worden.
Maar die lokale SMTP server moet ingericht en onderhouden worden.

Juist direct naar een (internet) SMTP server lost heel veel problemen op, dit gaat bijna altijd met libraries en vraagt dus weinig onderhoud.

Je moet natuurlijk dan wel een goed geconfigureerde en betrouwbare SMTP server gebruiken.

[DJMaze]

Je zou als test eens alleen TLSv1.2+ toestaan.
Dat blokkeert standaard een hele berg oude meuk.
Als zij je dan geen factuur meer kunnen sturen weet je genoeg.

Verder kent SMTP het RSET commando om de verbinding te resetten en de volgende mail af te leveren zodat je niet steeds opnieuw een verbinding hoeft op te zetten.
Niet elke SMTP ondersteunt dit, maar dan heb je dus nooit meer dan 1 connectie nodig.
https://www.postfix.org/CONNECTION_CACHE_README.html

[ Voor 6% gewijzigd door DJMaze op 01-04-2022 20:11 ]

[Jazzy]

DJMaze schreef op vrijdag 1 april 2022 @ 20:07:
Je zou als test eens alleen TLSv1.2+ toestaan.
Dat blokkeert standaard een hele berg oude meuk.
Als zij je dan geen factuur meer kunnen sturen weet je genoeg.

Wat wil je hiermee testen? Of de zendende server TLS ondersteunt, en welke versie, kun je gewoon in je logs lezen.

[DJMaze]

@Jazzy factuur via email is nog niet officieel.
Niks ontvangen = geen betalingstermijn
Als de verzendende partij geld wil, moeten ze hun zaakjes op orde hebben.
TLSv1.2+ is met PSD2 en andere regels een vereiste.

[ Voor 13% gewijzigd door DJMaze op 02-04-2022 01:03 ]

[boyette]

kozue schreef op donderdag 31 maart 2022 @ 11:30:
Aangezien ik hierover niks kan vinden op het grote internet (het zal er allicht staan, maar waar?), hierbij meer een algemene vraag over meningen van anderen die SMTP servers beheren.

Onze SMTP server heeft al jaren een limiet op het aantal connecties per IP. Dit om te voorkomen dat 1 afzender de hele connection pool vol kan maken, wat voornamelijk door spammers en ander onguur volk gedaan zou worden. Het is immers voor zover ik weet de bedoeling, dat als je meerdere mails wilt versturen die nog in je queue staan, dat je die niet allemaal tegelijk probeert af te leveren via allemaal aparte verbindingen in een soort van parallel constructie, maar netjes 1 connectie opent en ze 1 voor 1 aanbiedt via deze connectie. Het zou daarom niet nodig moeten zijn om heel veel connecties per IP toe te staan. De limiet staat momenteel op 2.

Dit gaat al jaren goed, en niemand ooit over horen klagen. Maar nu is er 1 partij die ons facturen stuurt en tegen deze limiet aan loopt. Ze proberen er 10 of meer te versturen en alleen de eerste 2 lukken, de rest geeft een melding terug dat ze teveel connecties open hebben staan. Dat klinkt alsof ze voor iedere mail tegelijk een connectie proberen te openen. Dus als het er 10 zijn, krijgen we 10 parallelle connecties, en als het er een keer 100 zijn, maken ze 100 connecties. Mijn mening daarover is dat hun server niet deugt en ze die moeten fixen. Dit heb ik aangegeven (uiteraard in iets nettere bewoording), met als reactie terug dat hun server prima werkt en het aan onze kant ligt. Dat terwijl we van heel veel partijen facturen ontvangen en het daar allemaal prima werkt.

Dus hierbij dan mijn vraag... is wat ze doen acceptabel en is onze limiet van 2 connecties per IP te laag, of is hun server gewoon aan het spammen en worden ze terecht geblokkeerd? Ik ga ze geen oneindig veel connecties geven (dat levert allicht problemen op), en de limiet voor hun IP ophogen naar 10 lijkt me ook maar een halve oplossing (dan lopen ze er met mail 11 en 12 weer tegenaan). Bovendien ben ik sowieso niet van voorkeursbehandelingen en heb geen zin om voor hun een whitelist te gaan onderhouden...

Je kunt toch gewoon de limiet voor hun ip weghalen als je dit op ip basis kunt regelen.
of desnoods op 25 zetten dan heb je het nog een beetje beveiligd.
Wat is het risico daarvan..?

[kozue]

boyette schreef op zaterdag 2 april 2022 @ 01:13:
[...]


Je kunt toch gewoon de limiet voor hun ip weghalen als je dit op ip basis kunt regelen.
of desnoods op 25 zetten dan heb je het nog een beetje beveiligd.
Wat is het risico daarvan..?

Het is mogelijk dit per IP verschillend te maken, maar dit gaat met condities (een soort if-else) en maakt de config dus complexer. Extra complexiteit is extra onderhoud. Ik heb niet veel zin om onze systemen en config complexer te maken voor andermans knutselwerkjes. Ik zie 2 mogelijke oplossingen: of het blijft zoals het is, en ze mogen het aan hun kant fixen (als ze zelf het probleem veroorzaken met non-standaard custom systemen), of de limiet gaat globaal omhoog voor alle IP’s.

[NielsFL]

Even terug naar het begin: je hebt deze instelling gemaakt omdat het spam zou verminderen. Maar is dat ook echt aantoonbaar zo?

En is het dan effectiever dan een rspam, spam assassin of andere "normale" oplossing? (Voor mij werkt rspam echt heel erg goed.)

[Brahiewahiewa]

NielsFL schreef op zaterdag 2 april 2022 @ 10:56:
Even terug naar het begin: je hebt deze instelling gemaakt omdat het spam zou verminderen. Maar is dat ook echt aantoonbaar zo? ...

Eerlijk gezegd krijg ik de indruk van de TS dat hij spammers op zijn server niet zo erg vindt, zolang ze maar niet teveel spam versturen

[boyette]

kozue schreef op zaterdag 2 april 2022 @ 08:01:
[...]


Het is mogelijk dit per IP verschillend te maken, maar dit gaat met condities (een soort if-else) en maakt de config dus complexer. Extra complexiteit is extra onderhoud. Ik heb niet veel zin om onze systemen en config complexer te maken voor andermans knutselwerkjes. Ik zie 2 mogelijke oplossingen: of het blijft zoals het is, en ze mogen het aan hun kant fixen (als ze zelf het probleem veroorzaken met non-standaard custom systemen), of de limiet gaat globaal omhoog voor alle IP’s.

Dat laatste lijkt me niet zo verkeerd..
ik ben toch ook niet overtuigd dat zij een probleem hebben hier..
als zij alles tegelijkertijd factureren en op dat moment geen ander mailverkeer hebben en een flinke server hebben die al die mailtjes tegelijkertijd verstuurt dan krijg je meerdere open sessies.

Aan jouw kant is de configuratie echter wat vreemd en omdat de mailserver zelf ook de server is die het smtp verkeer afhandeld krijg je dit

[degroot]

Eigenlijk zou je een Email Security (cloud of on-prem) oplossing ervoor moeten zetten.
Dan hoef je zelf ook niet die trukendoos open te trekken m.b.t. het aantal connecties per IP om zo SPAM of berichten van ongure types te voorkomen.
Als je de Email Security oplossing eenmaal goed instelt , heb je er weinig omkijken meer naar. Die bepaald wel aan de hand van Threat Intel of een IP onguur is. Tevens kan je beter bepaalde policies afdwingen , en scan je attachments al "buiten de poort".

[kozue]

Ik heb het aantal connecties per IP maar op 20 gezet (dezelfde waarde als Exchange standaard aanhoudt voor outgoing). Ik vind 20 gelijktijdige connecties nog steeds overdreven veel (zo realtime is email niet dat je niet in batches kan versturen met 1 connectie), maar ik ben het gezeur zat. Vandaag weer het zoveelste mailtje hierover.

Thanks iedereen voor jullie meningen en inzicht

[fictorie]

Voor een grote landelijke organisatie doen wij de mail relay. Deze organisatie krijgt veeeeeel mail binnen. Wij hebben 10 concurrent connections per ip staan (en 2 mail relays aan de internet kant).