Blokkeert EDPnet poort 25 (mail out) ?

[LucP]

Vanochtend overgestapt van Dommel naar EDPnet, nadat zowel de klantendienst als de technische dienst mij verzekerd hadden dat EDPnet "geen enkele" poort blokkeert. Dat was cruciaal voor mij, omdat ik o.a. mijn eigen mail server draai.

Heb inmiddels IPv4/IPv6 internet connectie - met een EDPnet IP adres, supersnel dus.

Alleen lijkt poort 25 (uitgaande mail) toch geblokkeerd, behalve dan naar de eigen EDPnet mail servers.

Met "telnet mail.example.com 25" (naam is fictief) krijg ik "no route to host".

Weet iemand hier meer over?

Het gaat om een VDSL-formule voor privé-gebruik, met een variabel IP adres.

Inkomende mail werkt prima.

[Joachim]

Het spijt me dat te horen, want we blokkeren effectief poort 25 uitgaand op dyn abo's, dit is een echte noodzaak vanwege vele virussen die hierop werken

Zie ook: https://www.edpnet.be/nl/support/oploss ... en-is.html

[GuntherDW]

Op dit forum even zoeken laat je zien dat voor consumenten abbo's je mail moet laten relayen via relay.edpnet.be. Er is ook een lijstje van adressen voor je SPF records bezichtbaar.

Dat relayen heb je zo ingesteld echter. Bij dommel kon je rechtstreeks gaan inderdaad, maar "public" IP's staan heel vaak op blocklists, net omdat het residential IP's zijn. Alsook blocken veel diensten als gmail je omdat je RDNS niet overeen komt met bv "mail.domain.be".

https://userbase.be/forum/viewtopic.php?t=52798#p747381

Wat is trouwens de limiet per dag/uur van deze relay eigenlijk? Ik weet dat gmail het niet leuk vind als je in 1 uur tijd opeens 30 mails stuurt terwijl je niet in hun "whitelist" staat, maar wil graag wel concrete info eigenlijk.
EDIT: Op de engelse versie van die pagina is er nog een link naar de feitelijke limieten van deze service, maar op de nederlandse is er geen link naar?
https://www.edpnet.be/en/support/instal ... imits.html

[Sinna]

Dat had ik eerder gemeld in het Proximus stopt samenwerking met Dommel/Billi-topic: voor residentiële klanten moet het via edpnet-mailservers, professionele klanten kunnen hun eigen mailserver gebruiken, zie https://userbase.be/forum/viewtopic.php ... 75#p782619.

[LucP]

Ja, ik had dat bericht in het Dommel draadje gezien, precies daarom dat ik een half uur of zo op wacht heb gestaan bij EDPnet om het na te vragen. Ik had verwacht dat ik dan een correct en up-to-date antwoord zou krijgen. Niet dus ...

Ik wil hier de discussie niet aangaan over zin en onzin van het draaien van een mail server op een dynamisch IP..

Ik draai mijn eigen mail server sinds 1998 of zo, steeds vast IP, maar sinds Dommel dat afschafte bij de invoering van VDSL, heb ik de issues met blacklists enz. redelijk onder controle.

De hoofdreden voor mij om rechtstreeks te willen gaan is dat ik dan weet waar de mail zit. Het komt maar al te vaak voor dat bvb een destination MX plat ligt, en dan blijft de mail bij mij in de queue zitten, waar ik hem kan zien. Dat heeft me al veel discussies bespaard. Als ik de mail via een relay stuur, dan weet ik niet waar hij gebleven is.

Mijn vertrouwen in EDPnet heeft alvast een flinke deuk gekregen.

[ITnetadmin]

Het spijt me dat te horen, want we blokkeren effectief poort 25 uitgaand op dyn abo's, dit is een echte noodzaak vanwege vele virussen die hierop werken

Je kan dat natuurlijk ook opt-out maken.
Best of both worlds, maar de meeste isp's zijn te lui om de moeite te doen.
Ik zou zeggen "bewijs dat het ook anders kan".

[GuntherDW]

Als het echt zo belangrijk is...

https://www.edpnet.be/nl/business/internet.html

Echter kan je dan later ook niet meer van dingen als easyswitch gebruik maken.
Ik heb zelf zo ook wat dingen die ik jammer vind, bv geen fixed IP meer, tenzij ik ineens veel bijleg voor dat Pro abbo.

[LucP]

