Nu begin ik toch aan mezelf te twijfelen.
Een ehlo/helo name van een mailserver, moet een FQDN zijn. Maar die moet toch ook een MX record hebben normaliter of niet?
Likes: 0
04/01/11 02:31
Nu begin ik toch aan mezelf te twijfelen.
Een ehlo/helo name van een mailserver, moet een FQDN zijn. Maar die moet toch ook een MX record hebben normaliter of niet?
04/01/11 02:58
MX hoeft niet. Zekerheidshalve zou ik wel een A record aanmaken.
04/01/11 03:12
Oh. Een mx record is dus alleen nodig om mail te kunnen ontvangen volgens rfc?
En een ehlo/helo name hoeft alleen een FQDN te zijn dan?
Ik dacht altijd dat dit met elkaar te maken had, omdat er dan gecontroleerd kon worden of betreffende server (die de ehlo/helo afgeeft) wel mail mag versturen, c.q. een RFC gekwalificeerde mailserver betreft.
Maar dat is dus niet zo?
04/01/11 03:23
Eerlijk gezegd kan ik dat moeilijk geloven. Zelfs bij abuseat zie ik het volgende staan als je een testbericht krijgt op de helocheck:
Lijkt mij dus toch dat zoals ik al aannam de helo een MX record moet hebben, aangezien de FQDN van je mailserver namelijk een MX record (en A record) hebben moet.It should be the fully qualified domain name for your mail server
04/01/11 07:44
Een FQDN is een (kort gezegd) internet routeerbare domeinnaam. Zegt niets over het soort dns record. Je hebt het hier alleen over de helo. Natuurlijk heb je voor het ontvangen van email een mx record nodig, maar dat heeft op zich weinig met de helo te maken.
04/01/11 08:49
Wat niet volgens RFC is (jammer) maar wel vaak gechecked wordt, is of de reverse entry voor het IP van de server overeenkomt met de fqdn in de helo.
04/01/11 09:55
Ik zal het eens proberen uit te leggen met een voorbeeld:Oorspronkelijk geplaatst door Blacky
Domein: domain.com
De mailserver heet pietje.
De FQDN van de server is dan bv pietje.domain.com, de reverse dns staat daar ook heen.
In de MX records staat: domain.com mx 10 mx1.domain.com en domain.com mx 20 mx2.domain.com
mx1.domain.com wijst naar hetzelfde ip als pietje.domain.com. mx2 naar iets anders.
Voor domain2.com geldt hetzelfde, mx1.domain2.com verwijst naar hetzelfde ip als pietje.example.com.
De FQDN voor de primaire MX server van domain2.com zit dan ook in een ander domein, wat prima is.
04/01/11 12:17
In principe heb je voor het ontvangen van email geen MX record nodig. Als deze niet bestaat, zal de email afgeleverd worden op het A record van het domein (of van het subdomein).
Dit alles staat beschreven in RFC 5321, sectie 5.1.
ja - advies en beheer: Hosting in de cloud - the next big thing!
04/01/11 12:26
Dit dus
04/01/11 12:39
Ondanks dat je gelijk hebt, maak je het alleen maar onnodig moeilijk nu.
04/01/11 12:55
Dat was niet de bedoeling.
Hiermee probeerde ik juist wat extra informatie te geven. Ik heb al te vaak mee gemaakt namelijk dat er vanuit gegaan wordt dat zonder MX record geen email ontvangen wordt (bijvoorbeeld om spam tegen te houden), maar dit is dus niet het geval.
Om toch nog ontopic te blijven:
In RFC 2821, sectie 3.6, staat duidelijk beschreven dat een FQDN (in de HELO of EHLO) beschikking moet hebben over een A record. Mocht er geen A record beschikbaar zijn, dan moet er een ipadres gebruikt worden in de HELO of EHLO.
ja - advies en beheer: Hosting in de cloud - the next big thing!
04/01/11 13:17
Helaas zijn er een paar mailservers die daar niet mee om kunnen gaan.
Advies voor mailservers die mail verzenden (voor mailservers die enkel mail ontvangen is het minder van belang):
Domein: domain.com
Servernaam: pietje
IP: 10.0.0.5
rDNS IP 10.0.0.5: pietje.domain.com
pietje.domain.com verwijst via een A-record naar 10.0.0.5
HELO/EHLO: pietje.domain.com
Voor mailservers die enkel email ontvangen adviseer ik hetzelfde, echter is het iets minder van belang.
Let op: MX-records kunnen rustig naar iets anders dan pietje.domain.com verwijzen, zolang de A-records van de hosts waar ze naar verwijzen maar IP 10.0.0.5 hebben.
IP/servernaam/domeinnaam zijn uiteraard enkel voorbeelden.
Tools die handig zjn voor ISPs vind je natuurlijk bij Tools 4 ISP.
04/01/11 15:57
Maar voor versturen dus wel.
Ja precies, dat doe ik met de mailserver van thuis inderdaad ook.
Oke tot zover bedankt voor de uitleg. Het was me natuurlijk bekend wat een FQDN was.
Alleen de combinatie tussen ehlo/helo en mx adres zat me niet lekker.
Normaliter zorg ik zelf altijd dat dit overeen komt met het a record van de mailserver.
Maar ik kwam nu een voorbeeld tegen waar je met een drietal domeinnen te maken hebt en dus zag ik evendoor de bomen het bos niet meer.
Ik ga dat praktijk voorbeeld erbij nemen.
Er komt een hoop mail niet aan bij Telfort. Mijn vermoeden was dat die controle uitvoeren op ehlo/helo en PTR. Maar misschien is er toch een andere storing aan de hand.
Domein: computeridee.nl xx.xx.xx.53
Daarop draait een vbulletin forum (-f parameter actief) wat uiteraard mail naar gebruikers stuurt zoals notificaties van antwoorden, net als hier. Het forum heeft een ander ip dan de domeinnaam namelijk xx.xx.xx.51. (eerste deel is hetzelfde).
Deze wordt verzonden als volgt:
[83.219.86.51] (helo=php.hub.fastxs.net). Dit ehlo/helo ip resolved naar services.hub.nl
Dat klopt dus niet volgens de RFC? Resolved niet naar fastxs.net en niet naar computeridee.nl.
Er is geen MX adres wat naar dat 51 ip verwijst.
Dus wel voor het verzenden dan.In principe heb je voor het ontvangen van email geen MX record nodig
Maar hoe wordt dit dan gecontroleerd als de helo naam niet naar het MX A record hoeft te verwijzen?
Dus abuseat zit ernaast door dit te stellen?
http://cbl.abuseat.org/helocheck.htmlIt should be the fully qualified domain name for your mail server or an IP address enclosed in square brackets.
Ik zou anders geen reden weten waarom alleen de mail van dat forum niet bij Telfort email adressen aan komt. Volgens mij doen die een helo of ptr check of zoiets.
04/01/11 17:17
Voor het versturen van de email heb je ook geen MX nodig. Dit had ik ook genoemd.
ja - advies en beheer: Hosting in de cloud - the next big thing!
04/01/11 17:19
Ja nu begrijp ik het helemaal niet meer. Dus voor het versturen heb je geen MX record nodig en voor het ontvangen ook niet. Waarom dan wel nog?Voor het versturen van de email heb je ook geen MX nodig.
Ik ga die RFC ook nog maar eens opnieuw lezen. Maar genoemd probleem met mail ontvangst als boven omschreven bestaat nog steeds.
Quote