Onderwerp: Helo name en mx records

Als je het NETJES wilt doen:

Versturen: De HELO dient een FQDN te zijn welke overeenkomt met de reverse DNS van het IP (verder geen MX records nodig), de reverse DNS dient weer te resolven naar het A record van de server.

Ontvangen: Er dienen MX records te zijn welke verwijzen naar de mailserver. Zijn die er niet, dan zullen de servers die conform de RFC werken proberen af te leveren op het A record van de domeinnaam.

Kijk dan had ik het toch goed voor.
Want ik ga er van uit dat je het netjes wilt doen, althans ik zelf wel als het even kan.
Alleen dacht ik dat "netjes doen", hetzelfde was als werken conform de RFC, maar in dit geval is dus een MX record niet verplicht volgens RFC maar is wel netjes om te gebruiken.
So far so good. Thanks, dat is wat ik horen wilde.

Alleen zat ik dan scheef in mijn gedachte dat de helo ook naar de mailserver fqdn moest verwijzen, maar Abuseat heeft dat ook fout dus daar hoef ik me niet voor te schamen.

Enig idee met mijn genoemde voorbeeld, waarom de mail niet aan komt?
Zou dat dan toch een probleem bij Telfort zijn? Of misschien toch sprake van een blokkade omdat de reverse van de genoemde helo uit komt op een andere hostnaam/domeinnaam?

Wat is de exacte weigering van Telfort? Wijzig je HELO eens in services.hub.nl ?

Ik ben niet van fastxs.net dus ik kan niets wijzigen en de weigering van Telfort kan ik ook niet zien.

Ik heb alleen net als een aantal anderen Telfort adsl en wij krijgen van dat forum geen mail binnen, vandaar dat ik even in de headers van de mail heb gekregen, die het forum schijnbaar wel naar andere email adressen gezonden krijgt.
En toen met dig even de mx adressen opgezocht en de ip's nagekeken.

En daarbij viel me dus ook op dat het helo ip naar een andere hostnaam resolved hetgeen me op het idee bracht dat dit wel eens de oorzaak van het niet aankomen kon zijn.
Als dat het geval is dan zal CID contact moeten opnemen met fastxs en als dat niet het geval is dan moeten we eens bij Telfort gaan vragen waarom er mail geweigerd wordt.

Om het heel simpel te stellen,

mail wordt verstuurt naar mx1 of mx2 .domein .nl gebaseerd op de volgorde die je MX aangeeft. daar gebruik je dus MX voor.

Echter als er door een fout (laten we het even zo noemen) geen mx bestaat dan is er een falback naar het A reccord. - mx is dus enkel van belang om bij het ontvangen de volgorde van mailservers aan te geven. aan te raden is toch wel MX te gebruiken ook als je maar 1 mailserver hebt.


verder zou ik dit vooral neerleggen bij je hoster, zijn in principe verantwoordelijk voor de correcte server instellingen (neem ik aan???) - maar een belletje naar je provider (als klant dus niet als vertegenwordiger van de site) kan ook wel eens heel informatief zijn, meestal ook veel informatiever dan wanneer je uit naam an de site oid zou bellen (als je die autoriteit daar hebt tenminste).

verder zou ik dit vooral neerleggen bij je hoster, zijn in principe verantwoordelijk voor de correcte server instellingen (neem ik aan???)

Mijn ISP Telfort eerder. Want zoals ik schreef probeerde ik alleen er achter te komen waardoor het euvel veroorzaakt werd.

Vandaar dat ik graag wilde weten of het kan dat deze helo reverse niet klopt en op grond daarvan mail geweigerd kan worden door ontvangende mailserver.

Maar ik heb verder niets ermee te maken behalve dan dat ik zelf ook Telfort adsl heb en die mails ook niet krijg.
Ik zal betreffend forum adviseren bij hun hosting partij te rade te gaan om te vragen of ze een reject reason kunnen ontdekken.
En zelf zal ik bij Telfort even gaan vragen of zij kunnen onderzoeken wat er met die mails gebeurt.