Het spijt me dat te horen, want we blokkeren effectief poort 25 uitgaand op dyn abo's, dit is een echte noodzaak vanwege vele virussen die hierop werken

Dat was tien jaar geleden of zoiets.

Later zijn virussen wat slimmer geworden, en zijn ze ook via de mail-out relay van de ISP beginnen sturen, met als gevolg dat die dan op de zwarte lijst terecht kwam - samen met al zijn klanten. Dat kwam zo vaak voor dat ik zelfs een tijdje een whitelist (RWL) heb gedraaid met alle (mij) bekende Belgische ISP mail servers er op.

Ik zie dat trouwens nog altijd gebeuren, en vaak duurt het dan een hele tijd voor de ISP zichzelf weer van de lijst gewerkt heeft. Tot die tijd moet ik het IP adres whitelisten als ik de mail wil binnenkrijgen.

Je kan dat natuurlijk ook opt-out maken.
Best of both worlds, maar de meeste isp's zijn te lui om de moeite te doen.
Ik zou zeggen "bewijs dat het ook anders kan".

Dat zou inderdaad een simpele oplossing zijn, die voor EDPnet trouwens wat extra klanten zou genereren. Ik ben beslist niet de enige die op zoek is naar een betaalbare manier om mijn mail zelf onder controle te houden.

Het voorkomen van misbruik lijkt me dan niet moeilijker dan met een statisch IP. Zo'n een opt-out impliceert trouwens dat de klant, die dat vraagt, ook zijn verantwoordelijkheid opneemt.

[MarkDM]

EDPNET heeft nog eigenaardige kronkels. Je kan geen mail versturen met als inhoud alleen een afbeelding in jpg, gif, png of zo. Dus zonder tekst.
Ik heb daar lang geleden al voor geprotesteerd.
Hun antwoord: "Dat is een berichtstructuur van spam, wij laten dat niet door."
Bij andere providers is dat nochtans geen probleem.

[on4bam]

Is er een "goede" reden om poort 25 te gebruiken? Als EDP'er gebruik ik hun mailserver niet maar wel die van mijn domain. No problems at all maar ik gebruik dan wel poort 465 met encryptie.
En idd. Ik ben jaren terug bij Dommel vertrokken omdat ze weigerden iets te doen aan het probleem van hun geblackliste mailservers (ik had er ook hosting).

[GuntherDW]

Lang niet elke mailserver accept encrypted mail over poort 465/587, laat staan dat die poorten open staan. 25 is de "safe bet". Al kan het ook als failover ingesteld worden natuurlijk.
Echter kan je ook gewoon op port 25 "STARTTLS" gebruiken voor toch encryption te hebben over poort 25.

[LucP]

Ja, ik heb net ook gemerkt dat ze de uitgaande mail censureren.

Een bericht met als inhoud "Test message" wordt tegengehouden door relay.edpnet.be.

Message you sent was blocked by our bulk email filter

Dit heeft niks te maken met dynamic IP, die mail werd wel degelijk via hun relay verstuurd (weliswaar om mijn SPF setup te testen). Deze censuur doen ze dus voor al hun klanten...

[GuntherDW]

Zulke "Test message" messages tegenhouden ga je bij bijna elke provider wel zien waarbij je hun relay moet gebruiken.
Had je bij dommel bijvoorbeeld ook als je van hun relay gebruik zou maken.

[LucP]

Mooi niet dus. De bewuste mail wordt gegenereerd door een scriptje dat mijn SPF config controleert. De mail via relay.dommel.be ging er zonder enig probleem door, elke keer weer.

Ik heb trouwens nooit gehoord dat dommel de uitgaande mail van hun klanten zou filteren. Maar dat doet er nu even niet toe, nu ik ontdek dat EDPnet het blijkbaar wél doet.

Meteen nog één van de redenen om mijn eigen mail server te blijven draaien. Ik betaal een provider om mij een internet verbinding te leveren, en niet om mijn uitgaande post te censureren.

Nog veel minder om de inkomende mail te filteren trouwens, maar dat is gelukkig (?) niet aan de orde. Inbound smtp mag blijkbaar wel van EDPnet.

[keerekeerweere]

Als je echt uitgaande mails wil sturen, is misschien een kleine dedicated server of VPS een optie ? Of misschien zelfs een kleine container of pod gebaseerde oplossing ?
Kan vanaf een maar EUR / maand...

[GuntherDW]

