I'd like to fix a long-standing issue here; namely, I'm not calling the
zen zone at spamhaus.org properly in main.cf. What I have is:
reject_rbl_client zen.spamhaus.org,
as a smtpd_client_restrictions entry.
Reading the spamhaus web site FAQs I see that zen is a DNS zone combining
t
On Thu, 15 Jan 2009, Matt Hayes wrote:
This usually happens when you are going above their amount of queries
they limit free use to.
Matt,
Interesting. There are only two of us users at this domain and the
overwhelming majority of incoming messages are spam that's rejected by
postfix. We pr
On Thu, 15 Jan 2009, Rich Shepard wrote:
Interesting. There are only two of us users at this domain and the
overwhelming majority of incoming messages are spam that's rejected by
postfix. We probably average 300 incoming messages per day (mostly on
technical mail lists), but have thousan
On Thu, 15 Jan 2009, mouss wrote:
if you forward DNS queries to your ISP, then the rate limit applies to
your ISP. spamhaus don't see mail hitting your servers. They only see DNS
queries.
Ah, so! That explains it. I run Dan Bernstein's dnscache here, but use my
ISP's DNS servers otherwise.
On Thu, 15 Jan 2009, J Sloan wrote:
I find that having a local unix-based dns server is often orders of
magnitude faster than relying on an upstream isp for dns resolution.
Joe,
I don't know that the effort to set up and maintain djbdns is worth any
speed increase. I've no basis for compari
On Thu, 15 Jan 2009, Victor Duchovni wrote:
You don't need to run your own DNS server provided your cache does not
forward cache misses to the ISP. A local cache is sufficient.
Victor,
I assume that dnscache does forward misses up the line, and apparently
zen.spamhaus.org never made it into
On Fri, 16 Jan 2009, Res wrote:
It's been proven time after time after time this is not so, and/or
whatever they use to calculate this, is horribly inaccurate and has been
for a long time.
THank you, Res. I changed DNS nameservers and resolved the issue.
Rich
--
Richard B. Shepard, Ph.D.
On Thu, 15 Jan 2009, J Sloan wrote:
Dunno about djbdbs - last I checked it was rather long in the tooth - but
using the standard bind9, out of the box, as shipped by linux vendors and
used as a caching dns server is a very cheap and easy speedup.
Joe,
I've been running DJB's dnscache for a
On Thu, 15 Jan 2009, Victor Duchovni wrote:
This misses the point, ...
Victor,
I'm not at all surprised. I've never delved deeply into DNS; it's so
peripheral to our business that I have no time to spend learning all about
it.
Your explanation is much appreciated.
Rich
--
Richard B. Sh
On Fri, 16 Jan 2009, Geert Hendrickx wrote:
You can configure dnscache to forward queries for zen.spamhaus.org to
different upstream servers than the rest of the queries (list IP's, one
per line, in root/servers/zen.spamhaus.org - not sure whether you can tell
it to do recursive resolving for su
On Fri, 16 Jan 2009, mouss wrote:
If you can't get djbdns to do its own resolution, install bind. setting up
a "caching only" bind is relatively trivial (and many systems come with a
fully working default setup).
Mouss,
Using dnsmasq works so there's probably no added value in setting up an
I'm running postfix-2.5.2 on what is now Slackware-12.2. Had the system
crash a week ago and, with udev and mkinitrd issues, it took until yesterday
afternoon to get it back up and working properly. But, two issues mail are
still to be resolved, and I need some advice on how to resolve them.
On Sat, 24 Jan 2009, Douglas C. Stephens wrote:
Not really sure either of these are about Postfix.
Douglas,
Me, neither, but I want to eliminate it if appropriate.
1. No clue. I have no users that run Alpine.
OK.
2. My mailbox servers don't use Qualcomm's qpopper, but this looks li
On Sat, 24 Jan 2009, Douglas C. Stephens wrote:
1. No clue. I have no users that run Alpine.
Douglas,
Got it fixed. Set smtp-sender=localhost and that fixed the slowness.
Whew!
Rich
--
Richard B. Shepard, Ph.D. | IntegrityCredibility
Applied Ecosystem Services
This has not happened before: two messages sent to me, and received, but
not delivered to my mailbox. Here's what the maillog shows:
Feb 9 11:43:59 salmo postfix/qmgr[32715]: E4041AAE:
from=, size=4572, nrcpt=1 (queue active)
Feb 11 11:33:33 salmo postfix/qmgr[21684]: 8BA1AF50:
from=, size=483
On Wed, 11 Feb 2009, Terry Carmen wrote:
What do you get with:
grep E4041AAE /var/log/maillog
Terry,
Feb 9 11:43:58 salmo postfix/smtpd[17963]: E4041AAE:
client=vms173007pub.verizon.net[206.46.173.7]
Feb 9 11:43:59 salmo postfix/cleanup[17966]: E4041AAE:
message-id=<88ba18204f8d4137a8f4a4b0
On Wed, 11 Feb 2009, Terry Carmen wrote:
Postfix delivered it to procmail, so postfix is done with it.
I saw that, but there's nothing in ~/procmail/log since 2007.
Time to look further.
Thanks,
Rich
--
Richard B. Shepard, Ph.D. | IntegrityCredibility
Applied
On Wed, 11 Feb 2009, J.P. Trosclair wrote:
Might be worth turning on logging procmail. I don't see any problem from
postfix, looks like the mail was delivered and whatever procmail did with
it will probably revealed via procmail's log for future messsages.
Done.
As I wrote earlier, procma
On Wed, 11 Feb 2009, Sahil Tandon wrote:
Figure out why Postfix is passing the message on to procmail. Is it a
.forward file? A transport setting in main.cf?
Sahil,
No, because the delivery address is local.
I've turned on (and up) procmail logging. Perhaps that will help.
Why, afte
I upgraded both my distribution (to Slackware-13.1) and postfix (to 2.7.1)
and continue to see warnings that I fixed in the daily log summary. The
warnings are:
Warnings
postfix-script (total: 4)
2 not owned by postfix: /var/lib/postfix/./master.lock
1 /var/spoo
On Fri, 12 Nov 2010, Wietse Venema wrote:
Trick question: does running the command "postfix check" produce
the same warnings? If not, perhaps the warnings are from a different
point in the space-time continuum.
Wietse,
No, "postfix check" does not produce these warnings, but they have
appea
On Fri, 12 Nov 2010, Jeroen Geilman wrote:
Are you running pflogsumm with cumulative history ?
Jeroen,
Not deliberately. In the past when I've resolved warnings they did not
appear the next day.
Try to purge the history, or run it once for just "yesterday".
I'll go look for how to do
Recently I upgraded to postfix-2.7.1. Something changed in the pflogsumm
reporting system because now each day's report appears to accumulate for the
entire week before resetting. It used to report for only the previous day's
maillog, which is why the local file, /etc/cron.daily/1pflogsumm, runs
On Mon, 22 Nov 2010, Carlos Mennens wrote:
Both client_access & sender_access appear to have the same formatting:
some.domain.tld REJECT
another.domain.tld REJECT
Am I correct or have I missed something?
Carlos,
I use a badaddr file that lists domains from whom I will not acc
The Postfix book tells me that using the WARN option on a restriction
(such as in the /etc/postfix/header_checks file) logs the warning while
delivering the message. However, there is apparently no marking of the
message so it's clearly identified as one that tripped that warning.
I want to
On Tue, 6 Oct 2009, Ralf Hildebrandt wrote:
I want to examine delivered messages that contain
"Content-Transfer-Encoding: base64" in the header.
Basically that would be all messages...
Ralf,
I asked locally about that because much of the spam I receive is coded
base64 while almost all
On Tue, 6 Oct 2009, Wietse Venema wrote:
Perhaps "warn" is not the right concept for inspecting mail. Options more
directly related to mail inspection would be:
holdFreeze the mail in the queue until acted upon.
Frozen mail can be inspected with "postcat -q queueid", or
deleted/requeued
On Wed, 7 Oct 2009, LuKreme wrote:
Looking at my mail spool almost ALL mail is either 7bit, 8bit, or
quoted-printable.
That's what I've seen here, too.
Regardless, when I put those base64 messages on hold and looked at them
this morning, none was base64 Content-Transfer-Encoded. I'm witho
I just upgraded from -2.7.1 to -2.8.2. I see there are many changes
between my existing main.cf and the new main.cf.default.new. Is there an
efficient way to preserve the specifics of my current main.cf while adding
the new features in the main.cf.default.new?
Thanks,
Rich
On Sun, 3 Apr 2011, Wietse Venema wrote:
Run this, with the old configuration files in place:
# postfix upgrade-configuration
Wietse,
Thank you. I'm still missing something after doing this: I see
smtpd_delay_reject = yes in main.cf.new, but not in main.cf. Did I run the
command incorrectl
On Sun, 3 Apr 2011, Sahil Tandon wrote:
What is main.cf.new? It is not distributed with Postfix. The parameter
setting you mention above is the default, and thus does not even need to
appear in main.cf.
Sahil,
I did not check the date on the file, so it might be from an earlier
upgrade.
On Sun, 3 Apr 2011, Rich Shepard wrote:
If I understand you correctly, applying upgrade-configuration should be
all I need to do and parameters such as smtpd_delay_reject = yes should be
in 2.8.2 without explicit inclusion in main.cf. Yet a colleage of mine
still has his mail to me rejected
On Sun, 3 Apr 2011, Sahil Tandon wrote:
AFAIK, Postfix has never distributed such files. This must be an artifact
of your package management system.
Yes, from the last Slackware upgrade.
And also note that this setting has been the default since well before
2.7.2.
Well, then, that's n
I re-installed bind and both host and dig are now working, but attempts to
join a mail list fail:
Oct 11 08:31:44 salmo postfix/smtpd[30881]: NOQUEUE: reject: RCPT from
unknown[67.23.35.254]: 450 4.7.1 Client host rejected: cannot find your
hostname, [67.23.35.254]; from=
to= proto=ESMTP helo=
On Tue, 11 Oct 2011, Driessen wrote:
Set HELO = PTR = A = marge.leafe.com and the Problems going away
Where do I do this?
Danke,
Rich
On Tue, 11 Oct 2011, Rich Shepard wrote:
Set HELO = PTR = A = marge.leafe.com and the Problems going away
Where do I do this?
What I did was to modify /etc/hosts here by adding the IP address and the
name @slicehost.net. I'll let them know there's a problem with their DNS
serve
On Tue, 11 Oct 2011, Noel Jones wrote:
This messages was rejected by the reject_unknown_client_hostname
restriction.
Noel,
That's what I assumed.
That's only half of it. You also need to check:
$ host 67-23-35-254.static.slicehost.net.
Host 67-23-35-254.static.slicehost.net. not found: 3
On Tue, 11 Oct 2011, Noel Jones wrote:
... many of them do enforce the equivalent of
reject_unknown_reverse_client_hostname.
Noel,
That has been in main.cf. I commented out of
reject_unknown_client_hostname and reloaded postfix.
Thanks very much for the insights,
Rich
A common form of spam comes with the body text in all uppercase letters.
Perhaps the senders are all using Apple ][e computers. Anyway, if I add the
following to /etc/postfix/body_checks will I unintentionally reject valid
messages?
/[A-Z].*/
If this will not selectively identify such messag
On Sun, 13 Nov 2011, Noel Jones wrote:
This test is much better suited for SpamAssassin or some other filter that
can examine the whole body. IIRC SpamAssassin already includes tests for
all-caps.
Noel,
That's why I asked before rushing ahead. :-)
Perhaps I need to update SA, then, beca
A few weeks ago I upgraded postfix from 2.11.0 to 2.11.1 and soon saw that
my daily log summary reports stopped appearing in my inbox each morning. The
script (logwatch.pl) is run from /etc/cron.daily and has worked faithfully
for years. Until recently.
I've been going back and forth between
Postfix is rejecting mail from an address that should be allowed in. The
mail log tells me:
Jul 28 13:11:58 salmo postfix/smtpd[17243]: NOQUEUE: reject: RCPT from
wsip-xx-xxx-xx-xx.ph.ph.cox.net[xx.xxx.xx.xxx]: 450 4.1.7
<[EMAIL PROTECTED]>: Sender address rejected: unverified
address: Address
On Mon, 28 Jul 2008, Rich Shepard wrote:
Postfix is rejecting mail from an address that should be allowed in. The
mail log tells me:
More information.
proto=ESMTP helo=
I should have written this as 'somedomain.com'.
When I try to traceroute to the sending address I get
On Mon, 28 Jul 2008, Charles Marcus wrote:
Post output of postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/major-aliases
body_checks = regexp:/etc/postfix/body_checks
command_directory = /usr/sbin/
config_directory = /etc/postfix
daemon_d
On Mon, 28 Jul 2008, Sahil Tandon wrote:
Sender Address Verification (SAV) is done in Postfix with the
reject_unverified_sender parameter; see postconf(5) for details. Before
employing this feature, make sure you understand its implications and read
the ADDRESS_VERIFICATION_README.
Sahil,
Every now and then a message that should be rejected by one of my UCE
filters makes it though to my inbox. Today, three of them did so. I'd like
to learn how to find why the lists aren't working on occasion.
The most frequently involved list is badip (IP addresses in CIDR format).
In main.cf
On Thu, 7 Aug 2008, Ralf Hildebrandt wrote:
These are NOT CIDR format.
I don't understand, Ralf. The contents of badip are in CIDR format. What
have I missed?
Thanks,
Rich
On Thu, 7 Aug 2008, Brian Evans - Postfix List wrote:
Ralf is pointing out that you are using a HASH table which cannot do CIDR,
only a single IP.
A CIDR table can do CIDR.
A-ha! I will make the change immediately.
Thank you, Brian,
Rich
On Thu, 7 Aug 2008, Ralf Hildebrandt wrote:
Use cidr: instead of hash:
Thank you very much, Ralf. I certainly missed this when I read your book.
Much appreciated,
Rich
On Thu, 7 Aug 2008, Noel Jones wrote:
check_sender_access hash:/etc/postfix/badip,
And this one won't ever match anything. check_sender_access uses the
envelope sender email address (ie. [EMAIL PROTECTED]) as the key; it won't
ever be an IP address.
Thanks, Noel. I missed this, too.
On Thu, 7 Aug 2008, Stan Hoeppner wrote:
Is the CIDR file a plain text flat file?
Stan,
Yes. A representative line:
222.111.0.0/12 550 Rejected IP address.
Do I need to run any commands against it to do the binary conversions or
is that something Postfix does automatically on th
On Thu, 7 Aug 2008, Stan Hoeppner wrote:
Oh, heheh. No, I meant like do I need to be running postmap on it from
the command line kinda scenario, like with the access file.
Stan,
Yes: postmap. I use a Makefile so each time I change anything in
/etc/postfix the proper builds are run. Here's
On Thu, 7 Aug 2008, Noel Jones wrote:
No, you do not need to "postmap" cidr: or regexp: or pcre: tables. These are
all just plain text files. Postfix reads in the plain text file and
processes it internally.
Thank you, Noel. That cleared it up for me, too.
Rich
My wife uses her laptop connected wirelessly to the network, but sending
mail has failed since I upgraded postfix to 2.5.2 and enabled SASL
authorization. Thunderbird keeps asking for her password on the server when
she tries to send mail (incoming mail reaches her inbox with no problems)
and wo
On Fri, 29 Aug 2008, Wietse Venema wrote:
There are lots of hits when you search the web for:
cannot connect to saslauthd server: Permission denied
Likely one of them will have the answer.
I've tried a couple but without success. Also, I fixed main.cf per mouss'
message. I had cut and pas
On Fri, 29 Aug 2008, mouss wrote:
smtpd_* parameters are used by 'smtpd', the thing that listens for smtp
connections. this is what you contact when you telnet or when Thunderbird
send mail.
mouss,
Mea culpa! I cut this from the README file and pasted it into main.cf
without paying close at
On Fri, 29 Aug 2008, J.P. Trosclair wrote:
The reason your mail is working locally is probably because postfix is
configured to accept mail from the local network or localhost without any
sort of authentication but not when the mail is comming from an untrusted
network:
All outgoing mail com
On Sat, 30 Aug 2008, Graham Leggett wrote:
Unfortunately the alternate usecase support in SASL is virtually non
existent, so you're stuck using strace to tease out the real error that is
preventing SASL from working. If you are truly stuck, use strace (or your
local equivalent) to run testsaslau
On Sat, 30 Aug 2008, Graham Leggett wrote:
Once testsaslauthd works, then add postfix to the mix.
Graham,
I just ran testsaslauthd for my wife's account from the server:
[EMAIL PROTECTED] ~]# testsaslauthd -u pamela -p
0: OK "Success."
So that seems to be OK. Same success if I add our
On Sat, 30 Aug 2008, Graham Leggett wrote:
You're testing this while running as root - you need to test this running
as the system user that ultimately will be used to run postfix.
Graham, Wietse, Noel, mouss:
I turned off SASL authorization and returned to the status we had for
years. Sinc
Running postfix-3.0.3 on Slackware-14.1 here.
I need to relay outbound messages through my ISP. When I send newsletters
to subscribers I need to limit the number of messages per hour to < 300. To
accommodate this need I understand that within main.cf I set
default_destination_rate_delay = 15
On Mon, 22 Feb 2016, Wietse Venema wrote:
If you did not change any of the _destination_recipient_limit
settings, this will send 240 messages per hour to the ISP. It also
rate-limits all other Postfix delivery agents (local delivery, in
particular).
Wietse,
I can live with a 15s delay local
When upgrading to -2.11.4 (on Slackware-14.1), a message is displayed that
line 504 in /usr/libexec/postfix/post-install has too many arguments. Adding
double quotes to $path fixes this problem.
Is this an issue with the source for post-install? I don't see any
reference to that file in the S
I'm not a professional SysAdmin or network admin but have been running my
own smtpd using cyrus-SASL for years. I want now to transition to using
dovecot-SASL and have difficulty correctly configuring dovecot.
Reading the postfix/dovecot Web pages and following the links, I created
/etc/pam.d
On Tue, 17 Feb 2015, Viktor Dukhovni wrote:
This is a symptom of a deeper problem, possibly a bug in the Bourne
shell implementation on the system in question.
Victor,
Standard linux bash.
I am guessing that your shell read and split the whole "postfix-files"
file in one gulp, rather than
On Tue, 17 Feb 2015, Viktor Dukhovni wrote:
Before you do, insert debugging code to print the "$path" in question.
Something like:
Viktor,
Thank you; I'll do this.
Rich
On Tue, 17 Feb 2015, Viktor Dukhovni wrote:
Perhaps you should be asking the dovecot list, not the Postfix list.
Viktor,
Rather than joining the dovecot mail list I went to their Web site and
worked through the configuration documentation step-by-step. After running
all their reommended che
On Tue, 17 Feb 2015, Viktor Dukhovni wrote:
I am guessing that your shell read and split the whole "postfix-files"
file in one gulp, rather than split each line. Too many tokens from a
single line in that file is implausible.
Viktor,
I passed on your message to the postfix SlackBuilds maint
On Tue, 17 Feb 2015, Wietse Venema wrote:
Rich Shepard:
Now the only remaining issue is the lack of double quotes around $path on
line 504 of /usr/libexec/postfix/post-install. At worst after the next
postfix upgrade, I'll just edit it by hand again.
May I ask again, do you have spac
On Tue, 17 Feb 2015, Rich Shepard wrote:
I'm not a professional SysAdmin or network admin but have been running my
own smtpd using cyrus-SASL for years. I want now to transition to using
dovecot-SASL and have difficulty correctly configuring dovecot.
Found a web forum thread that see
On Tue, 17 Feb 2015, Wietse Venema wrote:
Dovecot has no client support. Server only.
Wietse,
Thank you. I'll stay with cyrus then.
Much appreciated,
Rich
On Wed, 18 Feb 2015, Viktor Dukhovni wrote:
Sounds like nonsense to me. You can operate a port 587 submission
service on a machine which routes outbound mail via a smarthost.
Viktor,
For my situation that's not worth my time and effort.
You'll have to somehow deal with tracking the machin
On Wed, 18 Feb 2015, Wietse Venema wrote:
Just to be sure we are talking about the same thing, are you referring to
the same line 504 that I have here:
501 # Flag obsolete objects. XXX Solaris 2..9 does not have "test -e".
502 if [ -n "$obsolete_flag" ]
503 then
504 test -r $path -a
On Wed, 18 Feb 2015, Viktor Dukhovni wrote:
Oops, I was looking at line 504 in the 3.0.0 source. Indeed in the above
line 504, $path should be in quotes, though it if it needs quoting,
appending it to "obsolete" still won't work right.
Viktor,
Only the first, unquoted $path needs the quote
On Wed, 18 Feb 2015, Wietse Venema wrote:
This suggests that you have a space in a pathname of some Postfix
configuration pathname parameters such as queue_directory,
command_directory, sendmail_path, and so on.
Wietse,
Here are all directory paths from main.cf; I deleted all other lines:
On Wed, 18 Feb 2015, Viktor Dukhovni wrote:
This does not matter, the problem might come from somewhere else. You need
to figure out why that particular path on line "504" is causing the
problem. We can't do that for you.
To do that, you need to edit the post-install shell script to
log the obs
On Wed, 18 Feb 2015, Wietse Venema wrote:
Or y9u can send us the postfix-files file that Postfix 2.11.4 wants to install.
$config_directory:d:root:-:755:u
$data_directory:d:$mail_owner:-:700:uc
$daemon_directory:d:root:-:755:u
$queue_directory:d:root:-:755:uc
$sample_directory:d:root:-:755:o
$
On Wed, 18 Feb 2015, Wietse Venema wrote:
That means we will need command output from the modified post-install
script to find out what is going on.
Wietse,
As soon as I can.
Rich
On Wed, 18 Feb 2015, Viktor Dukhovni wrote:
diff --git a/conf/post-install b/conf/post-install
index 7e79c92..35279d0 100644
--- a/conf/post-install
+++ b/conf/post-install
@@ -501,6 +501,7 @@ test -n "$create" && {
# Flag obsolete objects. XXX Solaris 2..9 does not have "test -e".
On Wed, 25 Feb 2015, Viktor Dukhovni wrote:
The directory does not exist, but it looks like that's what you have
set as "sample_directory", either in the existing main.cf files or
in the build configuration.
Viktor,
Yes, there was a samples/ directory in /etc/postfix; I've no idea how long
On Wed, 25 Feb 2015, Wietse Venema wrote:
I have added a test to the post-install script so that it terminates with
an error message when a Postfix pathname contains whitespace. To override
a broken pathname in your case one would use:
# make upgrade some_directory=/path/without/space ...
In t
For the past few days an incoming message rejected by a body_checks rule
has been stuck somewhere and prevents the daily logwatch report being mailed
to me. No subdirectory in /var/spool/postfix/defer/ or ../deferred/ contains
a file and I don't know where to find this so I can remove it. The me
On Thu, 5 Mar 2015, Leonardo Rodrigues wrote:
postsuper -d QUEUEID
Leonardo,
The mail queue is empty and there is nothing in deferred. I interpret the
message
as a notice of message rejection, not a message itself. It's an unmatched
entry in logwatch. In pflogsumm there's a record of it
On Thu, 5 Mar 2015, Noel Jones wrote:
Please send all of the log entries for this message, unedited except for
the recipient name.
Noel,
I was the intended recipient; the sender was a mail list manager:
Mar 2 11:14:37 salmo postfix/cleanup[4816]: B52909929A: reject: body browse
and edit d
On Thu, 5 Mar 2015, Wietse Venema wrote:
If this is handled by the pickup daemon, then it is a local submission.
Wietse,
Yes, this is submitted locally.
When a local submission is rejected by header/body_checks then
it should be returned to sender, not get stuck in the queue.
The message
On Thu, 5 Mar 2015, Wietse Venema wrote:
That is not a Postfix configuration file. Try:
grep internal_mail_filter_classes /etc/postfix/main.cf /etc/postfix/master.cf
Not found in either one.
Do you have receive_override_options=no_header_body_checks in main.cf
or master.cf?
No; in neit
On Thu, 5 Mar 2015, Wietse Venema wrote:
Last chance: do you have "receive_override_options" in those files?
No.
Otherwise, either your Postfix configuration files are in a different
place (do "postfix reload" and see the real pathname in the mail logfile)
or your Postfix has been changed.
On Thu, 5 Mar 2015, Wietse Venema wrote:
Can you do "postfix reload" AND LOOK IN THE MAIL LOGFILE. There will
be a record like this:
Mar 5 10:10:24 salmo postfix/postfix-script[11000]: refreshing the Postfix
mail system
Mar 5 10:10:24 salmo postfix/master[21792]: reload -- version 2.11.4,
c
On Thu, 5 Mar 2015, Wietse Venema wrote:
Did we ever confirm where the "stuck" email message comes from?
Mar 3 05:50:32 salmo postfix/pickup[11492]: 241BB9929C: uid=0 from=
Mar 3 05:50:32 salmo postfix/cleanup[13188]: 241BB9929C: message-id=<20150
303135032.241bb99...@salmo.appl-ecosys.com>
On Thu, 5 Mar 2015, Rich Shepard wrote:
Did we ever confirm where the "stuck" email message comes from?
There's nothing about this message in maillog or maillog.1, only in
maillog.2 from Tuesday.
Using a different string for grep finds this in today's /var/log/maill
On Thu, 5 Mar 2015, Wietse Venema wrote:
Agian, one message (948EC9926E) is rejected by body_checks, and a
corresponding bounce message (A6C4E99275) is delivered to the sender.
There is no evidence of mail being stuck in the queue. Postfix works as
expected.
Wietse,
Make sense now to me; t
On Thu, 5 Mar 2015, Noel Jones wrote:
But since you state the origin is a mail list manager, it's likely the
message is stuck in the list manager software and not in postfix.
Noel,
And the MLM will likely keep sending it for a few days. I've commented out
that body_checks rule and hope that
During the most recent upgrade I inadvertently altered owner, group,
and/or permissions in /var/spool/postfix. I've looked for information in all
the README files that seemed applicable but have not found a list of how
/var/spool/postfix subdirectories should be set. Please point me to a doc
tha
On Thu, 6 Aug 2015, Michael J Wise wrote:
Needs Group Write.
Michael,
Ah, I should have seen that.
See that little "s"?
That's special.
Yep. I learned that maildrop and public need to be set gid.
It would still be useful to have a complete list of owners, groups, and
perms for the
On Thu, 6 Aug 2015, Michael J Wise wrote:
This is from a MacOS 10.9 instance, so it's not quite current, and the
user is ... a bit weird, but it should help as a data point. Good luck!
Thanks, Michael.
Rich
On Thu, 6 Aug 2015, Viktor Dukhovni wrote:
# postfix set-permissions
Except on Debian systems where it might not work, because the Debian
"postfix-files" file (in $daemon_directory for recent enough
releases) often has more files list than are actually deployed by
Postfix packages.
Viktor,
I just upgraded postfix from 3.1.2 to 3.2.2. When I chown postfix of the
/var/spool/postfix/ tree I get these warnings:
# /etc/rc.d/rc.postfix start
postfix/postfix-script: warning: not owned by root: /var/spool/postfix/.
postfix/postfix-script: warning: not owned by root: /var/spool/postfix/pi
On Sun, 25 Jun 2017, Wietse Venema wrote:
Must be owned by root, mode 755.
All that is taken care of with "postfix set-permissions", which
should happen automatically as part of the installation procedure.
Wietse,
OK.
Of course no such warranties exist if you do things by hand.
I use
On Sun, 25 Jun 2017, Wietse Venema wrote:
See comment above: run "postfix set-permissons".
Thanks, Wietse. I ran 'chown -R root /var/spool/postfix/pid/' with postfix
stopped. When re-started nor warnings were displayed.
Regards,
Rich
Running postfix-3.2.4 here on Slackware-14.2. I am a professional services
sole practitioner, not a professional system or network admin.
After several years having outbound mail forwarded through my ISP's mail
server I changed ISPs and now have a static IP address. The other recent change
he
1 - 100 of 126 matches
Mail list logo
