Re: whitelisting problem

[Stan Hoeppner]

/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 : Helo command
>> rejected: Host not found; from=
>> to= proto=ESMTP helo=
> 
> 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

Re: whitelisting problem

[Stan Hoeppner]

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

[Stan Hoeppner]

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

[Stan Hoeppner]

Stefan Förster put forth on 12/5/2009 8:51 AM:
> * Stan Hoeppner :
>> 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

[Stan Hoeppner]

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

[/dev/rob0]

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 : Helo command
> rejected: Host not found; from=
> to= proto=ESMTP helo=

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

PATCH: smtpd_proxy logging (was: Snapshot 20091109, queue disk partition ...)

[Wietse Venema]

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= to= proto=ESMTP
helo=

(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: remote_header_rewrite_domain ignored

[Wietse Venema]

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: 
> >> " 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

Re: whitelisting problem

[Sahil Tandon]

On Sat, 05 Dec 2009, Stan Hoeppner wrote:

> 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?

Why the hostility?  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.

-- 
Sahil Tandon 

Re: remote_header_rewrite_domain ignored

[Jerry]

On Sat, 05 Dec 2009 15:36:06 +
Ed W  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: smtp_enforce_tls on submission tcp/587 only

[Terry L. Inzauro]

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?
> 
> 
> 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
> 
> 
> 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

smtp_enforce_tls on submission tcp/587 only

[Terry L. Inzauro]

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?


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


http://www.postfix.org/TLS_README.html>


kind regards,


Terry

Re: remote_header_rewrite_domain ignored

[mouss]

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: 
>>> " 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

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: 
" 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

[Wietse Venema]

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: 
> " 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]

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: whitelisting problem

[Michael Orlitzky]

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: whitelisting problem

[Stefan Förster]

* Stan Hoeppner :
> 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

[mouss]

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

[mouss]

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 : Helo command rejected:
> Host not found; from=
> to= proto=ESMTP helo=
> 
> 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]

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: Strange fix? Can't send mail externally but can send locally using Outlook 2003

[mouss]

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: remote_header_rewrite_domain ignored

[Ed W]

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: 
" 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: 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?


Thanks

Ed W

Re: sender_dependent_relayhost_maps and ldap with multivalue attribute

[Giovanni Mancuso]

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: whitelisting problem

[Stefan Förster]

* Stefan Förster :
> Rejection message:
> 
> | Dec  4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from
> | unknown[204.238.179.8]: 450 4.7.1 : Helo command rejected:
> | Host not found; from=
> | to= proto=ESMTP helo=
> 
> 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: whitelisting problem

[Stefan Förster]

Hallo Stan,

* Stan Hoeppner :
> Stefan Förster put forth on 12/5/2009 5:46 AM:
> > * Stan Hoeppner :
> >> 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 : Helo command rejected:
| Host not found; from=
| to= proto=ESMTP helo=

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

[Stan Hoeppner]

Stefan Förster put forth on 12/5/2009 5:46 AM:
> * Stan Hoeppner :
>> 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

[Stefan Förster]

* Stan Hoeppner :
> 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 : Helo command rejected:
> Host not found; from=
> to= proto=ESMTP helo=
> 
> Any clues as to what's wrong?
> 
> --
> Stan

Re: whitelisting problem

[Stan Hoeppner]

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 : Helo command rejected:
>> Host not found; from=
>> to= proto=ESMTP helo=
>>
>> 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