Ik had wel "last" van dommel dat "test messages" blokkeerde, hence m'n bericht erover .
Dingen als "Test" in de subject was ook een trigger. Sindsdien stuurde/forwardde ik gewoon berichten of newsletters als test om te kijken of alles goed werkt.

[ITnetadmin]

Is er een "goede" reden om poort 25 te gebruiken? Als EDP'er gebruik ik hun mailserver niet maar wel die van mijn domain. No problems at all maar ik gebruik dan wel poort 465 met encryptie.
En idd. Ik ben jaren terug bij Dommel vertrokken omdat ze weigerden iets te doen aan het probleem van hun geblackliste mailservers (ik had er ook hosting).

Lang niet elke mailserver accept encrypted mail over poort 465/587, laat staan dat die poorten open staan. 25 is de "safe bet". Al kan het ook als failover ingesteld worden natuurlijk.
Echter kan je ook gewoon op port 25 "STARTTLS" gebruiken voor toch encryption te hebben over poort 25.

Om effe te verduidelijken:
Vele webhosts die email aanbieden laten je toe om hun mailservers te gebruiken voor verzending; deze laten dan zeer vaak connecties toe op poorten anders dan 25, speciaal om die ISP blocks te omzeilen.

Dit heeft echter geen enkele invloed op mensen die zelf thuis een mailserver beheren.
Eigen mailservers moeten nl hun verzendingen afleveren aan andere mailservers; de locaties daarvan halen ze uit het TO adres, waarvan ze de host (een email is altijd user@host) opzoeken via DNS (via de MX records).
Die server to server communicatie gebeurt echter steevast via port 25, en daarvoor zijn *zelden* alternates voorzien.

1 groot probleem daarmee overigens:
DNS werkt (tot nu toe) *enkel* op layer 3; maw je kan geen port opgeven in DNS, enkel een IP (wat ik een tekortkoming vind van DNS, maar soit, daar was het niet voor gemaakt omdat het originele protocol ervan uitging dat ports niet geblocked worden en de default ports altijd beschikbaar zijn).
En moest dat wel lukken, dan nog zou je mailserver elke andere mailserver die geen alternate port voorziet niet kunnen bereiken.

[LucP]

Als je echt uitgaande mails wil sturen, is misschien een kleine dedicated server of VPS een optie ? Of misschien zelfs een kleine container of pod gebaseerde oplossing ?
Kan vanaf een maar EUR / maand...

Er zijn inderdaad meerdere "oplossingen" denkbaar, maar waarom zou ik extra moeten betalen om een probleem op te lossen dat door EDPnet wordt veroorzaakt?

Ze moeten maar gewoon hun blokkering van poort 25 outbound weer ongedaan maken, desnoods met een opt-out.

Vergeet ook niet dat we hier zitten omdat zowel de klantendienst als de technische dienst van EDPnet mij telefonisch verzekerd hadden dat ze *geen enkele poort* blokkeren. Aan de laatste heb ik zelfs gevraagd: "is dat formeel?", waarop ze stellig antwoordde "ja, dat is formeel, wij blokkeren geen enkele poort".

Hadden ze mij gezegd dat 25 dicht is, dan was ik zeker niet naar hen overgestapt.

Ik wil kleinere providers best een kans geven (anders waren we in 2014 niet naar Dommel gegaan), maar dan verwacht ik wel dat ze klantgericht denken. Voor de eenheidsworst-benadering, stijl "bij ons is het zo, punt uit", kan ik evengoed bij de grote dozen terecht.

Voor misleidende en ondeskundige "support" overigens ook.

Ik had wel "last" van dommel dat "test messages" blokkeerde, hence m'n bericht erover .

Waarvan akte . Mijn ervaring dateert van het laatste jaar of zo, toen Dommel ons dwong om van ADSL-2 naar VDSL over te schakelen en ik mijn fixed IP kwijt was.

Echter kan je ook gewoon op port 25 "STARTTLS" gebruiken voor toch encryption te hebben over poort 25.

Dat is tussen haakjes nog een reden om mijn eigen mail server te blijven draaien. De laatste tijd gaan er vaak mails heen en weer tussen ons en emmaus.be, een koepel van ziekenhuizen en verzorgingsinstelling. Die bevatten gevoelige medische informatie.

Zij supporteren ook TLS, dus als ik die rechtstreeks bij hen binnensteek, dan gaat de mail over de draad in versleutelde vorm.

