On Wed, 09 Jul 2008 16:02:44 GMT, Unruh wrote:
> I have just installed Mandraka 2008.1 and they have set up postfix so that
> errors like the enclosed are reported to email to postmaster.

Hmmm, I never saw that problem.
Then again, I modify the aliases file.

$ tail -12 /etc/postfix/aliases | head -5

# Person who should get root's mail. This alias
# must exist.
# CHANGE THIS LINE to an account of a HUMAN
root: bittwister


Then run postalias and service postfix restart

That sends all postmaster emails to me because of the default
postmaster: root
directive in aliases.

On Wed, 09 Jul 2008 12:02:44 -0400, Unruh wrote:

> Out: 451 4.3.5 Server configuration error

Looks to me like there's something in /etc/postfix/main.cf, or the directory
structure/ownership, that postfix doesn't like. Is there anything in
/var/log/mail/errors.log?

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Wed, 09 Jul 2008 16:02:44 GMT,
Unruh wrote:

> I have just installed Mandraka 2008.1 and they have set up postfix so
> that errors like the enclosed are reported to email to postmaster.
> This totally swamps the mail box. How do I shut it off? This is an
> insane use of mail reporting! (I could of course set up procmail to
> discard all such mail, but that would clearly be kludge and I should
> be able to switch the mail reporting off in postfix.
> -------------------------------------------------------------
>
> From: MAILER-DAEMON@physics.ubc.ca (Mail Delivery System)
> To: postmaster@physics.ubc.ca (Postmaster)
> Subject: Postfix SMTP server: errors from
> UNTRUST.OIZURU-FW.OIZURU.CO.TH[116.68.154.226]
> Message-Id: <20080709154837.972C7E8239@info.physics.ubc.ca>
> Transcript of session follows.
>
> Out: 220 info.physics.ubc.ca ESMTP Postfix (2.5.1) (Mandrake Linux)
> In: EHLO UNTRUST.OIZURU-FW.OIZURU.CO.TH
> Out: 250-info.physics.ubc.ca
> Out: 250-PIPELINING
> Out: 250-SIZE 10240000
> Out: 250-VRFY
> Out: 250-ETRN
> Out: 250-ENHANCEDSTATUSCODES
> Out: 250-8BITMIME
> Out: 250 DSN
> In: MAIL From:
> Out: 250 2.1.0 Ok
> In: RCPT To:
> Out: 451 4.3.5 Server configuration error
> In: DATA
> Out: 554 5.5.1 Error: no valid recipients
>
> Session aborted, reason: lost connection

In glancing through 2008.1's "/etc/postfix/main.cf.default" file, I see
that there is the following parameter defined there:

error_notice_recipient = postmaster

I suspect that if you were to add said parameter to your main.cf file,
but left the definition portion blank ("error_notice_recipient ="),
this would put an end to these sorts of messages. However, that may or
may not be the optimum solution in this instance.

If the "RCPT To:" address in the report is in fact a valid one, and so
Postfix had rejected the mail in error, that's certainly worth knowing
about; moreover, I find the status response "4.3.5 Server configuration
error" that it issued to be more than a little curious.

Perhaps one good approach would be to add the parameter to main.cf, but
rather than leave it empty, assign it to some other mailbox that would
only be used for this purpose. You could then accomplish the task of
separating out these messages from the rest of the ones that are bound
for the inbox of whomever receives root's mail, while still retaining
them temporarily as whatever remaining configuration issues there may
be are getting sorted out, so that you can see from how they change
over time just what effects your own config changes have wrought. You
could even have said mailbox deleted periodically by a cron job, so
that only the most recent of these are kept available for inspection.

HTH!

--
Bill Mullen
RLU #270075

"David W. Hodgins" writes:

>On Wed, 09 Jul 2008 12:02:44 -0400, Unruh wrote:

>> Out: 451 4.3.5 Server configuration error

>Looks to me like there's something in /etc/postfix/main.cf, or the directory
>structure/ownership, that postfix doesn't like. Is there anything in
>/var/log/mail/errors.log?

No that error report IS a report of an invalid recipient. Regular mail to
real recipients actually does get through fine. HOwever since my system
gets bombarded by junk messages to ancient or invalid recipients (a user
similar to the recipient reported in that message was here 15 years ago,
but the memory in spam lists is infinite) this means I get such invalid
address recipient mail maybe 1000 times a day. And getting 1000 emails from
SNTP like that is simply unacceptable.


>Regards, Dave Hodgins

>--
>Change nomail.afraid.org to ody.ca to reply by email.
>(nomail.afraid.org has been set up specifically for
>use in usenet. Feel free to use it yourself.)

Bill Mullen writes:

>On Wed, 09 Jul 2008 16:02:44 GMT,
>Unruh wrote:

>> I have just installed Mandraka 2008.1 and they have set up postfix so
>> that errors like the enclosed are reported to email to postmaster.
>> This totally swamps the mail box. How do I shut it off? This is an
>> insane use of mail reporting! (I could of course set up procmail to
>> discard all such mail, but that would clearly be kludge and I should
>> be able to switch the mail reporting off in postfix.
>> -------------------------------------------------------------
>>
>> From: MAILER-DAEMON@physics.ubc.ca (Mail Delivery System)
>> To: postmaster@physics.ubc.ca (Postmaster)
>> Subject: Postfix SMTP server: errors from
>> UNTRUST.OIZURU-FW.OIZURU.CO.TH[116.68.154.226]
>> Message-Id: <20080709154837.972C7E8239@info.physics.ubc.ca>
>> Transcript of session follows.
>>
>> Out: 220 info.physics.ubc.ca ESMTP Postfix (2.5.1) (Mandrake Linux)
>> In: EHLO UNTRUST.OIZURU-FW.OIZURU.CO.TH
>> Out: 250-info.physics.ubc.ca
>> Out: 250-PIPELINING
>> Out: 250-SIZE 10240000
>> Out: 250-VRFY
>> Out: 250-ETRN
>> Out: 250-ENHANCEDSTATUSCODES
>> Out: 250-8BITMIME
>> Out: 250 DSN
>> In: MAIL From:
>> Out: 250 2.1.0 Ok
>> In: RCPT To:
>> Out: 451 4.3.5 Server configuration error
>> In: DATA
>> Out: 554 5.5.1 Error: no valid recipients
>>
>> Session aborted, reason: lost connection

>In glancing through 2008.1's "/etc/postfix/main.cf.default" file, I see
>that there is the following parameter defined there:

>error_notice_recipient = postmaster

>I suspect that if you were to add said parameter to your main.cf file,
>but left the definition portion blank ("error_notice_recipient ="),
>this would put an end to these sorts of messages. However, that may or
>may not be the optimum solution in this instance.

>If the "RCPT To:" address in the report is in fact a valid one, and so
>Postfix had rejected the mail in error, that's certainly worth knowing
>about; moreover, I find the status response "4.3.5 Server configuration
>error" that it issued to be more than a little curious.

Nope the recipient IS an ivalid address. It is a munging of the name of
someone who was here 15 years ago, but spam lists have an infinite memory.

Yes, I have no idea why it is reporting Server Configuration error for an
invalid recipient. Is there something I should be setting up in aliases to
handle invalid recipients? Note that this is first time I have seen this
with postfix. My 2007.0 and 2007.1 Mandriva systems never reported errors
like this, so there seems to have been some change in postfix.


>Perhaps one good approach would be to add the parameter to main.cf, but
>rather than leave it empty, assign it to some other mailbox that would
>only be used for this purpose. You could then accomplish the task of
>separating out these messages from the rest of the ones that are bound
>for the inbox of whomever receives root's mail, while still retaining
>them temporarily as whatever remaining configuration issues there may
>be are getting sorted out, so that you can see from how they change
>over time just what effects your own config changes have wrought. You
>could even have said mailbox deleted periodically by a cron job, so
>that only the most recent of these are kept available for inspection.

Thanks good idea.


>HTH!

>--
>Bill Mullen
>RLU #270075

On Wed, 09 Jul 2008 21:15:15 GMT, Unruh wrote:

> Is there something I should be setting up in aliases to
> handle invalid recipients?

No. Your aliases file is just a mapping of generic name to a person.
To see generic names
grep : aliases

Guessing you need to create a local user database of who to accept
and just drop it if they are not in the database.

Quick search turned up
http://www.seaglass.com/postfix/faq.html#ubenousr

No telling what could be found
http://groups.google.com/advanced_search
Results 1 - 10 of about 335,000 for unknown postfix

Unruh writes:

>Bill Mullen writes:

>>On Wed, 09 Jul 2008 16:02:44 GMT,
>>Unruh wrote:

>>> I have just installed Mandraka 2008.1 and they have set up postfix so
>>> that errors like the enclosed are reported to email to postmaster.
>>> This totally swamps the mail box. How do I shut it off? This is an
>>> insane use of mail reporting! (I could of course set up procmail to
>>> discard all such mail, but that would clearly be kludge and I should
>>> be able to switch the mail reporting off in postfix.
>>> -------------------------------------------------------------
>>>
>>> From: MAILER-DAEMON@physics.ubc.ca (Mail Delivery System)
>>> To: postmaster@physics.ubc.ca (Postmaster)
>>> Subject: Postfix SMTP server: errors from
>>> UNTRUST.OIZURU-FW.OIZURU.CO.TH[116.68.154.226]
>>> Message-Id: <20080709154837.972C7E8239@info.physics.ubc.ca>
>>> Transcript of session follows.
>>>
>>> Out: 220 info.physics.ubc.ca ESMTP Postfix (2.5.1) (Mandrake Linux)
>>> In: EHLO UNTRUST.OIZURU-FW.OIZURU.CO.TH
>>> Out: 250-info.physics.ubc.ca
>>> Out: 250-PIPELINING
>>> Out: 250-SIZE 10240000
>>> Out: 250-VRFY
>>> Out: 250-ETRN
>>> Out: 250-ENHANCEDSTATUSCODES
>>> Out: 250-8BITMIME
>>> Out: 250 DSN
>>> In: MAIL From:
>>> Out: 250 2.1.0 Ok
>>> In: RCPT To:
>>> Out: 451 4.3.5 Server configuration error
>>> In: DATA
>>> Out: 554 5.5.1 Error: no valid recipients
>>>
>>> Session aborted, reason: lost connection

>>In glancing through 2008.1's "/etc/postfix/main.cf.default" file, I see
>>that there is the following parameter defined there:

>>error_notice_recipient = postmaster

>>I suspect that if you were to add said parameter to your main.cf file,
>>but left the definition portion blank ("error_notice_recipient ="),
>>this would put an end to these sorts of messages. However, that may or
>>may not be the optimum solution in this instance.

>>If the "RCPT To:" address in the report is in fact a valid one, and so
>>Postfix had rejected the mail in error, that's certainly worth knowing
>>about; moreover, I find the status response "4.3.5 Server configuration
>>error" that it issued to be more than a little curious.

>Nope the recipient IS an ivalid address. It is a munging of the name of
>someone who was here 15 years ago, but spam lists have an infinite memory.

>Yes, I have no idea why it is reporting Server Configuration error for an
>invalid recipient. Is there something I should be setting up in aliases to
>handle invalid recipients? Note that this is first time I have seen this
>with postfix. My 2007.0 and 2007.1 Mandriva systems never reported errors
>like this, so there seems to have been some change in postfix.


Hmm, I discovered that in copying from a prior installation, I had the line

smtpd_recipient_restrictions =
permit_mynetworks
check_recipient_access reject_unauth_destination

in the file, but there was an error message in /var/log/syslog that seemed
to suggest that the check_recipient_access needed an argument. I have
commented out all those lines, and so far it seems no more error reports.
So it looks like it was a configuration error.

It would be nice if the postfix error reports were more helpful than they
are.
Thanks again.

On Wed, 09 Jul 2008 21:15:15 GMT,
Unruh wrote:

> Yes, I have no idea why it is reporting Server Configuration error
> for an invalid recipient.

Nor do I. But it's definitely not saying at this point in the process
that it realizes that the address itself is invalid. From RFC 3463:

X.3.5 System incorrectly configured

The system is not configured in a manner that will permit it to
accept this message.

The "4" in place of the "X" above indicates that Postfix considers this
to be a temporary error, so the sender should try again later. Had it
correctly identified at this stage that the address was bad, I would
have expected it to send a code of 5.1.1:

X.1.1 Bad destination mailbox address

The mailbox specified in the address does not exist. For
Internet mail names, this means the address portion to the left
of the "@" sign is invalid. This code is only useful for
permanent failures.

The leading "5" would mark it as a permanent error, don't resend later.

It would seem that these error-related mails are most likely due to the
as-yet unknown config problem that has generated the 4.3.5 code; I see
from examination of my MDV 2007.1 system that the default definition for
the error_notice_recipient parameter is exactly the same on there as it
is on MDV 2008.1. I think that Bit Twister, as is his custom, is on the
right track when he suggests that you look into those aspects of your
current config that pertain to rejection of invalid addressees. I use
the default value for local_recipient_maps, which BTW has also not been
changed at all between the 2007.1 and 2008.1 versions.

Have you modified the "smtpd_recipient_restrictions" parameter from the
(also unchanged 2007.1->2008.1) default? While the local_recipient_maps
one will affect how it decides what is and isn't a valid local address,
the smtpd_recipient_restrictions one will tell it what to do once it has
made that call, one way or the other; the default setting is:

smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination

This means that first it checks to see if the message originated from a
local system, in which case it will accept it even if the addressee is
not a valid local one (because it will handle outbound mail from these
systems), and check no further; for any message that isn't of localnet
origin, it then checks to see if the message has failed the local user
test and/or the "domain is mentioned in $mydestination" one, and will
then reject outright all messages that fail either of those two tests.

If you still have your main.cf from the 2007.1 setup that worked well,
perhaps a mere diff between the two files will provide more clues ...

--
Bill Mullen
RLU #270075

On Wed, 09 Jul 2008 22:35:12 GMT,
Unruh wrote:

> there was an error message in /var/log/syslog that seemed
> to suggest that the check_recipient_access needed an argument.

So it would appear:

http://www.postfix.org/postconf.5.ht...t_restrictions

Glad to hear that you got it sorted.

--
Bill Mullen
RLU #270075

On Wed, 9 Jul 2008 20:08:29 -0400, Bill Mullen wrote:

> If you still have your main.cf from the 2007.1 setup that worked well,
> perhaps a mere diff between the two files will provide more clues ...

All modified config files should be compared between releases to see
what might have changed. :-)

With postfix, it does not hurt to diff main.cf.default to see what is new.
I do not change main.cf.default. So far I have gotten away with just
appending my changes to main.cf to override any main.cf.default values.

Bit Twister writes:

>On Wed, 9 Jul 2008 20:08:29 -0400, Bill Mullen wrote:

>> If you still have your main.cf from the 2007.1 setup that worked well,
>> perhaps a mere diff between the two files will provide more clues ...

>All modified config files should be compared between releases to see
>what might have changed. :-)

>With postfix, it does not hurt to diff main.cf.default to see what is new.
>I do not change main.cf.default. So far I have gotten away with just
>appending my changes to main.cf to override any main.cf.default values.

Unfortunately there are about 100 default values, almost all of which I
have no idea what they do, except that if you do something slightly wrong,
postfix fails, either refusing all mail or piling up hundreds in the mail
que (after about 1.2 hr I have 73 in my mail que all of which were mail to
invalid users. )

On Wed, 9 Jul 2008 20:46:00 -0400, Bill Mullen wrote:
>
> I don't think that editing main.cf.default would do any good anyway, as
> it appears to merely be there to let you know which defaults have been
> compiled into the distro's version of Postfix; I highly doubt that any
> of the actual running Postfix daemons even access it at all.

Hmmm, as I misunderstand it, main.cf.default is sourced/read first, then main.cf

Unruh writes:

> "David W. Hodgins" writes:
>
>>On Wed, 09 Jul 2008 12:02:44 -0400, Unruh wrote:
>
>>> Out: 451 4.3.5 Server configuration error
>
>>Looks to me like there's something in /etc/postfix/main.cf, or the directory
>>structure/ownership, that postfix doesn't like. Is there anything in
>>/var/log/mail/errors.log?
>
> No that error report IS a report of an invalid recipient. Regular mail to
> real recipients actually does get through fine. HOwever since my system
> gets bombarded by junk messages to ancient or invalid recipients (a user
> similar to the recipient reported in that message was here 15 years ago,
> but the memory in spam lists is infinite) this means I get such invalid
> address recipient mail maybe 1000 times a day. And getting 1000 emails from
> SNTP like that is simply unacceptable.

But an invalid recipient should not cause your system to return Server
Configuration Error. If your system is returning SCE to the incoming
client, your configuration is broken.

First fix your configuration.

Then, if you still need to switch off error reporting, look at the section
on error reporting in
http://www.postfix.org/BASIC_CONFIGURATION_README.html

Bill Mullen writes:

>On Thu, 10 Jul 2008 00:25:54 +0000 (UTC),
>Bit Twister wrote:

>> On Wed, 9 Jul 2008 20:08:29 -0400, Bill Mullen wrote:
>>
>> > If you still have your main.cf from the 2007.1 setup that worked
>> > well, perhaps a mere diff between the two files will provide more
>> > clues ...
>>
>> All modified config files should be compared between releases to see
>> what might have changed. :-)

