Hi Stan,
On Wed, 09 Dec 2009 21:24:53 -0600
Stan Hoeppner wrote:
> Mikael Bak put forth on 12/9/2009 4:18 AM:
>
> > I understand why you avoid the real question. But hey - it's your server :-)
>
> Do you? I have avoided it because these threads can quickly delve into
> childish mud slinging i
Mikael Bak put forth on 12/9/2009 4:18 AM:
> I understand why you avoid the real question. But hey - it's your server :-)
Do you? I have avoided it because these threads can quickly delve into
childish mud slinging if the participants aren't civil thoughtful
adults. I'm assuming we are all civi
John Peach put forth on 12/9/2009 7:03 AM:
> On Wed, 09 Dec 2009 03:58:28 -0600
> Stan Hoeppner wrote:
>
> [snip]
>> Two words: LIST MAIL. When you reply directly to senders, all kinds
>> of unpleasant things can happen. Keep replies on list only and you
>> can avoid seeing some of the draconi
Stan Hoeppner a écrit :
> Mikael Bak put forth on 12/8/2009 3:31 AM:
>> mouss wrote:
>>> I'm looking through you, where did you go:
>>>
>>> : host greer.hardwarefreak.com[65.41.216.221]
>>> said: 554 5.7.1 : Client host
>>> rejected: Access denied (in reply to RCPT TO command)
>>>
>>> It is nice to
On Wed, 09 Dec 2009 03:58:28 -0600
Stan Hoeppner wrote:
[snip]
> Two words: LIST MAIL. When you reply directly to senders, all kinds
> of unpleasant things can happen. Keep replies on list only and you
> can avoid seeing some of the draconian things folks do.
>
setting the reply-to header hel
Stan Hoeppner wrote:
> Mikael Bak put forth on 12/8/2009 3:31 AM:
>> mouss wrote:
>>> I'm looking through you, where did you go:
>>>
>>> : host greer.hardwarefreak.com[65.41.216.221]
>>> said: 554 5.7.1 : Client host
>>> rejected: Access denied (in reply to RCPT TO command)
>>>
>>> It is nice to no
Mikael Bak put forth on 12/8/2009 3:31 AM:
> mouss wrote:
>> I'm looking through you, where did you go:
>>
>> : host greer.hardwarefreak.com[65.41.216.221]
>> said: 554 5.7.1 : Client host
>> rejected: Access denied (in reply to RCPT TO command)
>>
>> It is nice to not reject mail from people who h
lst_ho...@kwsoft.de wrote:
> Zitat von Mikael Bak :
>>
>> I could not agree more. I got this from him:
>>
>> : host greer.hardwarefreak.com[65.41.216.221]
>> said: 554 5.7.1 : Client host rejected:
>> Mail not accepted from Hungary (in reply to RCPT TO command)
>>
>> Maybe he thinks nobody in Hunga
Zitat von Mikael Bak :
mouss wrote:
I'm looking through you, where did you go:
: host greer.hardwarefreak.com[65.41.216.221]
said: 554 5.7.1 : Client host
rejected: Access denied (in reply to RCPT TO command)
It is nice to not reject mail from people who help you...
I could not agree more.
mouss wrote:
>
> I'm looking through you, where did you go:
>
> : host greer.hardwarefreak.com[65.41.216.221]
> said: 554 5.7.1 : Client host
> rejected: Access denied (in reply to RCPT TO command)
>
> It is nice to not reject mail from people who help you...
I could not agree more. I got this
On Mon, 07 Dec 2009, Stan Hoeppner wrote:
> mouss put forth on 12/7/2009 3:52 PM:
>
> > I'm looking through you, where did you go:
> >
> > : host greer.hardwarefreak.com[65.41.216.221]
> > said: 554 5.7.1 : Client host
> > rejected: Access denied (in reply to RCPT TO command)
> >
> > It is nice
mouss put forth on 12/7/2009 3:52 PM:
> I'm looking through you, where did you go:
>
> : host greer.hardwarefreak.com[65.41.216.221]
> said: 554 5.7.1 : Client host
> rejected: Access denied (in reply to RCPT TO command)
>
> It is nice to not reject mail from people who help you...
Sorry 'bout
Sta[snip]
> 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
> t
Stan Hoeppner a écrit :
> 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
Stan Hoeppner a écrit :
> /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 gree
On Sat, 05 Dec 2009 21:32:02 -0600
Stan Hoeppner wrote:
> 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 ne
/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:
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 ho
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_recipien
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_
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! Tha
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 f
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
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?
Yo
* 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_
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 questio
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_hostn
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 for
* 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:
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
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
* 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
>
>
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_
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
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/d
35 matches
Mail list logo