Oorspronkelijk geplaatst door ichat

Om het heel simpel te stellen,

mail wordt verstuurt naar mx1 of mx2 .domein .nl gebaseerd op de volgorde die je MX aangeeft. daar gebruik je dus MX voor.

Echter als er door een fout (laten we het even zo noemen) geen mx bestaat dan is er een falback naar het A reccord. - mx is dus enkel van belang om bij het ontvangen de volgorde van mailservers aan te geven. aan te raden is toch wel MX te gebruiken ook als je maar 1 mailserver hebt.


verder zou ik dit vooral neerleggen bij je hoster, zijn in principe verantwoordelijk voor de correcte server instellingen (neem ik aan???) - maar een belletje naar je provider (als klant dus niet als vertegenwordiger van de site) kan ook wel eens heel informatief zijn, meestal ook veel informatiever dan wanneer je uit naam an de site oid zou bellen (als je die autoriteit daar hebt tenminste).

Het niet definieren van een MX record noem ik niet direct een fout, omdat in de RFC duidelijk vermeld staat dat een A record ten alle tijden gebruikt kan en zal worden op het moment dat dat niet present is.

Denk sowieso dat een MX record in deze context (hoop nieuwe dingen gelezen hier die er toch iets dieper op ingaan, waarvoor dank) eigenlijk gebruikt kan en mag worden voor het definieren van prioriteit op de mailserver.

Ik kan nu compleet de plank misslaan, maar volgens mij zit ik toch wel een beetje in de richting zo.

Denk sowieso dat een MX record in deze context eigenlijk gebruikt kan en mag worden voor het definieren van prioriteit op de mailserver.

Hoe bedoel je "prioriteit op de mailserver"?

Of bedoel je "prioriteit van mailserver"? In het laatste geval klopt dat want je geeft door de cijfers van de mx aan welke volgorde er genomen moet worden, laagste cijfer eerst.

Oorspronkelijk geplaatst door Blacky

Hoe bedoel je "prioriteit op de mailserver"?

Of bedoel je "prioriteit van mailserver"? In het laatste geval klopt dat want je geeft door de cijfers van de mx aan welke volgorde er genomen moet worden, laagste cijfer eerst.

Dat bedoelde ik inderdaad.

Oorspronkelijk geplaatst door T. Verhaeg

Het niet definieren van een MX record noem ik niet direct een fout, omdat in de RFC duidelijk vermeld staat dat een A record ten alle tijden gebruikt kan en zal worden op het moment dat dat niet present is.

Denk sowieso dat een MX record in deze context (hoop nieuwe dingen gelezen hier die er toch iets dieper op ingaan, waarvoor dank) eigenlijk gebruikt kan en mag worden voor het definieren van prioriteit op de mailserver.

Ik kan nu compleet de plank misslaan, maar volgens mij zit ik toch wel een beetje in de richting zo.

Ja en nee, je mag er niet vanuit gaan dat ieder ip gebruikt wordt voor de smtp server. Als je website (A record) naar xx.xx.xx.20 verwijst omdat hier iis/apache/... op draaid maar smtp bvb op xx.xx.xx.15 dan moet je nogaltijd een MX record gebruiken. Zelfs al staan deze ip adressen op dezelfde fysieke server ingesteld. Dus de rfc regel telt alleen maar als je domein.tld verwijst naar het ip waar de smtp server op draaid.

Staar je trouwens ook niet blind op de prioriteit want spammers gebruiken ze bvb allemaal of die met de laagste rang (hoogste nr).

Oorspronkelijk geplaatst door The-BosS

