Glad you fixed it! On Thu, 2010-05-20 at 23:16 +0200, b.hinzer wrote: > > > I guess I found my problem. Plesk also has a smtps_psa which needs the > same settings like smtp_psa. > > Then I tried your hint by blacklisting my domain (using wildcard > @web-vision.de in blacklist_senders). > > To make sure that I have no greylisting entries already, I flushed my > greylist folder completely. > > > > And now, guess what - it's running like it should. No more open_relay > and logfile now shows auth-message. Thanks for your help! Great!!! > > > > Eric Shubert <[email protected]> hat am 20. Mai 2010 um 22:30 > geschrieben: > > > Sorry, I can't answer this. I use qmail-toaster, not plesk. > > Perhaps a plesk user (or a plesk list) would be helpful. > > > > -- > > -Eric 'shubes' > > > > b.hinzer wrote: > > > > > > > > > Could this be, because of the fact that the settings are wrong in > > > /etc/xinet.d/smtp_psa are wrong (or even in wrong order)? > > > > > > > > > > > > server_args = > -Rt0 /var/qmail/bin/relaylock /usr/local/bin/spamdyke > > > -f /etc/spamdyke.conf /var/qmail/bin/qmail-smtpd > > > > /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw > > > /var/qmail/bin/true > > > > > > > > > > > > > > > > > > > > > > > > Eric Shubert <[email protected]> hat am 20. > > > Mai 2010 um 20:09 geschrieben: > > > > > > > Right-o, Sebastian. :) > > > > > > > > Boris, once you have all your users authenticating, you'll want > to > > > > *blacklist* your local domains. This will block emails where > the senders > > > > are faked with your domain. > > > > > > > > -- > > > > -Eric 'shubes' > > > > > > > > Sebastian Grewe wrote: > > > > > That would still require your clients to actually enable SMTP > > > > > authentication on their end to do the process of > authentication. They > > > > > have to send the username and password and once approved they > are > > > > > allowed to send. > > > > > > > > > > On Thu, 2010-05-20 at 19:58 +0200, Boris Hinzer wrote: > > > > >> We are running standard Plesk qmail and also have SMTP auth > enabled. > > > > >> > > > > >> > > > > >> Am 20.05.2010 um 19:40 schrieb Eric Shubert > > > <[email protected]>: > > > > >> > > > > >>> I believe Sebastian's right. Greylisting won't come into > play if the > > > > >>> sender is authenticating successfully. Your problem is that > > > > >>> authentication isn't happening, for whatever reason. > > > > >>> > > > > >>> In order to track down the problem, we need to know a bit > more about > > > > >>> your configuration. Are you using any particular 'flavor' > of qmail? > > > > >>> > > > > >>> In your client configuration, there should be a "server > requires > > > > >>> authentication" or "use username and password" setting of > some sort > > > > >>> (varies by client program). Be sure that's checked. > > > > >>> > > > > >>> -- > > > > >>> -Eric 'shubes' > > > > >>> > > > > >>> Sebastian Grewe wrote: > > > > >>>> Hey, > > > > >>>> > > > > >>>> I think there is an issue somewhere else. We are using > SMTP Auth on > > > > >>>> Qmail Level and it works fine with Greylisting. Users are > not being > > > > >>>> rejected when sending mail through the servers after SMTP > > > > >>>> authentication. > > > > >>>> > > > > >>>> I have no experience with Spamdyke doing the > authentication. But > > > make > > > > >>>> sure the users are actually doing the authentication > process. > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Sebastian > > > > >>>> > > > > >>>> On Thu, 2010-05-20 at 19:03 +0200, Boris Hinzer wrote: > > > > >>>>> Am 20.05.2010 um 18:15 schrieb Eric Shubert > > > <[email protected]>: > > > > >>>>> > > > > >>>>>> Boris Hinzer wrote: > > > > >>>>>>> Hello, > > > > >>>>>>> > > > > >>>>>>> can anybody verify this behavior? > > > > >>>>>>> We are facing the situation, that if we whiteliste > local > > > > >>>>>>> emailadresse the smtp auth is completely skipped. > > > > >>>>>>> Server is then acting like an open relay for these > mailaddresses. > > > > >>>>>>> > > > > >>>>>>> In spamdyke.conf we have the following: > > > > >>>>>>> > smtp-auth-command=/var/qmail/bin/smtp_auth /var/qmail/bin/true / > > > > >>>>>>> var/ > > > > >>>>>>> qmail/bin/cmd5checkpw /bin/true > > > > >>>>>>> smtp-auth-level=ondemand-encrypted > > > > >>>>>>> > > > > >>>>>>> Best regards, > > > > >>>>>>> > > > > >>>>>>> Boris > > > > >>>>>> I can't verify, but this is the behavior I would expect. > If > > > > >>>>>> something is > > > > >>>>>> whitelisted, all filters are bypassed. Likewise if a > session is > > > > >>>>>> authenticated. Whitelisting can be dangerous, especially > > > > >>>>>> whitelisting > > > > >>>>>> your own domain(s). Whitelisting is intended more for > getting > > > > >>>>>> around > > > > >>>>>> trusted mail servers that are misconfigured (rDNS issues > > > > >>>>>> typically). > > > > >>>>>> > > > > >>>>>> If your local users all authenticate (which they > should), you can > > > > >>>>>> *blacklist* your local domains, which effectively blocks > spam > > > which > > > > >>>>>> spoofs/forges your domains. This is counter intuitive, > but since > > > > >>>>>> your > > > > >>>>>> users authenticate, they will not be affected by the > blacklist. > > > > >>>>>> > > > > >>>>>> What circumstance lead you to whitelist your local > domain in the > > > > >>>>>> first > > > > >>>>>> place? Difficulty authenticating? > > > > >>>>>> > > > > >>>>>> -- > > > > >>>>>> -Eric 'shubes' > > > > >>>>>> > > > > >>>>>> _______________________________________________ > > > > >>>>>> spamdyke-users mailing list > > > > >>>>>> [email protected] > > > > >>>>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > >>>>> Actually if we don't whitelist our local users they also > run into > > > > >>>>> greylisting process. This leads to very annoying messages > in > > > > >>>>> Outlook, > > > > >>>>> which our users don't understand. > > > > >>>>> > > > > >>>>> At the moment we removed senders from whitelist and > started an ip > > > > >>>>> based whitelist, which is IMHO second best solution > (thinking of > > > > >>>>> cell > > > > >>>>> phones, ipad, etc.). > > > > >>>>> > > > > >>>>> We are also facing the fact that mails where senders are > faked and > > > > >>>>> equal to receivers are getting through. > > > > >>>>> > > > > >>>>> Best regards, > > > > >>>>> > > > > >>>>> Boris > > > > >>>>> _______________________________________________ > > > > >>>>> spamdyke-users mailing list > > > > >>>>> [email protected] > > > > >>>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > >>> _______________________________________________ > > > > >>> spamdyke-users mailing list > > > > >>> [email protected] > > > > >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > >> _______________________________________________ > > > > >> spamdyke-users mailing list > > > > >> [email protected] > > > > >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > > > > > _______________________________________________ > > > > spamdyke-users mailing list > > > > [email protected] > > > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > spamdyke-users mailing list > > > [email protected] > > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > _______________________________________________ > > spamdyke-users mailing list > > [email protected] > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
