sendmail: Wie verhindern dass ipV6 relayer genutzt werden?

testit

Well-Known Member
Hallo,

versendet man eine EMail mittels sendmail via smtp, bspw. an eine t-online Mailaddy, kann man im maillog anschließend u.a. einen Eintrag der Form

relay=mailin.v6.t-online.de
oder bspw.
mx03.t-online.de

sehen, wobei der erste (v6) ein ipV6-System, das zweite (mx03) ein ipV4-Mail Exchanger ist.

Ich frage mich nun, wie man eigentlich ausschließen kann, dass sendmail einen IPv6-Mail-Exchanger kontaktiert, wenn man eine Mail versendet? Denn schließlich kann es ja sein, dass man sein FreeBSD-System noch gar nicht auf ipV6-Unterstützung umgestellt hat.

DaemonPortOptions=Name=IPv6 .... in der sendmail.cf mit einem dnl zu deaktivieren, scheint offensichtlich nicht auszureichen.

Danke und Gruß
testit
 
Hast du im System ipv6 mal deaktiviert, ipv6_enable="NO". bzw. gibts für sysctl-Sachen zum ausschalten. Wie machst du den deine Authentivizeirung oder ist das eine Standleitung. Telekom oder T-Online sind sowieso nicht so tolle, die schreiben um.
 
DaemonPortOptions=Name=IPv6 .... in der sendmail.cf mit einem dnl zu deaktivieren, scheint offensichtlich nicht auszureichen.

Du sollst auch nicht in der sendmail.cf rummalen, sondern in der mc und dann eine neue Konfiguration mit make anstoßen, um zu guter letzt sendmail neu zu starten.

Kann durchaus sein, daß Du das alles gemacht hast, aber zuweilen ist man ja vernagelt ... ;)
 
Hallo,

vielen Dank für Eure Hinweise.

Was in der sendmail.mc eingetragen wird als

