Onderwerp: bSMTP (of vergelijkbaar)?

Een (potentiele) klant wil op 1 van zijn domeinen zijn eigen thuis pc als inkomende mail server gebruiken. Op zich geen probleem voor ons, MX record even goed zetten en klaar (normaal gesproken)...

Echter hij geeft aan dat zijn ISP port 25 (inkomend) blokkeert. Dat gaan standaard dus niet werken. Zou (bijvoorbeeld) bSMTP een oplossing bieden (de klant maakt dan dus verbinding om zijn mail te de-queuen) of nog steeds het zelfde probleem. (en zo ja, iemand enig idee wat er binnen qmail moet gebeuren om dit te ondersteunen?)

Of anders een oplossing?

De smtp server ook op een andere poort laten draaien.

Bij bSMTP wordt de mail nogsteeds over poort 25 gestuurd.
Je zou via domainpop kunnen werken. Alle mail in 1 popbox laten komen, hem dat account laten ophalen en hij verdeeld de mail verder op zijn eigen server.

Origineel geplaatst door host3000
De smtp server ook op een andere poort laten draaien.

Dat heeft denk ik weinig zin, binnen een MX record is een port opgeven niet mogenlijk.

@InstantXs: Aan iets van domain pop zal ik ook te denken, ik had gehoopt dat bSMTP zou worden gezien als uitgaand port 25 (dat schijnt zijn ISP wel door te laten)....

Nee, wanneer de server van je klant een ETRN commando stuurt wordt de mail via een normale smtp(poort 25 dus) connectie gestuurd naar de uiteindelijke mailserver

Origineel geplaatst door royen99


Dat heeft denk ik weinig zin, binnen een MX record is een port opgeven niet mogenlijk.

Een poortnummer hoeft toch ook helemaal niet bij een mx record? Bij een A-record voeg je er toch ook geen 80 aan toe terwijl je httpd ook op een ander poort kan laten draaien.

De klant zal aan zijn kant ook met een smtp server werken. Die laat je (bijvoorbeeld) ook op poort 26 luisteren. Jij doet hetzelfde.

Hoe wil je ervoor zorgen dat de verzendende server weet dat hij via poort 26 moet connecten? dat gaat niet werken

Origineel geplaatst door InstantXs
Hoe wil je ervoor zorgen dat de verzendende server weet dat hij via poort 26 moet connecten? dat gaat niet werken

configuratie file ?

owja, we gaan alle mailserver op internet even op poort 26 zetten om zo te zorgen dat hij zen mail via poort 26 binnen krijgt

Kortom: poort van je mailserver wijzigen gaat niet werken (altans niet zonder een server die de mail naar de juiste poort forward)

@royen99 : Daar is nou net een speciale port voor uitgevonden : 587/tcp ("submission").

@InstantXs : met ETRN wordt er van de (providers-)mailserver een nieuwe connectie opgezet naar de mailserver van de kant. Bij TURN, however, gaat het verkeer over de reeds bestaande verbinding (precies waarom je geen TURN moet gebruiken). Hoe zit het dan met de dichtzittende poort 25? Ik heb dit eigenlijk nog nooit in de praktijk getest... Poort 25 / uitgaand wordt door de provider toegestaan, de klant kan e-mail versturen en dus een verbinding met de mailserver opzetten. Kortom er is ruimte voor het heen-en-weer sturen van TCP pakketjes.

@royen99 (again): Let wel, TURN is highly insecure. Ik zou het niet eens willen testen!
Probably kan je het beste het MX record wijzigen en een mailrelay van de toegangsprovider opgeven als 2e MX record (fallback). Of de klant gebruik laten maken van een catch-all POP account. Exchange (bijvoorbeeld) kan aan de hand van de Delivered-to header de email verder verspreiden.

@Digilover: dat zeg ik, de mail blijft in de queue staan, tot er een ETRN wordt gegeven. Daarna wordt de mail via de gebruikelijke manier afgeleverd (net zoals de rest van de mail in de queue die niet via bSTMP wordt opgehaald).

Zover ik weet heb je 2 (makkelijke) oplossing: DomainPOP of forwarding naar een andere poort. Met beide manieren heb je een extra server nodig die het afhandeld

Origineel geplaatst door InstantXs
@Digilover: dat zeg ik, de mail blijft in de queue staan, tot er een ETRN wordt gegeven. Daarna wordt de mail via de gebruikelijke manier afgeleverd (net zoals de rest van de mail in de queue die niet via bSTMP wordt opgehaald).

Met een ETRN commando, ja. Mijn twistpunt (sub-discussie) is nu : Hoe zit het met het TURN commando, als de verbinding $provider -> $klant over de reeds bestaande (-open-) verbinding $klant -> $provider gaat?

Zover ik weet heb je 2 (makkelijke) oplossing: DomainPOP of forwarding naar een andere poort. Met beide manieren heb je een extra server nodig die het afhandeld

Zo ongeveer alle providers die poort 25 inkomend sluiten (compleet useless, sluit liever uitgaand... magoed) hebben een relay-host beschikbaar. Planet.nl voorbeeld:

example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 mailrelay.planet.nl.

SMTP servers zullen eerst proberen om e-mail gericht aan postmaster@example.com af te leveren op mail.example.com. Omdat Planet poort 25 inkomend gesloten heeft, lukt dit niet. De verzendende SMTP server zal dan de e-mail afleveren op mailrelay.planet.nl welke het wel kan afleveren op mail.example.com (binnen het netwerk staat die poort gewoon open, leve borderrouters).

Klopt, even niet aan gedacht. Gebruik het ookniet dagelijks

1 van onze mail servers ondersteund zowel etrn als atrn (odmr) echter daar heeft de klant dus ook aparte software voor nodig. (ik ga er momenteel vanuit dat de klant iets als sendmail/qmail/exim draait (nog geen idee, wordt nagevraagd).

Zoals voorgesteld idd slimste om 2 mx records te maken, met zijn IP als primair, rest (waarschijnlijk dus alles) komt bij ons en via domainpop kan deze het ophalen.

Inkomend smtp blokeren, hoe verzinnen ze het (andersom kan ik me iets bijvoorstellen, al is het ook vaak lastig ..)

Thanks (ook alvast namens klant )..

Inkomend is handig om er voor e zorgen dat je klanten geen openrelay vormen. Verder zou ik het doen OF op de manier zoals digilover vertelde, of via domeinpop.
2 mx records en dan bij de 2e domeinpop instellen heeft geen zin, aangezien de mail toch altijd bij je 2e mx record uitkomt.
Gebruik je dus domainpop, dan heb je maar 1 mx record nodig, de andere is nutteloos.