how to allow a rejcted domain
in [Postfix]
|
From: /dev/rob0 on 25 Mar 2010 19:38 On Thu, Mar 25, 2010 at 05:43:11PM +0000, Jamie Griffin wrote: > > You need to understand the documentation of > > parent_domain_matches_subdomains. Unfortunately, I don't know > > enough to explain it to you. :) But I'm fairly sure in your case > > that the leading dot pattern was not looked up. I unset this: > > parent_domain_matches_subdomains = > > so, for me, something similar (with ihost.com) is what worked. > > I had briefly looked at that setting earlier but thought just > using the .domain.tld notation would be ok. Just having another > read about that, it looks as though I need to set it like this: > > /usr/pkg/etc/postfix/main.cf: > [ ... ] > parent_domain_matches_subdomains = smtpd_access_maps > [ ... ] > > is that right? No. If you tell Postfix to match subdomains, the lookup that does this is the domain name WITHOUT the leading dot. For example, this: ihost.com permit_auth_destination would match for a check_sender_access lookup of ibg(a)low1ap106.infra.secaucus.mebs.ihost.com . (Maybe my complaint went up the line, because I see that name now has an A record. Go figure!) If you unset parent_domain_matches_subdomains as I suggested, the lookup would be this, with the leading dot: .ihost.com permit_auth_destination If you have a parent_domain_matches_subdomains list which does NOT include smtpd_access_maps. I am not sure how that is handled. My guess is that the leading dot lookup is used. > I also understood that using the $smtpd_sender_restrictions > parameter would be the right way to whitelist this domain for what > i'm trying to achieve, have I got that right? You have what is IMO an unwieldy and hard-to-manage set of smtpd restrictions. Personally, I prefer keeping most or all restrictions in a single stage, smtpd_recipient_restrictions. However, IIRC from your OP, you did have the reject_unknown_sender_domain only in smtpd_sender_restrictions. Therefore yes, you are right. But to understand why, you should know that reject_unknown_sender_domain that caused your rejection. Anywhere you use that restriction, you must precede it with your whitelist lookup. Ugh. Do consider standing up for the principle of requiring senders to use real domains in their email addresses. I would have done so myself, but I knew they were not going to resend the bounced email. :) (IIRC it was just a copy of my invoice, which I had from my Web browser anyway.) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
From: Jamie Griffin on 25 Mar 2010 20:22 > No. If you tell Postfix to match subdomains, the lookup that does > this is the domain name WITHOUT the leading dot. For example, this: > ihost.com permit_auth_destination > would match for a check_sender_access lookup of > ibg(a)low1ap106.infra.secaucus.mebs.ihost.com . (Maybe my complaint > went up the line, because I see that name now has an A record. Go > figure!) > If you unset parent_domain_matches_subdomains as I suggested, the > lookup would be this, with the leading dot: > .ihost.com permit_auth_destination Yep. got that. I had set it using the .domain.tld method without including $parent_domain_matches_subdomains initially because the way i understood the access(5) manual page I didn't need to do this, and only using $parent_domain_matches_subdomains without the leading '.' and in conjunction with an smtpd access map but, I'm easily confused :-) [ ... ] > You have what is IMO an unwieldy and hard-to-manage set of smtpd > restrictions. Personally, I prefer keeping most or all restrictions > in a single stage, smtpd_recipient_restrictions. However, IIRC from > your OP, you did have the reject_unknown_sender_domain only in > smtpd_sender_restrictions. Therefore yes, you are right. But to > understand why, you should know that reject_unknown_sender_domain > that caused your rejection. Anywhere you use that restriction, you > must precede it with your whitelist lookup. I'm going to re-read about smtpd_*_restrictions to better understand what i've done because from what you've said I could improve my configuration but can i ask quickly, do you mean I can move all of the smtpd restrictions i'm using into $smtpd_recipeint_restrictions ? > Ugh. Do consider standing up for the principle of requiring senders > to use real domains in their email addresses. I would have done so > myself, but I knew they were not going to resend the bounced email. > :) (IIRC it was just a copy of my invoice, which I had from my Web > browser anyway.) Yeah I feel thefrustration with that too. I mean, the fuss i've gone to today just to get one message through my server; and the fact it's the ISP i'm paying that has send it is not very encouraging. Thanks again for your time and help. Jamie.
From: /dev/rob0 on 26 Mar 2010 07:59 On Fri, Mar 26, 2010 at 12:22:55AM +0000, Jamie Griffin wrote: > I'm going to re-read about smtpd_*_restrictions to better > understand what i've done because from what you've said I > could improve my configuration "Improve" is a value judgment. I think it's fair to say that management is easier if you stay within a single stage. But some restriction combinations need multiple stages. I didn't see anything in yours that couldn't be done in one stage, but then, I don't know what's in your access maps. > but can i ask quickly, do you mean I can move all of the smtpd > restrictions i'm using into $smtpd_recipeint_restrictions ? With the caveat that "recipient" must be spelled correctly, yes. :) Reference: http://www.postfix.org/SMTPD_ACCESS_README.html -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
From: Dennis Guhl on 26 Mar 2010 08:37
On Fri, Mar 26, 2010 at 12:22:55AM +0000, Jamie Griffin wrote: > I'm going to re-read about smtpd_*_restrictions to better understand what i've done because from what you've said I could improve my configuration but can i ask quickly, do you mean I can move all of the smtpd restrictions i'm using into $smtpd_recipeint_restrictions ? Yes, actually it makes your main.cf much more uncluttered and less error prone. This are my restrictions, which I use on with various servers serving some messages per hour up to severel hundred messages per minute: smtpd_recipient_restrictions = check_recipient_access = btree:/etc/postfix/access_rfc-recipient, # check_client_access = btree:/etc/postfix/access_client, # check_helo_access btree:/etc/postfix/access_helo, # check_sender_access btree:/etc/postfix/access_sender, # check_recipient_access btree:/etc/postfix/access_recipient, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_mynetworks, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.njabl.org, reject_rhsbl_client blackhole.securitysage.com, check_policy_service unix:/public/postgrey, reject_unverified_recipient, # permit_mx_backup, # reject_unauth_destination, permit The first two lines are really one line, because of an irritating line breaking I made a manual wordwrab. And the last permit is yust for completeness, it is default. For the rest it is mostly copied from the greman book "Das Postfix-Buch" written by Peer Heinlein. The double occurrence of 'check_recipient_access =' assures in the first entry the unconditionally acceptance from emails to postmaster@ or abuse@ to comply with the RFCs 822 and 2142. The second occurence can be used to whitelist some faulty senders I whish to receive. Of course the rbl entries are working for me, but this does not say they do so for you. On my sites I never became aware of problems with NiX SPAM (manitu.net) whilst other people report frequend false positives. > Jamie. Dennis |