Re: whitelisting problem
Michael Orlitzky put forth on 12/5/2009 1:38 AM: Stan Hoeppner wrote: I can't figure out why my whitelist entry for 204.238.179.0/24 is being ignored. If not for a transient DNS failure this afternoon I'd not have known this was broken. The check_client_access whitelist entry _should_ have triggered before reject_unknown_client_hostname. Any ideas why is doesn't/didn't? ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? You rejected the HELO hostname, not the IP address. What is reject_unknown_helo_hostname going to do when your DNS is broken? You missed the point entirely because you went after the low hanging fruit, calling out you read the rejection wrong!. Re-read my email and tell me why there was a rejection at all; why the email wasn't accepted as it should have been. If you'd actually read my entire email the first time, you wouldn't have answered as you did. You'll likely have to go for the fruit at the top of the tree to get the right answer. I've been on the top branch all day and can't figure it out, thus my email to the list. -- Stan
Re: whitelisting problem
* Stan Hoeppner s...@hardwarefreak.com: smtpd_helo_required = yes smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access Did you mean check_helo_access? Stefan reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unlisted_recipient check_recipient_access hash:/etc/postfix/access reject_rbl_client zen.spamhaus.org check_policy_service inet:127.0.0.1:6 /etc/postfix/access ... 66.135.197 OK 168.100.1 OK 204.238.179 OK spam-l-boun...@spam-l.com OK owner-postfix-us...@cloud9.net OK majordomo-ow...@cloud9.net OK owner-postfix-us...@postfix.org OK ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? -- Stan
Re: whitelisting problem
Stefan Förster put forth on 12/5/2009 5:46 AM: * Stan Hoeppner s...@hardwarefreak.com: smtpd_helo_required = yes smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access Did you mean check_helo_access? What does this have to do with the question I asked? How would this cause the problem I'm inquiring about? Why have two members now completely missed the problem? -- Stan
Re: whitelisting problem
Hallo Stan, * Stan Hoeppner s...@hardwarefreak.com: Stefan Förster put forth on 12/5/2009 5:46 AM: * Stan Hoeppner s...@hardwarefreak.com: smtpd_helo_required = yes smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access Did you mean check_helo_access? What does this have to do with the question I asked? How would this cause the problem I'm inquiring about? Why have two members now completely missed the problem? Rejection message: | Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from | unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: | Host not found; from=spam-l-boun...@spam-l.com | to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Obviously triggered by the reject_unknown_helo_hostname in: |smtpd_helo_restrictions = |check_recipient_access hash:/etc/postfix/access |reject_non_fqdn_helo_hostname |reject_invalid_helo_hostname |reject_unknown_helo_hostname Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. If this isn't what you were looking for I don't have any idea what your question is. Stefan
Re: whitelisting problem
* Stefan Förster cite+postfix-us...@incertum.net: Rejection message: | Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from | unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: | Host not found; from=spam-l-boun...@spam-l.com | to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Obviously triggered by the reject_unknown_helo_hostname in: |smtpd_helo_restrictions = |check_recipient_access hash:/etc/postfix/access |reject_non_fqdn_helo_hostname |reject_invalid_helo_hostname |reject_unknown_helo_hostname Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. Addendum: You can use check_client_access here. Stefan
Re: sender_dependent_relayhost_maps and ldap with multivalue attribute
Yes, i solved problem using how result_attribute a single-valued attribute. Thanks Victor Duchovni wrote: On Thu, Dec 03, 2009 at 01:57:07AM +0100, Giovanni Mancuso wrote: result_attribute = domains result_format = [127.0.0.1]:2501 expansion_limit = 1 But i have: postfix/trivial-rewrite[12577]: warning: dict_ldap_get_values[1]: /opt/postfix/etc/ldap/ldap_relaymaps.cf: Expansion limit exceeded for key: 'pi...@example1.org' If i delete example2.org and example3.org from ldap, it works correctly. If the domains attribute is multi-valued, or multiple entries match the query, you cannot use this schema to determine the relayhost. Your query must match a single LDAP entry and return a single-valued attribute. Postfix will not ignore attribute values in the result-set.
Re: remote_header_rewrite_domain ignored
Wietse Venema wrote: Ed W: Hi, I'm using postfix 2.5.7 and having some trouble with the server domain being appended to incomplete sender addresses. I have set # postconf|grep -e rewrite -e append -e myorigin -e mydomain -e local_header append_at_myorigin = yes append_dot_mydomain = no local_header_rewrite_clients = Note: local_***HEADER***_rewrite_clients, a feature that controls how HEADER address are rewritten. Fair enough - can you please help correct my config given the original goal of avoiding incomplete email addresses having a domain automatically appended? Thanks Ed W
Re: remote_header_rewrite_domain ignored
Ed W wrote: Wietse Venema wrote: Ed W: Hi, I'm using postfix 2.5.7 and having some trouble with the server domain being appended to incomplete sender addresses. I have set # postconf|grep -e rewrite -e append -e myorigin -e mydomain -e local_header append_at_myorigin = yes append_dot_mydomain = no local_header_rewrite_clients = Note: local_***HEADER***_rewrite_clients, a feature that controls how HEADER address are rewritten. Fair enough - can you please help correct my config given the original goal of avoiding incomplete email addresses having a domain automatically appended? To clarify the question - the goal is if someone connects via the network (not local sendmail command) and the transcript says RCPT TO: asdf that this is subsequently bounced as being an invalid recipient. What is happening at present is that it's being translated to a...@mydomain.com and being delivered to that recipient (I accept that I can reject this during the smtp conversation, and this is done on our main configuration, but I have a subset of customers for which I must accept this email and *bounce* it later) I suspect that it's necessary to set append_at_myorigin=no ? However, the documentation warns of this being an unsupported configuration? Can you please explain the correct way to achieve this configuration (surely it's a fairly normal configuration for mailservers these days?) However, note the docs for append_at_myorigin says that addresses have $remote_header_rewrite_domain appended and this is blank in my config? So I am still unsure why something is getting appended at all? I'm reasonably sure this configuration worked as desired with an earlier version of Postfix? Thanks Ed W
Re: Strange fix? Can't send mail externally but can send locally using Outlook 2003
William Jordan a écrit : [snip] Thanks /dev/rob0 I am searching through the archives now. What is odd is that this is not reproducible nor is it affecting any other user with Outlook 2003. check the configuration of outlook. make sure it is configured to authenticate. consider enabling the smtps service in master.cf. then you can configured outlook to use SSL (note smtps uses 465, not 25). Any way for now Thunderbird will suffice for this user. Though I doubt I will be able to force a conversion away from Outlook if this issue gets worse. Most likely we would lose PostFix first, which I do not think would be in our best interests at all. many people are using outlook with postfix. if you have a problem, find out the cause and fix it. moving to another MTA won't help.
Re: whitelisting problem
Stefan Förster put forth on 12/5/2009 6:16 AM: Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. If this isn't what you were looking for I don't have any idea what your question is. You're not seeing the forest for the trees. Look at my original post again. Within /etc/postfix/access there is a class C network listed with OK that matches the IP address of the rejected sending host. That should have caused the email to be accepted. Also, in smtpd_sender_restrictions, there is a whitelist entry in /etc/postfix/access that matches the sender address in the mail that was rejected. Once again, smtpd_sender_restrictions comes before smtpd_helo_restrictions in my main.cf, so even if for some unknown reason the client check whitelist entry failed, the sender check whitelist entry should have caused the email to be accepted. Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. How is everyone missing this? You're fixated on the darn error message. We all know what caused the error, a DNS lookup failure. That's not rocket science and has nothing to do with the problem. The problem is that the restriction processing order isn't being followed for some reason. Why isn't it? _THAT_ is the problem I'm asking for help with. That was clear in my first email, was it not? -- Stan
Re: whitelisting problem
Stan Hoeppner a écrit : I can't figure out why my whitelist entry for 204.238.179.0/24 is being ignored. If not for a transient DNS failure this afternoon I'd not have known this was broken. The check_client_access whitelist entry _should_ have triggered before reject_unknown_client_hostname. Any ideas why is doesn't/didn't? [snip] smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access reject_non_fqdn_helo_hostname reject_invalid_helo_hostname Look at this one: reject_unknown_helo_hostname [snip] ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? there is no check_client_access wihtelist in your smtpd_helo_restrictions, (before reject_unknown_helo_hostname). to avoid having to repeat your whitelists under every smtpd_mumble_restrictions, consider putting all your anti-spam checks under smtpd_recipient_restrictions. Also, avoid using a single /etc/postfix/access for different check_mumble_access. use one file per check (the checks are not looking for the same thing. so mixing the maps is not clean, and makes troubleshooting harder). smtpd_recipient_restrictions = reject_non_fqdn_sender reject_non_fqdn_recipient permit_mynetworks reject_unauth_destination # reject_unlisted_recipient reject_unlisted_sender # check_recipient_access hash:/etc/postfix/access_recipient check_client_access hash:/etc/postfix/access_client check_helo_access hash:/etc/postfix/access_helo check_sender_access hash:/etc/postfix/access_sender ... reject_unknown_client_hostname reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname # reject_rbl_client zen.spamhaus.org check_policy_service inet:127.0.0.1:6
Re: whitelisting problem
Stan Hoeppner a écrit : Stefan Förster put forth on 12/5/2009 6:16 AM: Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. If this isn't what you were looking for I don't have any idea what your question is. You're not seeing the forest for the trees. Look at my original post again. Within /etc/postfix/access there is a class C network listed with OK that matches the IP address of the rejected sending host. That should have caused the email to be accepted. Also, in smtpd_sender_restrictions, there is a whitelist entry in /etc/postfix/access that matches the sender address in the mail that was rejected. Once again, smtpd_sender_restrictions comes before smtpd_helo_restrictions in my main.cf, so even if for some unknown reason the client check whitelist entry failed, the sender check whitelist entry should have caused the email to be accepted. Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. you need to read the docs :) an OK in an smtpd_foo_restrictions skips further checks in _that_ restriction. so an OK in smtpd_client_restrictions skips further checks and goes to smtpd_helo_restrictions. for mail to be accepted, it needs to get an OK in _each_ restriction. by default, all but smtpd_recipient_restrictions return OK, but since you edited yours... This is why I suggested (in my previous post) that you put all your checks under smtpd_recipient_restrictions. Among other things, this avoids the need to duplicate whitelisting actions. [snip]
Re: whitelisting problem
* Stan Hoeppner s...@hardwarefreak.com: Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. The order in which checks are evaluated is the one in which the criterion to be checkd is made available to Postfix: 1. client IP address 2. HELO hostname 3. MAIL FROM aka sender 4. RCPT TO, aka recipient(s) 5. DATA 6. . How is everyone missing this? You're fixated on the darn error message. We all know what caused the error, a DNS lookup failure. That's not rocket science and has nothing to do with the problem. The problem is that the restriction processing order isn't being followed for some reason. Why isn't it? _THAT_ is the problem I'm asking for help with. That was clear in my first email, was it not? Postfix behaves according to the documentation. The documentation doesn't say that an OK from a check_client_access results in an OK for the HELO restrictions. And no, it was not clear from your first posting that you had a serious misunderstanding of how Postfix access control works. Your first posting simply suggested that you worked a whole night, couldn't barely keep your eyes open (5:46am) and therefore mixed check_recipient_access with check_client_access in your smtpd_helo_restrictions. Stefan
Re: whitelisting problem
Stan Hoeppner wrote: Michael Orlitzky put forth on 12/5/2009 1:38 AM: Stan Hoeppner wrote: I can't figure out why my whitelist entry for 204.238.179.0/24 is being You rejected the HELO hostname, not the IP address. What is reject_unknown_helo_hostname going to do when your DNS is broken? You missed the point entirely because you went after the low hanging fruit, calling out you read the rejection wrong!. Re-read my email and tell me why there was a rejection at all; why the email wasn't accepted as it should have been. If you'd actually read my entire email the first time, you wouldn't have answered as you did. You'll likely have to go for the fruit at the top of the tree to get the right answer. I've been on the top branch all day and can't figure it out, thus my email to the list. -- Stan Let's start from the beginning. Here's your access map: /etc/postfix/access ... 66.135.197 OK 168.100.1 OK 204.238.179 OK spam-l-boun...@spam-l.com OK owner-postfix-us...@cloud9.net OK majordomo-ow...@cloud9.net OK owner-postfix-us...@postfix.org OK ... Now, a client connects. Your restrictions begin to be evaluated. The first class to get evaluated is smtpd_client_restrictions: smtpd_client_restrictions = check_recipient_access hash:/etc/postfix/access check_client_access hash:/etc/postfix/access ... ... reject_unknown_client_hostname reject_unauth_pipelining Here, check_recipient_access does nothing, because the recipient (you) is not listed in the access map. The next restriction, check_client_access, matches on the client, 204.238.179.8. A result of OK is returned for smtpd_client_restrictions, and we move on to smtpd_helo_restrictions. smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname The first restriction, check_recipient_access, looks up the RECIPIENT'S ADDRESS in your access map. Since the recipient's address is not listed, this check does nothing, and we move on the next one. The non_fqdn/invalid checks pass, but then when we get to reject_unknown_helo_hostname, the message is rejected, because you can't look up the host name. I think what you mean to do here is check_client_access (as opposed to check_recipient_access). You could also use check_helo_access, but then you'd have to add that machine's HELO hostname to the access map.
Re: remote_header_rewrite_domain ignored
Ed W: Wietse Venema wrote: Ed W: Hi, I'm using postfix 2.5.7 and having some trouble with the server domain being appended to incomplete sender addresses. I have set # postconf|grep -e rewrite -e append -e myorigin -e mydomain -e local_header append_at_myorigin = yes append_dot_mydomain = no local_header_rewrite_clients = Note: local_***HEADER***_rewrite_clients, a feature that controls how HEADER address are rewritten. Fair enough - can you please help correct my config given the original goal of avoiding incomplete email addresses having a domain automatically appended? If an address has no domain, then by definition it delivers to the same destination as when the default domain were appended. Therefore, both address forms are equivalent. Therefore, Postfix uses the same address form for both, instead of doubling the number of configuration options (and code) for address forms that are by definition equivalent. Wietse
Re: remote_header_rewrite_domain ignored
Ed W: To clarify the question - the goal is if someone connects via the network (not local sendmail command) and the transcript says RCPT TO: asdf that this is subsequently bounced as being an invalid To summarize my other response, by definition an address without domain delivers to the same mailbox as an address with the default domain. Wietse
Re: remote_header_rewrite_domain ignored
Wietse Venema wrote: Ed W: To clarify the question - the goal is if someone connects via the network (not local sendmail command) and the transcript says RCPT TO: asdf that this is subsequently bounced as being an invalid To summarize my other response, by definition an address without domain delivers to the same mailbox as an address with the default domain. Understood - but, how can I change this please..? (and if there are hidden implications, please summarise so that I can test for breakage?) If this is not possible then can I please make a feature request for this? At least in the case of my users it's almost exclusively a typo (autocomplete gremlin due to Microsoft email programs..) and not intended for delivery to the local mail server (in my case it results in lack of feedback and hence backpressure to correct the typos and also a slight privacy issue in that emails are getting delivered to the wrong user rather than being bounced as undeliverable) Thanks for any help? Ed W
Re: remote_header_rewrite_domain ignored
Ed W a écrit : Wietse Venema wrote: Ed W: To clarify the question - the goal is if someone connects via the network (not local sendmail command) and the transcript says RCPT TO: asdf that this is subsequently bounced as being an invalid To summarize my other response, by definition an address without domain delivers to the same mailbox as an address with the default domain. Understood - but, how can I change this please..? (and if there are hidden implications, please summarise so that I can test for breakage?) If this is not possible then can I please make a feature request for this? At least in the case of my users it's almost exclusively a typo (autocomplete gremlin due to Microsoft email programs..) and not intended for delivery to the local mail server (in my case it results in lack of feedback and hence backpressure to correct the typos and also a slight privacy issue in that emails are getting delivered to the wrong user rather than being bounced as undeliverable) Thanks for any help? Ed W look for reject_non_fqdn_sender reject_non_fqdn_recipient
smtp_enforce_tls on submission tcp/587 only
I am trying to force submission (with SMTP auth via SASL) clients on tcp/587 to use TLS. Is there anyway to do this? I ran across smtp_enforce_tls, but this seems to force any and all SMTP clients to use TLS which is not what I want (this is a public facing machine). Will I need to implement some type of submission policy like this or am I understanding the policy structure incorrectly? snip from http://www.postfix.org/TLS_README.html /etc/postfix/main.cf: smtp_tls_policy_maps = hash:/etc/postfix/tls_policy /etc/services: submission 587/tcp msa # mail message submission /etc/postfix/tls_policy: [example.net]:587 encrypt protocols=TLSv1 ciphers=high [example.net]:msa encrypt protocols=TLSv1 ciphers=high [example.net]:submission encrypt protocols=TLSv1 ciphers=high /snip from http://www.postfix.org/TLS_README.html kind regards, Terry
Re: smtp_enforce_tls on submission tcp/587 only
Terry L. Inzauro wrote: I am trying to force submission (with SMTP auth via SASL) clients on tcp/587 to use TLS. Is there anyway to do this? I ran across smtp_enforce_tls, but this seems to force any and all SMTP clients to use TLS which is not what I want (this is a public facing machine). Will I need to implement some type of submission policy like this or am I understanding the policy structure incorrectly? snip from http://www.postfix.org/TLS_README.html /etc/postfix/main.cf: smtp_tls_policy_maps = hash:/etc/postfix/tls_policy /etc/services: submission 587/tcp msa # mail message submission /etc/postfix/tls_policy: [example.net]:587 encrypt protocols=TLSv1 ciphers=high [example.net]:msa encrypt protocols=TLSv1 ciphers=high [example.net]:submission encrypt protocols=TLSv1 ciphers=high /snip from http://www.postfix.org/TLS_README.html kind regards, Terry never mind. i asked too soon. looks like smtpd_tls_auth_only = yes does the trick. Thanks for the great product and stellar community support. Keep up the good work. Happy Holidays to all. _Terry
Re: remote_header_rewrite_domain ignored
On Sat, 05 Dec 2009 15:36:06 + Ed W li...@wildgooses.com replied: If this is not possible then can I please make a feature request for this? At least in the case of my users it's almost exclusively a typo (autocomplete gremlin due to Microsoft email programs..) and not intended for delivery to the local mail server (in my case it results in lack of feedback and hence backpressure to correct the typos and also a slight privacy issue in that emails are getting delivered to the wrong user rather than being bounced as undeliverable) I believe it to be self evident that the source of the affliction that you are experiencing can be best described by the acronym: PEBKAC. Microsoft has nothing to do with it. -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html The avoidance of taxes is the only intellectual pursuit that carries any reward. John Maynard Keynes
Re: remote_header_rewrite_domain ignored
Ed W: Wietse Venema wrote: Ed W: To clarify the question - the goal is if someone connects via the network (not local sendmail command) and the transcript says RCPT TO: asdf that this is subsequently bounced as being an invalid To summarize my other response, by definition an address without domain delivers to the same mailbox as an address with the default domain. Understood - but, how can I change this please..? (and if there are hidden implications, please summarise so that I can test for breakage?) If you don't want to receive mail for domain-less addresses then say so, instead of coming up with the wrong solution for the wrong problem. Use the reject_non_fqdn_mumble to stop bare addresses. Wietse
PATCH: smtpd_proxy logging (was: Snapshot 20091109, queue disk partition ...)
On Fri, Dec 04, 2009 at 08:54:01PM +0100, Stefan F??rster wrote:
Now, about logging - I'd be really grateful if the existing logging
functionality could be extended in a way so that the pre-queue
content filter's response is logged.
I know that it is actually the content filter's job to log what it did
during an ESMTP transaction, but I think if Postfix logged the
filter's response, correlating logs would be much easier.
Like this?
Dec 5 20:15:25 server postfix/smtpd[16712]: proxy-accept:
END-OF-MESSAGE: 250 2.0.0 Ok: queued as 91BE3547AFE;
from=sen...@example.com to=recipi...@example.com proto=ESMTP
helo=client.example.com
(with the same form for proxy-reject at END-OF-MESSAGE; the format
of the reject message would be consistent with other Postfix reject
messages.)
Wietse
diff --exclude=man --exclude=html --exclude=README_FILES --exclude=.indent.pro
--exclude=Makefile.in -r -cr /var/tmp/postfix-2.7-20091115/src/smtpd/smtpd.c
./smtpd.c
*** /var/tmp/postfix-2.7-20091115/src/smtpd/smtpd.c Sun Nov 15 10:34:24 2009
--- ./smtpd.c Sat Dec 5 20:16:33 2009
***
*** 1353,1358
--- 1353,1379
#endif
+ /* smtpd_whatsup - gather available evidence for logging */
+
+ static const char *smtpd_whatsup(SMTPD_STATE *state)
+ {
+ static VSTRING *buf = 0;
+
+ if (buf == 0)
+ buf = vstring_alloc(100);
+ else
+ VSTRING_RESET(buf);
+ if (state-sender)
+ vstring_sprintf_append(buf, from=%s, state-sender);
+ if (state-recipient)
+ vstring_sprintf_append(buf, to=%s, state-recipient);
+ if (state-protocol)
+ vstring_sprintf_append(buf, proto=%s, state-protocol);
+ if (state-helo_name)
+ vstring_sprintf_append(buf, helo=%s, state-helo_name);
+ return (STR(buf));
+ }
+
/* collapse_args - put arguments together again */
static void collapse_args(int argc, SMTPD_TOKEN *argv)
***
*** 3097,3102
--- 3103,3116
}
/*
+ * By popular command: the proxy's end-of-data reply.
+ */
+ if (proxy)
+ msg_info(proxy-%s: %s: %s;%s,
+(state-err == CLEANUP_STAT_OK) ? accept : reject,
+state-where, STR(proxy-buffer), smtpd_whatsup(state));
+
+ /*
* Cleanup. The client may send another MAIL command.
*/
saved_err = state-err;
Re: whitelisting problem
On Sat, Dec 05, 2009 at 05:34:03AM -0600, Stan Hoeppner wrote: You'll likely have to go for the fruit at the top of the tree to get the right answer. I've been on the top branch all day and can't figure it out, thus my email to the list. Climb down from the tree. Your answer was among the fallen fruit laying on the ground. Everyone in this thread but you seems to understand what happened. This is a classic example of why it's generally better to keep your restrictions in ONE STAGE unless you have a good reason not to, and of course, a good understanding of how multiple restriction stages wok (independently of one another: the simple fact that was lying beneath the tree, rotting.) ANY rejection in ANY stage means the mail is rejected. Doesn't matter how many whitelists you check in other stages. You forgot it in one that mattered. When whitelisting in smtpd_recipient_restrictions, be careful with how it's done. Use permit_auth_destination rather than OK unless you really did intend to allow relaying. The same thing can be done with whitelisting restrictions after reject_unauth_destination. Also give heed to mouss' advice about splitting up the access maps by type of lookup. No point in listing IP addresses in a sender or HELO lookup map. No point in listing email addresses in a client lookup map. Domain names can be in any, but are you sure you want to do the same thing for any of client, helo, sender and recipient lookups? This post might seem like a gratuitous me-too, and it partly is, but the thing that concerned me, as one of the people responsible for the Spam-L list, was the rejection, in the original post: Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Unknown? Here's what I get: 8.179.238.204.in-addr.arpa. 3600 IN PTR mx1.mfn.org. mx1.mfn.org.14400 IN A 204.238.179.8 That looks like perfect FCrDNS to me. So another issue you ought to look at: why is your resolver failing on this? Is it consistent? -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: whitelisting problem
mouss put forth on 12/5/2009 7:50 AM: you need to read the docs :) Isn't that always the case here. :) an OK in an smtpd_foo_restrictions skips further checks in _that_ restriction. so an OK in smtpd_client_restrictions skips further checks and goes to smtpd_helo_restrictions. Aha! Thanks mouss. I was under the assumption that first match wins means exactly that. I thought _all_ other checks were skipped after an OK. for mail to be accepted, it needs to get an OK in _each_ restriction. by default, all but smtpd_recipient_restrictions return OK, but since you edited yours... So, first match wins only applies within a restriction class. Missed that in the docs during previous reads. This is why I suggested (in my previous post) that you put all your checks under smtpd_recipient_restrictions. Among other things, this avoids the need to duplicate whitelisting actions. Sanity checking and ease of troubleshooting is precisely why I'd kept them separated for years, so each check type was in its respective class heading. I guess given the things I'm doing with my static lists, it makes no sense to continue my current method, given it makes the troubleshooting _more_ difficult... Thanks again mouss. -- Stan
Re: whitelisting problem
Stefan Förster put forth on 12/5/2009 8:51 AM: * Stan Hoeppner s...@hardwarefreak.com: Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. The order in which checks are evaluated is the one in which the criterion to be checkd is made available to Postfix: 1. client IP address 2. HELO hostname 3. MAIL FROM aka sender 4. RCPT TO, aka recipient(s) 5. DATA 6. . How is everyone missing this? You're fixated on the darn error message. We all know what caused the error, a DNS lookup failure. That's not rocket science and has nothing to do with the problem. The problem is that the restriction processing order isn't being followed for some reason. Why isn't it? _THAT_ is the problem I'm asking for help with. That was clear in my first email, was it not? Postfix behaves according to the documentation. The documentation doesn't say that an OK from a check_client_access results in an OK for the HELO restrictions. And no, it was not clear from your first posting that you had a serious misunderstanding of how Postfix access control works. Your first posting simply suggested that you worked a whole night, couldn't barely keep your eyes open (5:46am) and therefore mixed check_recipient_access with check_client_access in your smtpd_helo_restrictions. Nah, as I said to mouss, I was under the assumption that first match wins meant all other class checks were ignored. Given that, you can understand why I was pulling my hair out trying to identify the problem. Thanks for your patience. -- Stan
Re: whitelisting problem
Michael Orlitzky put forth on 12/5/2009 9:03 AM: I think what you mean to do here is check_client_access (as opposed to check_recipient_access). You could also use check_helo_access, but then you'd have to add that machine's HELO hostname to the access map. The reason for the check_recipient_access everyone is for two spam trap addresses that are intentionally omitted from my post. I did that upon someone's recommendation long ago without realizing the reason for it: first match wins is _per_ restriction class, not across all classes. Thanks for assisting. -- Stan
Re: whitelisting problem
Sahil Tandon put forth on 12/5/2009 1:49 PM: Why the hostility? Frustration, lack of rest, likely. Apologies. The others are just trying to help. :) Mouss already answered your question correctly, but you should review: http://www.postfix.org/SMTPD_ACCESS_README.html to understand how restriction lists are evaluated. I understand now, didn't then. Thanks for the link. Have read it at least twice (man) but apparently never grasped the per class issue. I've definitely got it now lol! -- Stan
Re: whitelisting problem
/dev/rob0 put forth on 12/5/2009 8:44 PM: This post might seem like a gratuitous me-too, and it partly is, but the thing that concerned me, as one of the people responsible for the Spam-L list, was the rejection, in the original post: Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Unknown? Here's what I get: 8.179.238.204.in-addr.arpa. 3600 IN PTR mx1.mfn.org. mx1.mfn.org.14400 IN A 204.238.179.8 That looks like perfect FCrDNS to me. So another issue you ought to look at: why is your resolver failing on this? Is it consistent? Yeah, I know. Already chatted with Alif about it. This 450 temp fail is what started all of this. I still got the mail obviously, but I wanted to figure out why my white list entry for spam-l didn't trigger. Thanks to many here, I now know why and am fixing it. It's looking like I was having transient issues with my resolvers. I did some more log digging and found more dns related temp fails than I should be having given my mail volume. I've since switched from the old resolvers to the new free Google resolvers. So far so good. If I run into problems there, I'll switch again or setup my own caching resolver. -- Stan