Code:
dnl Enable for both IPv4 and IPv6 (optional)
DAEMON_OPTIONS(`Name=IPv4, Family=inet')
DAEMON_OPTIONS(`Name=IPv6, Family=inet6, Modifiers=O')

wird anschließend in der sendmail.cf zu

Code:
DaemonPortOptions=Name=IPv4 ...
DaemonPortOptions=Name=IPv6 ...

Insofern spielt es keine Rolle, ob ich das in der .mc oder .cf ändere.

Hatte es aber auch vorsichtshalber in der .mc geändert und anschliessend mittels
make stop all install start
die .cf neu gebaut sowie sendmail neu gestartet.

Auch ipv6_enable="NO" hatte ich bereits "gesetzt".

@Flex6: Die Authentifizierung erfolgt über SASL-AUTH. Sendmail läuft auf einem FreeBSD-Server und wird mittels SMTP von einem Mail-Client von "außen" über das Internet (arcor, t-online usw.) genutzt. Also keine ungewöhnliche Konstellation.


Nette Grüße
testit
 
Gibt es einen Unterschied zwischen:
DAEMON_OPTIONS(`Name=IPv4, Family=inet')

und:
DAEMON_OPTIONS(`Name=MTA-v4, Family=inet')

wie es im Sendmail Manual [1] erwähnt wird?


BTW:
Wenn sich dein Sendmail selbst mit anderen Servern (als Client) verbindet, könnten evtl. auch eher die CLIENT_OPTIONS zutreffen? DAEMON_OPTIONS sagt ja nur auf welchen Sockets/IP's er auf eingehenden Verbindungen wartet.



[1] http://www.sendmail.org/m4/tweaking_config.html#DAEMON_OPTIONS
 
Hallo Wiedmann,

nach dem, was ich gelesen habe, gibt es keinen Unterschied in den o.a. Optionen.
Die Anweisung in der mc wird in das angeführte Pendant in der cg umgewandelt.

Was Deine Anmerkungen bzgl. der CLIENT-Eigenschaften angeht, liegst Du m.E. richtig.

Wenn ich auf meinem FreeBSD-Server eingebe:

nslookup -type=mx t-online.de

erhalte ich neben den typischen mx.t-online.de Mail Exchangern halt auch

mailin.v6.t-online.de has AAAA address 2003:2:2:10:fee::33
mailin.v6.t-online.de has AAAA address 2003:2:2:10:fee::32

Und leider werden dann halt auch gelegentlich DIESE beim Versenden einer EMail an eine t-online-Adresse als RELAY benutzt. Aber warum?

WIE entscheidet sendmail, welches der verfügbaren RELAYS es nutzt?

WIE kann man einstellen, dass es keinen Mail-Exchanger nutzt, der eine AAAA-Adresse hat?


Nette Grüße
testit
 
Hallo,

warum ist das Deiner Ansicht nach kontraproduktiv?

Und: Haben wir alle die letzten 10 Jahre "kontraproduktiv" gearbeitet?

Sind Dir eigentlich die Nachteile von ipV6, die auf uns alle zukommen werden, bekannt?


Nette Grüße
testit
 
nachteile ? .... hm
das es kein nat mehr gibt ? sehr geil ........

es gibt noch die eine oder andere baustelle ja aber im kern steht das protocol.

hinzukommt das einige grosse zugansprovider hier in D ende , anfang 1012 ihre dsl leitungen mit ipv6 ausstatten.

und in meinen augen gibt es nicht zu viele nachteile wie es vorteile gibt.

holger
 
Nun ja,

wenn man schon immer Anhänger des "gläsernen" Surfers war und darüberhinaus auch gerne noch mehr Spamaufkommen verzeichnen will, weil man am Tag gar nicht genug Viagra-Werbung etc. bekommen kann, ist ipV6 schon eine tolle Sache.

Nette Grüße
testit
 
Nun ja,

wenn man schon immer Anhänger des "gläsernen" Surfers war und darüberhinaus auch gerne noch mehr Spamaufkommen verzeichnen will, weil man am Tag gar nicht genug Viagra-Werbung etc. bekommen kann, ist ipV6 schon eine tolle Sache.

Nette Grüße
testit


das mit den glaesernen surfer ist mumpitz .... wenn du dich auf das thema mit der mac addr beziehst ........ dafuer gibt es ja die privacy extension.

ansonsten ist die ip genauso transparent wie eine nochrmale ipv4 addr.

und wenn du probleme mit spam hast solltest du du mal ueberlegen
ob du die richtigen massnahmen dagegen verwendest.

das hat mit ipv6 nix zu tun.

holger
 
Nun ja,

wenn man schon immer Anhänger des "gläsernen" Surfers war und darüberhinaus auch gerne noch mehr Spamaufkommen verzeichnen will, weil man am Tag gar nicht genug Viagra-Werbung etc. bekommen kann, ist ipV6 schon eine tolle Sache.

Nette Grüße
testit

nur weil man falsche dinge wiederholt, werden sie auch nicht richtiger (auch wenn diverse Rechtschreibeformen mich eines besseren belehren, aber sei's drum). wie mark05 schon richtig sagte, solltest du dich mit IPv6 mehr auseinandersetzen als irgendwelchen Mist nachzubrabbeln und deine Spamproblematik hat auch andere Gründe, als IPv6.

Noch zum Thema:
Wenn dein System keinen IPv6 router hat/kennt, sollte auch nicht per IPv6 versucht werden, irgendwelche Dinge zu verschicken; schon gar nicht, wenn du ein IPv4 relay setzt. Nur weil AAAA records zurückgeliefert werden, sollte noch lange nicht heissen, dass dein System mehr als LinkLocal Adressen besitzt oder versucht, mit jemand anderem per IPv6 zu kommunizieren
 
Zuletzt bearbeitet:
Evtl meint er RBLs, die natürlich schlechter funktionieren, wenn man weiterhin nur einzelne IPs blockt - eben weil im Protokoll eingebaut ist, dass sich Clients selber neue Adressen basteln.

Aber man kann ja auch einfach das ganze /64er blocken…

Falls dein System kein IPv6 unterstützt (ipv6_enable="NO"), dann wird auch nichts über IPv6 verschickt. Wie auch? Also entweder interpretierst du die Logs nicht richtig, oder Sendmail redet Quatsch.
 
nur weil man falsche dinge wiederholt, werden sie auch nicht richtiger (auch wenn diverse Rechtschreibeformen mich eines besseren belehren, aber sei's drum). wie mark05 schon richtig sagte, solltest du dich mit IPv6 mehr auseinandersetzen als irgendwelchen Mist nachzubrabbeln und deine Spamproblematik hat auch andere Gründe, als IPv6.

Ich denke, DU solltest als Erster Deinen eigenen Tipp beherzigen und Dich einmal näher mit den dem Thema ipV6 und daraus entstehenden Nachteilen auseinandersetzen. bevor Du derartige Spekulationen von Dir gibst.

Dass Du - zumindest in DIESEM Thread - bereits offenbarst, dass Du Informationen falsch aufnimmst, zeigt sich bereits daran, dass Du auf eine Spamproblematik (".. und Deine Spamproblematik") verweist, obwohl ich an keiner Stelle in diesem Thread von einer bestehenden Spam-Problematik berichtet habe.

Nette Grüße
testit
 
Falls dein System kein IPv6 unterstützt (ipv6_enable="NO"), dann wird auch nichts über IPv6 verschickt. Wie auch? Also entweder interpretierst du die Logs nicht richtig, oder Sendmail redet Quatsch.

Hallo,

vielen Dank für Deinen Hinweis.

Das Problem ist, dass ich zuvor KEIN ipv6_enable="NO" gesetzt hatte und trotzdem der beschriebene Fehler auftritt. Offensichtlich orientiert sich sendmail nicht an dieser Einstellung, sondern muß eigenständig davon in Kenntnis gesetzt werden, keine ipV6-Mail-Exchanger zu nutzen.

Problem ist, dass halt bisher alle mir bekannten (in diesem Thread beschriebenen) Maßnahmen nicht greifen und trotzdem immer wieder mal dieser v6.-Mail-Exchanger in´s Spiel kommt.

Ich habe gestern einen englischsprachigen Thread gefunden, in dem als einzige Lösung die Rekompilierung von sendmail mit expliziter Deaktivierung einer ipV6-Unterstützung vorgestellt wurde.


Nette Grüße
testit


P.S.:
BTW: Du hast einen der zu beachtenden Punkte im Zusammenhang mit ipV6 völlig richtig angeführt.

Für die Interessierten ein Bericht, in dem gleich mehrere Spezialisten zu Wort kommen, die beruflich mit Anti-Spam-Massnahmen zu tun haben:
http://www.internet-security.ca/int...l-could-complicate-e-mail-spam-filtering.html
 
Zuletzt bearbeitet:
Hallo,

ich erinnere mich dunkel, dass ich mal vor dem selben Problem stand, weil der Provider den rDNS-Eintrag für IPv6 nicht hingekriegt hat und deshalb die über IPv6 gesendeten Mails reihenweise nicht zugestellt wurden wegen fehlerhaften FCrDNS.

Jedenfalls habe ich es irgendwie so gelöst:
Code:
CLIENT_OPTIONS(`Family=inet6, Address=::1')dnl
CLIENT_OPTIONS(`Family=inet, Address=0.0.0.0')dnl

Ohne Anspruch auf absolute Richtigkeit des Code-Schnipsels :zitter:
Aber die Idee war, dass sendmail versucht, die Mail zuerst über das IPv6 Loopback-Interface rauszuschicken, was natürlich nicht funktioniert, und dann auf IPv4 zurückfällt.

Ist jetzt natürlich nicht super elegant, aber ein Workaround der bei mir funktioniert hat :)
 
Hallo,

ich erinnere mich dunkel, dass ich mal vor dem selben Problem stand, weil der Provider den rDNS-Eintrag für IPv6 nicht hingekriegt hat und deshalb die über IPv6 gesendeten Mails reihenweise nicht zugestellt wurden wegen fehlerhaften FCrDNS.

Jedenfalls habe ich es irgendwie so gelöst:
Code:
CLIENT_OPTIONS(`Family=inet6, Address=::1')dnl
CLIENT_OPTIONS(`Family=inet, Address=0.0.0.0')dnl

Ohne Anspruch auf absolute Richtigkeit des Code-Schnipsels :zitter:
Aber die Idee war, dass sendmail versucht, die Mail zuerst über das IPv6 Loopback-Interface rauszuschicken, was natürlich nicht funktioniert, und dann auf IPv4 zurückfällt.

Ist jetzt natürlich nicht super elegant, aber ein Workaround der bei mir funktioniert hat :)

Hallo,

ich denke, dass ich genau DAS Problem habe, das auch Du hattest und denke, dass mir Deine Hinweise helfen, den richtigen Lösungsansatz zu finden.

Während Deine Lösung mit einem Fallback-Ansatz arbeitet müsste es doch möglich sein, sendmail von vornherein "einzutrichtern", nur noch über ipV4-relayer Mails zustellt.

Nette Grüße
testit
 
Vielleicht bin ich ja einfach zu blöde, aber wer filtert SPAM denn lediglich maßgeblich nach IPs?

Hi,

Oxy hatte ja schon auf RBL hingewiesen.

Schau mal unter nachstehenden Links:
http://de.wikipedia.org/wiki/Realtime_Blackhole_List
http://www.spamhaus.org/pbl/

Bspw. setzen Anti-Spam-Werkzeuge wie SpamAssassin u.a. UNTER ANDEREM auf derartige Datenbanken und lassen dann das Ergebnis - wenn eine Absender-IP in einer solchen Datenbank eingetragen ist - in ihr eigenes Scoring zur Identifikation von Spam miteinfließen.

Überbewerten darf man derartige BLS natürlich nicht, denn man bekommt logischerweise auch ab und an bei dynamischer IP-Zuweisung durch seinen Access-Provider eine IP, die bereits schon einmal von einem Spammer genutzt wurde und wird daher ebenfalls unzutreffenderweise als Spammer angesehen. Daher wird ein "Treffer" in einer RBL auch von SpamAssassin nur als EIN TEILWERT zur Erkennung von Spams gewichtet, wobei man zum Glück den Gewichtungswert ggf. auch selbst ändern kann.


Nette Grüße
testit
 
tz tz tz

statische ip blocks egal ob ipv4 oder ipv6 , in bezug auf spam , in meinen augen das ineffizenteste was man machen kann , als ob die spammer nix lernen .

und klar ist die privacy extension nicht der weisheit letzen schuss aber wovon reden wir ?

das jemand weiss von welchem hersteller deine netzwerkarte bzw dein rechner ist ?
sorry ....... geh mal zu facebook ........ die lachen dich da aus .


ipv6 hat die gleichen probleme wie ipv4 , bezogen auf spam nur das es einfach ein
paar ;) mehr addressen gibt , und gerade deswegen macht es keinen sinn sich mit
statischen block filtern zu beschaeftigen .

und wenn das die einzigste sorge ist die du in bezug auf ipv6 und sicherheit hast , viel spass
ich sehe selber noch ein paar andere porbleme .

holger
 
und wenn das die einzigste sorge ist die du in bezug auf ipv6 und sicherheit hast , viel spass
ich sehe selber noch ein paar andere porbleme .

holger

Ich auch:

http://events.ccc.de/congress/2010/Fahrplan/events/3957.en.html

<offtopic>
Was ich auch sehe, ist dass große namhafte Hersteller im Netzwerkbereich nicht hinterherkommen, IPv6 zu unterstützen. Und ob hier in DE 2012 wirklich mal IPv6 auf den Zugangsleitungen gefahren wird, steht sicherlich in den Sternen. Das wäre aber dringends notwendig, um endlich mal Druck auszuüben.
</offtopic>

Rob
 
Nein,

ipV4 und ipV6 haben bezogen auf Spam NICHT das gleiche Problem. Wenn Du das nicht nachvollzogen hast, solltest Du Dir die genannten Quellen ggf. nochmals GENAUER durchlesen.

Was Deine Anmerkungen zur Netzwerkkarte angeht: SELBSTVERSTÄNDLICH ist genau DAS ein Bestandteil des Problems und jedem einleuchtend, der sich mit Datenschutz, Anonymisierungstools usw. auseinandersetzt. Es geht nämlich nicht immer nur um ein eindeutiges Attribut, sondern heutzutage oftmals um die Identifikation eines Anwenders durch eine Kombination von Attributsmerkmalen.


Nette Grüße
testit

tz tz tz

statische ip blocks egal ob ipv4 oder ipv6 , in bezug auf spam , in meinen augen das ineffizenteste was man machen kann , als ob die spammer nix lernen .

und klar ist die privacy extension nicht der weisheit letzen schuss aber wovon reden wir ?

das jemand weiss von welchem hersteller deine netzwerkarte bzw dein rechner ist ?
sorry ....... geh mal zu facebook ........ die lachen dich da aus .


ipv6 hat die gleichen probleme wie ipv4 , bezogen auf spam nur das es einfach ein
paar ;) mehr addressen gibt , und gerade deswegen macht es keinen sinn sich mit
statischen block filtern zu beschaeftigen .

und wenn das die einzigste sorge ist die du in bezug auf ipv6 und sicherheit hast , viel spass
ich sehe selber noch ein paar andere porbleme .

holger
 
Zurück
Oben