Verständnisfrage: Client-IP im eMail-Header

V

VisualBeo

New Member
Hallo liebe Community,

ich bin ein wenig irritiert darüber, dass sich per eMail-Header nachvollziehen lässt, von welchem Client-PC (IP-Adresse) ich eine Mail per SMTP über einen Mailserver verschicke. Zum Beispiel:

Code: 
Received: [COLOR="Red"]from XXXX.dip.t-dialin.net (HELO corsair) (t-com@[127.0.0.1])[/COLOR]          (envelope-sender <XXX@t-netbox.de>)
          by 10.XXX.18.141 (qmail-ldap-1.03) with AES128-SHA encrypted SMTP
          for <XXX@XXX>; 14 Aug 2010 15:00:07 -0000

Mein Problem dabei: Ich bekomme von meinem ISP eine dynamische IP zugewiesen, die der Server des Empfängers dann evtl. als Spam aussortiert oder sogar blockt, weil dynamische IP-Ranges entweder komplett auf Blacklists landen oder ich die IP eines früheren Spammers zugewiesen bekomme.
Desweiteren verhindern manche Blacklists sogar, dass ich als Client selber Mails über *meinen* Server verschickt. Arghs.

Welche Tricks kann ich verwenden, um per eMail-Client (Outlook, usw) weiterhin mails zu versenden, ohne das meine dyn-IP mitgesendet wird?
Spontan würde mir nur VPN einfallen, was natürlich zusätzlichen techn. Aufwand bedeutet.

Danke für Antworten und einen schönen Sonntag. Chris
 
Warum verwendest Du Blacklists welche Dial-Ups gelistet haben?
Willst Du keine Mails von geschätzten 90% Deiner User bekommen?
Wirf die "dummen" Blacklists raus und gut. Und wenn Deine Mails woanders geblockt werden, dann wende Dich an den dortigen Postmaster und lass Dich whitelisten.
 
Bei Postfix in der /etc/postfix/header_checks:
Code: 
# Mask local Received Lines
/^Received:/    IGNORE
Dann ist Dein Border-Gateway der erste Eintrag und der läßt sich gut automatisiert auf Blacklist-Einträge überwachen.
 
Das komplette Entfernen der ClientIP-Zeile wuerde ich nicht empfehlen da es fast unmoeglich macht bei Abuses raus zu finden von wo es kommt.
 
@Joe User:
False. Der Grund, warum diese Situation nie eintritt ist ein ganz einfacher:
Der User sendet seine Mail ja über einen E-Mail-Server mit statischer IP. Dieser Mailserver liefert die Mail dann beim Zielsystem ein.
Das Zielsystem macht nun meinetwegen einen RBL-Check. Und welche IP wird abgefragt? Natürlich nur die, des einliefernden Systems - also die statische IP des Mailservers.
Mehr weiß das Zielsystem zu dem Zeitpunkt auch garnicht, da RBL-Checks normalerweise durchgeführt werden, bevor auch nur ein Byte der E-Mail übertragen wird und damit noch keine Header aus der Mail ausgewertet werden können ;)
 
Das heißt also, @Lord Gurke, dass beim Übertragen einer eMail von Mailserver zu Mailserver nie die IP des Client-PCs geprüft wird per rbl? Gut zu wissen.

Aber Spamassassin macht das dann anschließend, nehme ich an?
 
@Lord Gurke
Dumm nur, dass der OP selbst schon die Mails seiner User beim Einliefern bei ihm durch ungeeignete RBLs jagt und somit TRUE.
 
@Joe User: halb so schlimm, ich bin der einzige User, der auf dem Server eMail-Dienste in Anspruch nimmt.

Ich hatte mich nur gewundert, dass ein Mailclient, der sich für das Versenden einer Mail (SMTP) mit Benutzer/Passwort anmeldet, dann noch geblockt wird.

Da steige ich in dieser seltsamen postfix-configfile (main.cf) nicht ganz durch, weil dort irgendwie kein Unterschied zwischen (a) Clients gemacht wird, die eMails versenden wollen und sich dazu anmelden, und (b) anderen Servern, die Mails übermitteln wollen.

Naja, ich benutze leider einen VServer mit Ubuntu und Plesk, und Plesk macht da schon die verrücktesten Sachen. Wenn ich unter Plesk RLBs eintrage, nimmt er folgende Reihenfolge:

Code: 
smtpd_client_restrictions = 
  permit_mynetworks,
  reject_rbl_client (mehrere RBL), 
  permit_sasl_authenticated,
  reject_invalid_hostname

Dann gibt es Probleme beim Versenden von Mails mit Email-Client per SMPT. Sobald ich das permit_sasl_authenticated über die RBL setze, klappt es wieder.

Jedenfalls ist mir nicht ganz klar, wieso angemeldete Clients ("Der Postausgangsserver erfordert Authentifizierung") noch irgendwelche Blacklists durchlaufen müssen.
 
Sobald eine Regel matched wird die folgende afaik nicht mehr bearbeitet.
Sollte der Absender also in mynetwork sein, wird keine der nachfolgenden Regeln durchgearbeitet.

Dies erklaert auch warum permit_sasl vor reject_rbl liegen muss; die Blocklists sperren oft dynamische IP's als Absender da diese in 99.9% der Faelle kein gewuenschter Mailserver sondern Spambots sind.
Somit kann die Kontrolle ob der Benutzer eingeloggt ist nie durchgefuehrt werden; die Email wird abgewiesen.
In der anderen Reihenfolge kommt sasl nie zum Zug da der Benutzer als eingeloggt und somit vertrauenswuertig erkannt wird.
 
Joe User said:
@Lord Gurke
Dumm nur, dass der OP selbst schon die Mails seiner User beim Einliefern bei ihm durch ungeeignete RBLs jagt und somit TRUE.
Click to expand...
Aber FALSE, weil die IP, die in den Received-Headern der Mail steht, damit nichts zu tun hat ;)

@VisualBeo:
Probier mal den Submission-Port aus, falls dieser aktiviert und in der Firewall des Servers geöffnet ist.
Dazu stellst du im Client statt des Standard-SMTP-Ports den Port 587 ein, die restlichen Einstellungen lässt du so.
Standardmäßig werden da bei Postfix praktisch alle Prüfungen abgeschaltet und gleichzeitig eine Authentifizierung zwingend vorgeschrieben - weshalb es also kein Problem darstellt, alle Spamfilter zu umgehen.
 
You must log in or register to reply here.
Back
Top