>I agree wholeheartedly.

Then of course you have to figure out what in the world the difference
means.
But before that you curse the maintainer who decided that things would look
better with an extra space stuck into each line so diff says everything has
changed.


>> With postfix, it does not hurt to diff main.cf.default to see what is
>> new. I do not change main.cf.default. So far I have gotten away with
>> just appending my changes to main.cf to override any main.cf.default
>> values.

>I don't think that editing main.cf.default would do any good anyway, as
>it appears to merely be there to let you know which defaults have been
>compiled into the distro's version of Postfix; I highly doubt that any
>of the actual running Postfix daemons even access it at all.

It does not look at anything but main.cf.

On Thu, 10 Jul 2008 16:18:39 GMT, Unruh wrote:
>
> Then of course you have to figure out what in the world the difference
> means.

If /usr/share/doc/postfix/html/index.html does not exist
there is http://www.postfix.org

> But before that you curse the maintainer who decided that things would look
> better with an extra space stuck into each line so diff says everything has
> changed.

Why no light a candle instead of cursing the darkness.
I have dif aliased to diff -bBw


> It does not look at anything but main.cf.

Well, that and master.cf.

I'll have to go along with it is not using main.cf.default for the
time being.

Must have assumed master.cf.default when I was hunting where a
variable was set. Example

cd /etc/postfix
postconf -d | grep virtual_mailbox_domains
grep virtual_mailbox_domains *.cf*

Bit Twister writes:

>On Thu, 10 Jul 2008 16:18:39 GMT, Unruh wrote:
>>
>> Then of course you have to figure out what in the world the difference
>> means.

>If /usr/share/doc/postfix/html/index.html does not exist
>there is http://www.postfix.org

>> But before that you curse the maintainer who decided that things would look
>> better with an extra space stuck into each line so diff says everything has
>> changed.

>Why no light a candle instead of cursing the darkness.
>I have dif aliased to diff -bBw

Thanks To light a candle you have to know where they are hidden.



>> It does not look at anything but main.cf.

>Well, that and master.cf.

>I'll have to go along with it is not using main.cf.default for the
>time being.

>Must have assumed master.cf.default when I was hunting where a
>variable was set. Example

>cd /etc/postfix
>postconf -d | grep virtual_mailbox_domains
>grep virtual_mailbox_domains *.cf*

On Fri, 11 Jul 2008 15:04:54 GMT, Unruh wrote:
>
> Thanks, To light a candle you have to know where they are hidden.

My process:
man cmd_here
locate cmd_here
less cmd_here
strings /wherever/cmd_here