[Postfixbuch-users] reject_sender_login_mismatch ausgetrickst ?

[Andreas Meyer]

"Uwe Driessen" <driessen at fblan.de> schrieb:

> Andreas Winkelmann schrieb: 
> > On Sunday 01 July 2007 01:46, Uwe Driessen wrote:
> > 
> > > Er holt sich seine mails so wie es aussieht auch noch von anderen
> > > Mailservern ab und bounced dann über meinen Mailserver Mails die niemals
> > > über meinen Server zugestellt sein können. Dazu kommt dann noch das das
> > > sehr wahrscheinlich Pishingmails sind.
> > 
> > > Jun 30 05:06:51 fblan postfix/qmgr[23152]: 401D74DCD9B: from=<>, size=5167,
> > > nrcpt=1 (queue active)
> > 
> > > Die checks laufen alle Auszug vom reject_sender_login_mismatch
> > > Und einen <> als Absender habe ich garantiert nicht in der map drin stehen
> > > Warum greift dieser check nicht bei dieser Mistgurke.
> > 
> > Weil die <>-Adresse etwas besonderes ist. Die lässt sich von den checks um
> > $smtpd_sender_login_maps herum nicht abfangen. Da Du sie allen zuordnen
> > müsstest, wäre das ja auch unnötig.
> 
> Der sender <> ist eigentlich ein Systemsender und kein Clientsender. Der wird ja nur
> genommen wenn Benachrichtigungen an Clients geschickt werden.
> 
> Dieser Kunde ist einfach Client hat aber aus Spieltrieb einen eigenen Postfix mit nach
> gelagertem Exchange aufgebaut.
> 
> Die frage ist wie ich solche Spielchen (nicht den normalen Mailverkehr) verhindern kann.
> Der Kunde darf nur mit seinem Namen abholen und auch nur mit seinem Namen versenden wie
> jeder andere Kunde/Client auch.
> 
> In seine Konfig lässt er sich nicht reinschauen und der Liste will er auch nicht beitreten
> das man mal dahinter kommt was er macht.
> 
> Postfix muß aber so was abfangen es kann ja nicht sein das für den andere Regeln gelten
> wie für "normale" clients.
> 
> Es muß eigentlich nur der reject_sender_login_mismatch greifen dann sind die Spielchen
> schon nicht mehr möglich.
> 
> Die frage ist was macht der User das da die restriction nicht greift ist da ein bug oder
> habe ich mist gebaut. Mein Postfix ist nun mal der Herr über Einlieferung und Versendung
> und da dulde ich keinen anderen daneben *gg  
> 
> Wer hat damit Erfahrungen denn es gibt ja einigen Firmen die in dieser Kombination
> arbeiten. 

Ich zitiere mal:
<Zitat>
 The idea behind REJECT_SENDER_LOGIN_MISMATCH is that no-one can
 use a given sender address unless they have logged in.
 Otherwise, REJECT_SENDER_LOGIN_MISMATCH is completely useless.
   Wietse
</Zitat>

Bei mir sind alle Benutzer, die relayen wollen in einer sasl_needed.db erfaßt.
Sobald reject_sender_login_mismatch aktiv ist, müssen die dort erfaßt sein.
Es wird auf einen Eintrag in der sasldb überprüft.

# reject_sender_login_mismatch
# Verwirft, wenn $smtpd_sender_login_maps eine MAIL FROM Adresse den Besitzer
# spezifiziert, aber der sich nicht mit SASL authentifiziert hat; Verwirft,
# wenn der Sender sich authentifiziert hat, aber die MAIL FROM Adresse nicht
# mit dem Sender übereinstimmt.


> > 
> > Du könntest höchstens mit access-Maps agieren.
> > 
> > Hmm, da der Benutzer von Dir einen User/Passwort bekommen hat, gibt es ja wohl
> > zumindest eine art Vertrauensstellung zwischen euch, also wäre es vielleicht
> > angebracht einfach mal mit der Person zu reden.
> 
> Vertrauen ist gut Kontrolle ist besser. Das ist ganz einfach ein Kunde der auf meinem
> Server gehostet wird. Fetchmail holt ab postfix versendet und leitet weiter an Exchange
> oder nimmt von dem Exchange an.
> Mich interessiert auch nicht wie der seine gurke konfiguriert hat sondern nur wie ich
> meinen Server sauber halte. Ansonsten muß ich immer aufpassen wenn ein Kunde sich so was
> einrichtet dann komme ich gar nicht mehr von der Überwachung weg.  
> 
> 
> 
> Mit freundlichen Grüßen
> 
> Drießen
> 


-- 
   Andreas Meyer
   
Internet-Tel.: 06341620317
Mein öffentlicher GPG-Schlüssel unter:
http://gpg-keyserver.de/pks/lookup?search=anmeyer&fingerprint=on&op=index