Als ik via relay.edpnet.be moet gaan, dan heb ik weliswaar TLS tot bij hen, maar ten eerste gaat daar de mail onversleuteld op hun schijf in de queue (en ze kunnen die dus lezen als ze dat zouden willen), en ten tweede heb ik er geen flauw idee van of zij ook via TLS naar de eindbestemming gaan.

Nog straffer: relay.edpnet.be ondersteunt zelfs geen DSN !!

Telnet naar hen op poort 25 en dan krijg ik dit op mijn EHLO:

Code: Selecteer alles

250-SIZE 100000000
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-STARTTLS
250-PIPELINING
250-8BITMIME
250 HELP

Normaal moet daar "250 DSN" bij staan.

Ik heb vanochtend een mail gestuurd waar ik ten laatste vanmiddag op moest antwoorden, en had dus een DSN gevraagd. Noppes dus. Nu weet ik dus niet of mijn mail bij de bestemmeling is toegekomen, of dat hij misschien nog op de schijf zit bij EDPnet, of dat hij er misschien zelfs afgevallen is.

Zelfs Dommel had die DSN optie. Maar ja, DSN is nog maar pas in januari 2003 ingevoerd (RFC 3461)....

Ik begin het gevoel te krijgen dat ik niet alleen van de Dommel-regen in de EDPnet-drup terecht ben gekomen, maar onderweg ook nog per abuus de tram naar het stenen tijdperk heb gepakt.

Ik ben alle controle over mijn uitgaande mail compleet kwijt.

[Fatsie]

Lang niet elke mailserver accept encrypted mail over poort 465/587, laat staan dat die poorten open staan. 25 is de "safe bet".

Ik meen dat 587 voor MSA bedoeld is, Mail Submission Agent, dus mails van een MUA (Outlook, Thunderbird, ...) aanvaarden.
25 is voor MTA, Mail Transfer Agent, ofte communicatie tussen servers bedoeld met gebruik van het SMTP protocol. Servers onder mekaar gaan normaal geen MSA/587 gebruiken.

Een server kan natuurlijk beide rollen vervullen, mails van lokale gebruikers in het LAN aanvaarden op 587 en dan met MTA/SMTP afleveren aan de server van de bestemmeling, eventueel via tussenliggende relays.

[lithion]

Ik ben alleszins voor een blokkade op poort 25 uitgaand. Er zijn teveel mensen die zelf hun eigen mailserver willen draaien, maar te weinig kennis hebben om dat goed te doen of de software nooit updaten zodat die vatbaar wordt voor hackers. Dergelijke mensen zorgen er dan voor dat ganse IP ranges geblokkeerd worden en EDPNET een slechte reputatie krijgt. EDPNET is hierin eigenlijk nog redelijk tolerant tov andere providers aangezien ze inkomend op poort 25 wel toestaan. Een opt-out zou ideaal zijn moest een gebruiker enkel zichzelf kunnen straffen. Hier is dit dus niet het geval.

[LucP]

Ik ben alleszins voor een blokkade op poort 25 uitgaand. Er zijn teveel mensen die zelf hun eigen mailserver willen draaien, maar te weinig kennis hebben om dat goed te doen of de software nooit updaten zodat die vatbaar wordt voor hackers.

Tot hier kan ik je perfect volgen.

Maar dat geldt ook voor klanten die bereid zijn om een VDSL Pro met vast IP te betalen. Het is niet omdat ze meer geld hebben, dat ze ook meer kennis hebben van mail servers. Toch krijgen die automatisch groen licht.

Dergelijke mensen zorgen er dan voor dat ganse IP ranges geblokkeerd worden en EDPNET een slechte reputatie krijgt.

Niet noodzakelijk. Het hangt er volledig van af hoe adequaat EDPnet reageert op klachten.

Als ik spam zie binnenkomen van een Duits of Engels netwerk, dan stuur ik meestal een klacht, en dan wordt er in de regel ook actie ondernomen. Voor andere landen doe ik de moeite niet (meer), en dan zie je inderdaad hele ranges geblokkeerd worden als zijnde van "spam-friendly providers".

Dan nog heeft dat geen rechtstreekse gevolgen voor de reputatie van de provider zelf, toch niet in de zin dat mails van zijn eigen servers geblokkeerd zouden worden (tenzij hij zelf een dynamisch IP uit die range zou gebruiken ).

EDPNET is hierin eigenlijk nog redelijk tolerant tov andere providers aangezien ze inkomend op poort 25 wel toestaan. Een opt-out zou ideaal zijn moest een gebruiker enkel zichzelf kunnen straffen. Hier is dit dus niet het geval.

