eTel und PTR Eintrag

[penguinforce]

dann wird der Remote SMTP keine EHLO/HELO durchführen (oder doch?!)

um es kurz zu sagen: oder doch?!.

forward dns, reverse dns und helo sollten immer übereinstimmen (diese dinge werden - meist in kombination - miteinander gegengeprüft), sonst ist deine ip schneller auf einer black-/block-liste, als du "ich kann doch einen mailserver konfigurieren" sagen kannst; einige server gehen sogar soweit, die domain zu prüfen (ob der mx-eintrag mit den daten des verwendeten smtp-servers ident ist (nein, ich meine nicht spf und konsorten, die aber im härtefall auch noch dazukommen)).

zu deiner (selbsternannten) wortklauberei: ich würde bei einem open-relay nicht sagen, dass dieser die mails empfängt (da er ja nicht das eigentliche ziel ist), sondern sie (unerlaubterweise) überträgt, daher ist der terminus empfangen hier eher fehl am platz (und dürfte zu den getätigten postings geführt haben) → aber das jetzt wäre wortklauberei...

just my 2¢



[sub][edit]:typos ausgebessert... *g*[/sub]

[al]

Versende ich Mails von meinem SMTP Server aus dann wird der Remote SMTP keine EHLO/HELO durchführen (oder doch?!).

Für mich ist grad nicht nachvollziehbar, was Du da meinst... Verstendest Du Mails, dann sagst Du HELO und der empfangende Host denkt sich halt seinen Teil zu dem, was Du da behauptest. (oder sprichst Du von callouts?)

Zum PTR eines outgoing Mailrelays ist zu sagen:
- daß er gesetzt sein sollte
- daß er auch konsistent gesetzt sein sollte (sprich der A auch wieder auf die IP auflöst)
- daß er nicht-generisch ausschauen sollte

Und weiterhin kamma einen SPF Record setzen und die IP bei dnswl.org eintragen, Dinge, die ggf. die Wahrscheinlichkeit, daß Mails auch angenommen werden, erhöhen, und die man halt mit einer dyn. IP nicht machen kann.

Was jetzt den Inhalt seines HELO angeht, so erhöht es in Meng Wong-nahen Implementierungen (SPF, karmaspere) natürlich auch die Akzeptanz, nicht zu lügen.

/al

[divB]

@penguinforce: D.h. angenommen ich schick ein Mail weg dann verbindet sich der remote SMTP zu mir zurück, macht ein HELO und checkt ob das mit dem PTR übereinstimmt? Würd ich krank finden, aber fürs Empfangen werd ich sowieso PTR, A und HELO-String gleich setzen.
Zur Wortklauberei: Das kommt eben auf die Abstraktionsebene an. Beim "relayen" empfängt der SMTP Server eben zuerst und versendet sie dann wieder (auch auf Ebene des SMTP Protokolls!). Etwas höher abstrahiert ist es dann eben eine Übertragung.
Auf alle Fälle musst du verstehen dass ich mich gegen die Unterstellungen einfach wehren musste.

@al: Ich meine ja genau das eben besprochene: Soweit ich weiss sage eben ICH helo zum Remote Host. D.h. der Remotehost wird bestenfalls den String den ICH mit HELO mitschicke mit dem PTR Eintrag vergleichen können...

Was meinst du damit, dass der PTR "nicht-generisch ausschauen sollte"?

[lordpeng]

mir entgeht jetzt grade der sinn an der sache, in dem fall wärs wohl das einfachere über einen smarthost zu relayen, bzw. wie gedenkst du mails zu empfangen? wenn du über diesen server nur versenden willst über einen sekundären mx?

[divB]

Nein, natürlich empfange ich vorrangig, für meine eigenen Domains. Würd aber auch gern darüber Senden (was eben bis jetzt nur über Smarthost ging).

Und, ok, nachdem das ganze sehr verwirrend ist, erkläre ich noch einmal wieso ich was geschrieben habe:

1.) Es war davon die Rede, endlich keinen Smarthost mehr verwenden zu müssen. Also SENDEN von Mails per SMTP. Senden eben, nicht empfangen.
2.) Dann hast du gesagt "ja, wenn der MTA richtig konfiguriert ist". Bemerkung: Es geht noch immer ums SENDEN.
3.) Daraufhin hab ich gefragt was man dafür am MTA konfigurieren muss. Eben fürs VERSENDEN (was ich noch extra in Asteriske eingeschlossen hab). Mir ist da eben nichts eingefallen.
4.) Dann hast du geantwortet dass man bei der MTA Konfiguration viel falsch machen kann. Das ist mir genauso bewusst wie korrekt, jedoch gilt das für den Empfang (um eben kein OpenRelay werden zu können).
5.) Dann hab ich noch einmal drauf hingewiesen dass ich vom Versenden gesprochen habe und nicht vom Empfangen (und das sogar noch mit einem Ironie-Smiley verziert). Bem: Der Empfang ist längst korrekt und sicher konfiguriert.
6.) Sodann ging ein Flamewar los in dem mir unterstellt wurde ich könne meinen MTA nicht konfigurieren (obwohl es keinen Hinweis darauf gibt, denn vom Empfangen hab ich ja nie gesprochen)

Ich hoff es ist nun klarer was ich gemeint hab. Und hiermit ist es eigentlich auch egal, oder?

Danke jedenfalls für deine zahlreichen Hinweise und alle andren die produktiv geantwortet haben

lg,
divB

[lordpeng]

auf deutsch, versenden willst du selber und empfangen über den pop deines providers - oder? das ist zwar eine an sich laufende konfiguration, aber aktuelle spamfilter methoden werden dir da unter umständen ins handwerk spucken ...

ich würde das ganze entweder komplett auslagern (senden und empfangen übern mailserver des providers) oder es komplett selber machen, mit eventuellem backup mx beim provider oder sonst wo ...

[divB]

Nein, nein, ich will auch empfangen (nur in den Erklärungen oben gings mir darum klarzustellen dass ich davon nicht gesprochen hab ).

Ich würds wie gesagt gerne komplett selbst machen. Empfangen funktioniert ja bereits gut (auch einige Jahre mit dyn-ip). Backup-MX hab ich bei Rollernet.us - is aber nicht so gut; wenig Speicher und nur 2 Tage Vorhaltezeit.

Kennt bei der Gelegenheit vielleicht jemand einen Gratisanbieter für Backup MX?

[lordpeng]

>Kennt bei der Gelegenheit vielleicht jemand einen Gratisanbieter für Backup MX?
gratis kenn ich keinen, aber ein heisser tipp is meist $dein_provider, je nachdem wie wichtig/vertraulich die mails sind, würd ich mich auch auf einen gratisanbieter der im falle eines verlusts nicht zur verantwortung gezogen werden kann, auch nicht verlassen wollen, da verlass ich mich lieber auf die zuverlässigkeit meiner hardware und meiner anbindung ...

[divB]

Naja, Situation ist halt dass das alles privat für mich selbst is und ich das ganze nur rein aus Spass an der Freude mache

Deswegen spielen die Kosten in erster Linie eine Rolle (die größte Problematik sind da z.Z. die Stromkosten; da rennen 250W rund um die Uhr...dabei tät ich gern noch so viel mehr rennen lassen...)

Deswegen kann ich sicher kein "professionelles" Service in Anspruch nehmen. Einen kleinen Betrag wär ich dafür aber durchaus bereit zu zahlen.

Prodiver ist - jetzt neu - eTel. Bieten die sowas; weiss das wer? Eben für privatzugänge und für das oben beschriebene Szenario erschwinglich?

[al]

Nein, nein, ich will auch empfangen
...
Kennt bei der Gelegenheit vielleicht jemand einen Gratisanbieter für Backup MX?

Für's Empfangen ist Dein rDNS aber reichlich uninteressant...

Und ad Backup-MX: wozu? Im Zeitalter der always-on DSLs.

/al

[divB]

@Empfangen: Endlich versteht mich einer
@Backup-MX: Naja, damit die Mails sicher alle ankommen. Und weisst es wie das mit "always-on" DSL so ist.
Weiters bin ich im Herbst für 3 Wochen nicht da und da kann bald einmal was ausfallen. Dann wärs auch schön wenn die Mails nicht im Nirvana verschwinden würden

[divB]

Hallo,

Ich hab heute ein Mail geschrieben und nach ein paar Minuten kam die Antwort dass es eingetragen ist. Aber nichts läuft so richtig, alle Tests im Internet sagen mir dass kein Reverse Eintrag existiert, dnswl hat mir den Eintrag verweigert. "host" liefert immer ein "not found", nslookup sowie dig liefern komische Ergebnisse die ich bei keiner andren IP beobachten konnte.