Ja en nee, je mag er niet vanuit gaan dat ieder ip gebruikt wordt voor de smtp server. Als je website (A record) naar xx.xx.xx.20 verwijst omdat hier iis/apache/... op draaid maar smtp bvb op xx.xx.xx.15 dan moet je nogaltijd een MX record gebruiken. Zelfs al staan deze ip adressen op dezelfde fysieke server ingesteld. Dus de rfc regel telt alleen maar als je domein.tld verwijst naar het ip waar de smtp server op draaid.

Staar je trouwens ook niet blind op de prioriteit want spammers gebruiken ze bvb allemaal of die met de laagste rang (hoogste nr).

Jep, heb je absoluut gelijk in, maar op het moment dat alles op een bak draait (of dat goed is laat ik even in het midden) kan het wel.

Oorspronkelijk geplaatst door T. Verhaeg

Jep, heb je absoluut gelijk in, maar op het moment dat alles op een bak draait (of dat goed is laat ik even in het midden) kan het wel.

Als je webserver en smtp server en ... allemaal hetzelfde ip adres gebruiken en je A record daar naar verwijst wel. Of het goed is of niet laat ik in het midden, maar dit wordt nogal eens over het hoofd gezien als je op een webcluster staat die enkel doet wat hij moet doen.

Oorspronkelijk geplaatst door T. Verhaeg

Het niet definieren van een MX record noem ik niet direct een fout, omdat in de RFC duidelijk vermeld staat dat een A record ten alle tijden gebruikt kan en zal worden op het moment dat dat niet present is.

Ik dacht met de opmerking (tussen haakjes) erachter, wel duidelijk te hebben, dat het 'fout' in werkelijkheid iets genuanceerder is, maar dat ik omwille van duidelijkheid die nuance niet heb gemaakt.
Toch wil ik nog wel even aangeven waarom ik het een 'fout' vindt, Ik zou het namelijk willen vergelijken met iet triviaals als 'zwijgen is toestemmen' Je weet nooit helemaal zeker of iemand nu toestemt, of niet weet hoe te protesteren, of dat men wellicht simpelweg de vraag niet heeft begrepen.
Kortom onduidelijkheid alom, en slechts een kwestie van gemakzucht om dan maar aan te nemen dat er toegestemd is.

Tot zover mijn argument om het in vereenvoudigde vorm dan maar als 'fout' te omschrijven.

Ik dacht met de opmerking (tussen haakjes) erachter, wel duidelijk te hebben, dat het 'fout' in werkelijkheid iets genuanceerder is, maar dat ik omwille van duidelijkheid die nuance niet heb gemaakt.

Ik heb het ook als zodanig opgevat, vond het wel handig omschreven op die wijze in elk geval. Waarvoor trouwens nog dank voor de uitleg.
Er zijn natuurlijk meerdere mogeijkheden. Ik weet ook niet of het zin zou hebben in het kader van anti-spam of beveiliging, maar anders was het wellicht goed om een MX record verplicht te stellen.
Doch zoals gezegd, ik weet niet of dat ook echt nut zou gaan hebben.

Om nog even terug te komen op het probleem van de TS: veel mailservers controleren of forward en reverse DNS met elkaar kloppen. De betreffende mailserver heeft een reverse waar geen forward DNS entry bij hoort:

- php.hub.fastxs.net heeft een A-record naar 83.219.86.51
- 83.219.86.51 heeft een PTR-record naar services.hub.nl
- services.hub.nl heeft een A-record naar 62.177.169.82, en geen A-record naar 83.219.86.51

Hierop kan de mailserver concluderen dat de reverse DNS-entry niet klopt wegens het ontbreken van een bijbehorende forward DNS-entry. Ik weet niet zeker of dit in strijd is met een RFC, maar het kan heel goed de reden zijn dat de e-mail geweigerd wordt. Spammers gebruiken vaak slordig opgezette mailplatformen en het streng controleren hierop houdt veel spam buiten de deur.

MX-records zijn alleen maar bedoeld om makkelijk aan te kunnen geven op welke server e-mail voor een bepaald (sub)domein kan worden aangeboden en hebben hier dus niets mee te maken.