Ten eerste: zoals EDPnet het nu doet, straffen ze niet alleen zichzelf maar ook al hun klanten als er een "foute" mail door hun filters raakt, want dan worden ze zelf geblokkeerd. En dat is eigenlijk onvermijdelijk, want geen enkele spam filter is perfect, en ook anti-virus software kan niet anders dan achter de feiten aanhollen.

Om die blokkering ongedaan te maken, moeten ze de "dader" vinden en maatregelen nemen om herhaling te voorkomen. Dan nog zijn sommige blacklists erg weigerachtig om een kleine provider er weer af te halen.

Tot die tijd is heel EDPnet geblokkeerd.

Als ze nu een opt-out zouden voorzien, dan zou die klant wel degelijk enkel zichzelf straffen - op voorwaarde dat EDPnet adequaat optreedt bij klachten. Maar dat moeten ze eigenlijk sowieso doen, zie hoger.

In dat geval zouden ze de "rotte appel" namelijk snel te pakken hebben, en de opt-out gewoon weer kunnen intrekken.

Het enige verschil met een vaste-IP-klant is dat het IP van een "residentiële" mail server kan gewijzigd zijn tegen de tijd dat er een klacht binnenkomt en EDPnet er kan op reageren. Maar daar hebben ze hun logs voor.

Bijkomend voordeel voor EDPnet is dat ze, als één of meer van hun dynamische IP's geblokkeerd raken wegens zo'n rotte appel, ze geen moeite hoeven te doen om die weer van de lijst(en) te krijgen. Met hun eigen relay server moeten ze dat natuurlijk wel. En zoals gezegd is dat niet altijd simpel.

Voor mijn part zouden ze trouwens de mail server van de klant kunnen testen alvorens het opt-out verzoek te honoreren. Ik denk dan bvb aan tooltjes zoals https://www.hardenize.com. Als de klant dan groen licht krijgt, dan weet je tenminste dat er daar een mail admin zit die niet zomaar een out-of-the-box installatie heeft gedaan. Een soort "rijbewijs" dus, maar dan om "met een mail server te mogen rijden".

[LucP]

Ja, ik heb net ook gemerkt dat ze de uitgaande mail censureren.

Een bericht met als inhoud "Test message" wordt tegengehouden door relay.edpnet.be.

Message you sent was blocked by our bulk email filter

Dit heeft niks te maken met dynamic IP, die mail werd wel degelijk via hun relay verstuurd (weliswaar om mijn SPF setup te testen). Deze censuur doen ze dus voor al hun klanten...

Dat moet ik enigszins nuanceren.

Misschien eerst even resumeren. Zoals gezegd werd dit "test" bericht gegenereerd door een scriptje. Dat was een Q&D ding in Perl dat een socket opent, rechtstreeks naar de destination server (dus relay.edpnet.be), en dat vervolgens een bare-bones SMTP dialoog uitvoert. Ik had het in elkaar gedraaid om mijn SPF setup te testen toen Dommel mij dwong over te schakelen van een vast naar een dynamisch IP. Met hun relay server werkte dat altijd zonder problemen, maar met relay.edpnet.be ging het dus ineens fout.

Gisteren probeerde ik dan een bericht met exact dezelfde inhoud ("Test message") en hetzelfde onderwerp naar dezelfde bestemmeling te sturen vanuit een echte MUA (Thunderbird), en die mail ging er wél door. Het probleem lag dus elders, en het was dan niet moeilijk te raden waar het zat.

Ik heb mijn scriptje inmiddels gewijzigd en een "Date" header in RFC-822 formaat aan het bericht toegevoegd. En inderdaad: nu gaat ook dat er door. Het is reproduceerbaar: als ik de "Date" header weglaat, krijg ik bovenstaande foutmelding, als ik hem toevoeg, lukt het prima.

Welnu: met een dergelijke controle op mijn uitgaande mail heb ik geen enkele moeite (ook al is hij anno 2019 nog maar weinig zinvol meer, maar als hij niet baat, dan schaadt hij ook niet - toch niet voor normale mails).

Anders gezegd, en duidelijker: als EDPnet inderdaad enkel en alleen de envelope van de uitgaande mail controleert op syntax, dan neem ik terug wat ik gezegd heb over "censuur".

Als echter zou blijken dat ze toch ook de inhoud van mijn uitgaande mail zouden analyseren, dan zou dat een heel ander paar mouwen zijn.