Kein Hostname/IP bei Emailübertragung

Styx

Universaldilettant
Hallo Leute,
ich habe ein Problem mit unserem Router in der Firma, der mit FreeBSD 6.2 betrieben wird. Die Kiste tut brav ihren Dienst und alles ist soweit suppi.

Allerdings habe ich festgestellt, dass wenn wir Emails raus schicken, interessanterweise nicht die IP des Routers sondern die interne IP oder auch der interne Hostname des jeweiligen Rechners, von dem die Email geschickt wird, weiter geleitet wird. Das ist zwar an sich kein Problem, führt aber gelegentlich dazu, dass Mails in Spam-Ordnern landen, da die Verschleierung des echten Ursprungs ja eine beliebte Spammermethode ist. Die Mails werden übrigens über einen externen pop/smtp-Server geschickt. Das Mailsystem läuft also nicht über den Router.

Nun die Frage: Woran könnte das liegen? Der Router verfügt über einen DNS-Cache, der auch gut funktioniert und vor langer Zeit mal nach der Anleitung im Wiki zusammen gebastelt wurde. Jemand irgendeine Idee?
 

Kamikaze

Warrior of Sunlight
Die IP und der Hostname wird normalerweise gar nicht übermittelt. Das heißt, die Daten werden direkt vom Email Client im Header eingetragen.
 

Styx

Universaldilettant
Stimmt. Ich habe gerade nochmal nachgeschaut, ist natürlich unsinn. Es geht um die Headerinfos, die in diesem Fall nicht korrekt übermittelt bzw. versteckt werden:

Received: from ss6.xxxxxxx.net (ss6.xxxxxxxx.net [85.xxx.xxx.xxx]) by mail1.xxxx.com with ESMTP; Wed, 14 Mar 2007 01:28:08 -0700

Received: from [192.168.1.180] (i59F7E3B3.xxxxxxx.de [89.xxx.xxx.xxx])
(authenticated bits=0)
by ss6.xxxxxxxx.net (8.13.7/8.13.7) with ESMTP id l2E8FIWa016015;

Die Frage ist, ob ein Hostname an der Stelle was ändern würde, denn wie gesagt, auch bei den internen hostnames gibt es offensichtlich diese Probleme.

Edit:
Oder kann das auch am Emailanbieter liegen?
 
Zuletzt bearbeitet:

max93

Well-Known Member
Hallo!

Wenn der Client zum Server mit der IP 89.x.x.x eine nicht ge-NAT-ete Verbindung hat, dann sieht das alles gut aus und dann gehört das auch so.

HTH & Ciao.
Markus Mann
];-)
 

Styx

Universaldilettant
Und warum gab es dann Beschwerden von Firmen, dass die Mails wegen genau dieser Sache im Spamfilter landen? NAT verwende ich nicht.
 

mapet

Active OpenBSD User
weil das eine interne ip ist, die im internet nix zu suchen hat. du solltest daher zumindest den smtp-port ins nat einbeziehen, damit der smtp-server da deine externe ip-adresse reinschreibt. warum die allerdings so superpingelig filtern, bleibt wohl ihnen überlassen. bei unseren ausgehenden mails steht als erstes auch der interne domino mit seiner internen adresse drin, der das dem mailgateway abliefert.

hth,
marc
 

Styx

Universaldilettant
du solltest daher zumindest den smtp-port ins nat einbeziehen, damit der smtp-server da deine externe ip-adresse reinschreibt.

Ich muss dafür extra NAT einrichten? Und vor allem von wo nach wo soll es denn leiten? Es gibt ja nun mehr als einen Rechner und nochmal: Der Mailserver ist extern.

warum die allerdings so superpingelig filtern, bleibt wohl ihnen überlassen.

Angeblich Spamabwehr...
 

mapet

Active OpenBSD User
also mit pf machst du das mit einer zeile (das beispiel hier gilt für alle verbindungen von intern -> extern):

nat on $ext_if from $int_if:network to any -> ($ext_if)

da soll nix geleitet werden. NAT bedeutet lediglich Network Address Translation, also in dem falle "übersetze auf dem externen anschluss alles, was vom internen interface aus dem internen netz kommt und irgendwo hingehen soll auf die externe adresse". dadurch bekommen dann die externen geräte nur die adresse deines routers mitgeteilt und dein problem sollte sich erledigt haben.

hth,
marc
 

Styx

Universaldilettant
Na gut, dann werde ich mal schauen. Ich nutze derzeit IPFW2, allerdings habe ich schon länger überlegt umzusteigen, was vielleicht ein guter Zeitpunkt wäre.
 
R

rosa

Guest
Sorry Jungs, aber mit Nat ist jetzt nen schlechter Scherz oder und was hat das ganze mit einem Port zu tun?
Und wenn IPFW sauber rennt, warum dann auf PF umsteigen?

Mal abgesehen davon das Envelop-Mail-Header mit localen IPs ganz normal sind und daran nichts auszusetzen gibt, denn schliesslich ist das nur ein Punkt von eventuell vielen des Mail-Routings, was eben auch aus einem anderen Netz nicht gleich dem des Internets sein kann, kann man das ändern in dem man diese vom MTA überschreiben lässt. Alle MTAs die ich kenne können das.

Was man tunlichst unterlassen sollte ist die letze Ausstellung der Maila an "fremde" MTAs von DynIPs die nicht vernünftig aufgelöst werden.
Was aber wieder ein andere Punkt ist.
 

mapet

Active OpenBSD User
hi rosa, so wie ich das verstanden habe, ist der MTA nicht unter seine kontrolle und andere beschweren sich, dass da mal ne lokale ip im header auftaucht und filtern das dann (warum auch immer). wenn er nun NAT aktiviert, bekommt der mailserver eben nicht die lokale ip angezeigt, sondern die externe ip und alle sind zufrieden und können sich wieder hinlegen :)
 
R

rosa

Guest
Ich weiss nicht wieso man an hand eines Headereintrages von wo die Mail mal irgend wann kamm filtern sollte. Dann würde ja alle meine Mails und die der Firma hier wegfallen.

Nat ist ne Krücke, und keine Lösung ;-)
Im Übriegen kann IPFW2 auch intern Nat ;-)

Aber am ende bleib ich dabei, das soll ein MTA überschreiben wenn es dann sein soll, wes aber unfug ist.
 

CommanderZed

OpenBSD User
Teammitglied
Hallo

genau dieses "fehlerhafte" Filterverhalten hat uns neulich auch viel zeit gekostet - anscheinend filtern einige Provider inwzwischen tatsächlich auf _alle_ Header-Addressen - logisch das die "erste" dann die Dynamische IP ist, von der man es gesendet hat.

Das Problem liegt damit ganz allein beim fehlerhaft filternden Empfänger!
 

mapet

Active OpenBSD User
ernsthaft? wer sind denn solche spezialisten, damit ich meine user mal vorwarnen oder zu einem providerwechsel raten kann, falls mal solche probleme auftauchen sollten?
 

mapet

Active OpenBSD User
ich stimme dir da zu rosa, und ich habe auch nicht gesagt, er solle den paketfilter wechseln ;). mein interner notes spricht mit dem mailgateway ja auch von seiner internen ip aus, und ich hab auch nicht vor, das in irgendeiner weise zu ändern, weil sich irgendwelche findigen "it-pros" wieder irgendnen blödsinn mit den headern ausgedacht haben...
 
Oben