Was nämlich krank ist: Bei von mir getesten IPs bekomme ich als Antwort einen "IN PTR" Eintrag, z.B. für google:

Code: Alles auswählen

$ dig -x 209.85.135.104
; <<>> DiG 9.3.2 <<>> -x 209.85.135.104
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18536
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;104.135.85.209.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
104.135.85.209.in-addr.arpa. 79720 IN   PTR     mu-in-f104.google.com.

;; AUTHORITY SECTION:
135.85.209.in-addr.arpa. 70748  IN      NS      ns4.google.com.
135.85.209.in-addr.arpa. 70748  IN      NS      ns1.google.com.
135.85.209.in-addr.arpa. 70748  IN      NS      ns2.google.com.
135.85.209.in-addr.arpa. 70748  IN      NS      ns3.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         329751  IN      A       216.239.32.10
ns2.google.com.         329751  IN      A       216.239.34.10
ns3.google.com.         329751  IN      A       216.239.36.10
ns4.google.com.         329751  IN      A       216.239.38.10


Bei mir jedoch bekomme ich zwar eine Antwort ABER es ist ein CNAME Ergebnis! Wie ist das möglich? Das kann doch nicht korrekt sein oder?

Code: Alles auswählen

$ dig -x 193.154.229.55

; <<>> DiG 9.3.2 <<>> -x 193.154.229.55
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61098
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;55.229.154.193.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
55.229.154.193.in-addr.arpa. 80742 IN   CNAME   intra.nobaq.net.

;; AUTHORITY SECTION:
nobaq.net.              1542    IN      SOA     ns1.nobaq.net. admin.nobaq.net. 2007092404 43200 7200 604800 1800


Anstt CNAME müsste doch hier PTR stehen oder?

Kann das jemand erklären?

Danke im Vorraus,
divB


EDIT: Ich habs jetzt grad mit meinen lokalen Bind probiert - das Verhalten bekomme ich, wenn ich in einer Reverse-Zone tatsächlich ein CNAME statt ein PTR einbau.
Aber ist dies überhaupt erlaubt? Laut Wikipedia dürfen in so einer Zone nur PTR-Records erlaubt sein!
Wie bringe ich eTel dann dazu, mir einen gscheiten *PTR* zu setzen?

[lordpeng]

>Laut Wikipedia dürfen in so einer Zone nur PTR-Records erlaubt sein!
auch wenn wikipedia bei technischen artikeln recht zuverlässig ist, würd ich für solche belange eher in den RFC's als in wikipedia nachschlagen

>Wie bringe ich eTel dann dazu, mir einen gscheiten *PTR* zu setzen?
einfach nochmal ein mail schicken wär vielleicht das einfachste ...

btw

C:\WINDOWS\system32>nslookup
Standardserver: ns1.ycn.com
Address: 212.88.160.2

> set type=ptr
> 193.154.229.55
Server: ns1.ycn.com
Address: 212.88.160.2

Nicht autorisierte Antwort:
55.229.154.193.in-addr.arpa canonical name = intra.nobaq.net

nobaq.net
primary name server = ns1.nobaq.net
responsible mail addr = niki.nobaq.net
serial = 2007092404
refresh = 43200 (12 hours)
retry = 7200 (2 hours)
expire = 604800 (7 days)
default TTL = 1800 (30 mins)
>

[divB]

Weisst du obs nun erlaubt ist? (google suchen brachten mich nicht weiter)

Zum nochmaligen schicken: Hmm, was soll ich der Sandra (deren Domainadmin, die hat mir zumindest die Antwort gegeben) dann schreiben? Dass der Eintrag falsch ist oder dass ich gerne einen echten PTR hätte?

Was willst du mir mit dem "btw"+nslookup Ausgabe sagen? Dass der Eintrag passt oder eben nicht passt? Ich bekomme da das gleiche Ergebnis.

Hast du einen "echten" PTR bekommen?

lg,
divB

[penguinforce]

Code: Alles auswählen

[22:10] (~)$ host -t ptr 193.154.229.55
55.229.154.193.in-addr.arpa domain name pointer intra.nobaq.net.

noch mehr ptr geht nimmer...