-------- Original-Nachricht -------- > Datum: Fri, 31 Jul 2009 16:16:34 +0200 > Von: albinootje <[email protected]> > An: [email protected] > Betreff: Re: [Dspam-user] Alias spam ham question.
> Steve wrote: > > >> Would something like this do ? > >> > http://thelowedown.wordpress.com/2008/02/24/postfix-restricting-smtpd-client-access-by-domain/ > >> I wouldn't mind restricting my users to only forward to ham and > >> spam inside the LAN. > >> > > That would do it but much better is to use restriction classes and > > only allow authenticated users to use the spam/ham alias. Let me know > > if you need help in how to setup that. > I am a bit in a rush. Need to go to buy some food. So I will make it short. In main.cf add a new restriction class (lets call it "check_dspam_train_alias"): --------- check_dspam_train_alias = permit_sasl_authenticated permit_mynetworks reject --------- Then tell Postfix that you have that restriction class by adding/changing in main.cf the following: --------- smtpd_restriction_classes = check_dspam_train_alias --------- Should you have already an entry inside "smtpd_restriction_classes" then just add the "check_dspam_train_alias" into the list of known restriction classes. And now glue that together (I mean the restriction class called "check_dspam_train_alias") together with your normal mail processing. Since you want to restrict the access to an recipient the earliest stage checking for the recipient would be at the "RCPT TO" stage (aka: smtpd_recipient_restrictions) and the latest could be at the "END-OF-DATA" stage (aka: smtpd_end_of_data_restrictions). I would strongly advise to not do it at the "END-OF-DATA" stage since this would wast to much time and bandwidth. So lets do it at the earliest stage (or at whatever stage you prefer starting from the "RCPT TO" stage). Add/change in your main.cf the following: --------- smtpd_recipient_restrictions = [your other permitting restrictions like "permit_sasl_authenticated", "permit_mynetworks", etc...] [your other restricting restrictions like "reject_non_fqdn_sender", "reject_unknown_sender_domain", etc] check_recipient_access pcre:${config_directory}/dspam_train.pcre [your other restrictions] --------- So you add that "check_recipient_access" at that stage where you think is best to check for the recipient (aka the spam/ham alias). I added a PCRE but basically this can be any of the Postfix supported lookup table on your setup. The PCRE table could look like this (assuming your SPAM alias is "s...@...." and your HAM alias is "h...@...."): --------- # smtpd_recipient_restrictions = check_recipient_access pcre:${config_directory}/dspam_train.pcre # # Check here if the recipient is our DSPAM # SPAM-/HAM alias and if it is then instruct # Postfix to evaluate the restriction class # "check_dspam_train_alias". # /^(spam|ham)\@([...@.]+\.?){1,99}\.[a-z]{2,4}$/ check_dspam_train_alias --------- You could simplify the RegExp to be (if you like to capture any mail send to spam@ ham@): --------- /^(spam|ham)\...@.*$/ check_dspam_train_alias --------- If you want you could even add your domain instead of matching any domain: --------- /^(spam|ham)\...@mydomain\.tld$/ check_dspam_train_alias /^(spam|ham)\...@another\-domain\.tld$/ check_dspam_train_alias --------- Or all in one line: --------- /^(spam|ham)\@((mydomain|another\-domain)\.tld|one\-more\.co\.uk|again\-one\.com)$/ check_dspam_train_alias --------- It's all up to you what recipients you want to allow only for authenticated users. I think you get the point. Should you have just one global SPAM-/HAM alias then using a hash db should be faster then the other lookup methods. So now you have enclosed the SPAM-/HAM alias in a restriction class and should someone from external write to your SPAM-/HAM alias and not be authenticated or from your network then you will not allow that recipient to be used. Authenticated users and users from your network are double secured. First by using (for example) "permit_sasl_authenticated" in "smtpd_recipient_restrictions" before using the "check_recipient_access" with the PCRE and secondly by allowing in the restriction class "check_dspam_train_alias" again the two permit instructions (permit_sasl_authenticated and permit_mynetworks) before the final reject. So legitimate users should not be affected by the new added restriction class while all others should be rejected in "check_dspam_train_alias"). > Yes, please. > TIA. > Steve -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
