On Tue, 8 Oct 2019, Jaroslaw Rafa wrote:
(However, it didn't help with my original Gmail issue - even mail relayed
via another server still goes to spam on the receiving side :()
Jaroslaw,
While not directly related to your issue, I've found that some clients who
use gmail end up with
On Mon, 5 Aug 2019, Wietse Venema wrote:
These pathnames are stored in $meta_directory/postfix-files (you can use
"postconf meta_directory" to find out where that is).
Wietse,
Yes, that's /etc/postfix/ here.
I suppose you copied that postfix-files file over from some different
machine?
I'm migrating to a new desktop as my server/workstation. Postfix-3.3.2 was
installed so I just upgraded to -3.4.6. When I ran postfix set-permissions
upgrade-configuration it returned
chown: cannot access '/usr/doc/postfix-3.3.1/README_FILES': No such file or
directory
I cannot find the
On Thu, 4 Jul 2019, Wietse Venema wrote:
Don't adjust ownership or permissions of Postfix files/directories. Let
'postfix set-permissions' do what needs to be done.
Wietse,
This is the first thing I do. When starting postfix throttles and displays
errors I fix them. This lead me to store
On Thu, 4 Jul 2019, @lbutlr wrote:
Slackware issue?
Likely not. I've used the same build script for years.
All the directories in /var/spool/postfix are owned by postfix except for
pid, which is owned by root.
Thank you. That's why the logwatch warnings puzzled me.
Regards,
Rich
Currently running 3.4.5 on Slackware-14.2. After each upgrade I run 'postfix
set-permissions upgrade-configuration' then adjust ownerships as needed.
When I upgraded to 3.4.5 last weekend I found that when /var/spool/postfix
has owner.group of root.postfix the server would not start. Changing
On Thu, 6 Dec 2018, Noel Jones wrote:
Wild guess: some spammer used your own address as sender, and the
connection was rejected by some of your spam controls, probably an rbl.
Noel,
There are certainly many rejected by a couple of rbls as well as by other
postfix UCE checks. Why these two
Today's pflogsumm report includes this rejection:
Recipient address rejected: Please see http (total: 2)
2 rshep...@appl-ecosys.com
Since this is my address I'm curious why two incoming messages were rejected
when many more were passed. I'd appreciate advice on how I can
On Sun, 28 Jan 2018, Wietse Venema wrote:
Please tell the maintainer that it they need to run the command, not the
user.
Wietse,
I'll do this.
Thanks,
Rich
On Sun, 28 Jan 2018, Viktor Dukhovni wrote:
When upgrading from an older postfix version, make sure the variables such as
html_directory and readme_directory in /etc/postfix/main.cf point to the new
location. These can also be fixed later, afterwards make sure to run:
postfix
On Sun, 28 Jan 2018, Viktor Dukhovni wrote:
Note that "make; make upgrade" would normally take care of this, perhaps
you're doing something else (needlessly complicated)?
Viktor,
I use the SlackBuilds.org build script (as I do for all my installations
and upgrades).
Also see:
On Sun, 28 Jan 2018, Viktor Dukhovni wrote:
# postfix set-permissions upgrade-configuration
Viktor,
I thought there was a procedure for post-upgrade configuration but had
forgotten where I had seen it.
Thanks very much for the information. It now resides where I'll see it
(and use it)
On Sun, 28 Jan 2018, robert.wo...@robertwolfe.org wrote:
I would first check and see if group "postdrop" exists. Then, if so, I
would recommend running a "chown root:postdrop" on these files. But, of
course, YMMV.
Robert,
postdrop still is a group. What I had neglected in my
I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop
and /usr/sbin/postqueue were set gid:
-rwxr-sr-x 1 root root 13888 Jan 28 08:58 /usr/sbin/postdrop*
-rwxr-sr-x 1 root root 18012 Jan 28 08:58 /usr/sbin/postqueue*
Yet, when I start postfix I see these messages:
Jan
On Tue, 16 Jan 2018, Rich Shepard wrote:
Running postfix-3.2.4 on Slackware-14.2. My server and workstation are on
the same host. Yesterday, about mid-day, messages to me stopped being
delivered to my INBOX. /var/spool/mail shows:
Earlier today I added another recipe to ~/procmail
On Wed, 17 Jan 2018, Matus UHLAR - fantomas wrote:
on some systems I maintain there was "VERBOSE=yes" and procmail logged
path to the created file within maildir. try setting VERBOSE=yes at the
begin of your procmail rc file.
Matus,
Thanks for clarifying. Here is ~/.procmailrc:
On Wed, 17 Jan 2018, Matus UHLAR - fantomas wrote:
what's in the /home/rshepard/procmail/log ?
Matus,
That is what I sent in the message: the log content for that specific
test message not delivered to my inbox. I deleted the lines showing procmail
testing for matches to mail list
On Tue, 16 Jan 2018, Noel Jones wrote:
This probably isn't related to your delivery problems, but whatever miler
you've configured at :8891 isn't running. Most likely the service is down.
Noel,
That was added by me last November as I added SPF and openDKIM to postfix.
The latter starts and
On Tue, 16 Jan 2018, Noel Jones wrote:
Pick one message and follow it through the logs. If postfix fails or
misdirects the message, postfix will log what happened. If the message
makes it through postfix and is handed off to procmail, then that's where
the problem is.
Noel,
Aw, I should
Running postfix-3.2.4 on Slackware-14.2. My server and workstation are on
the same host. Yesterday, about mid-day, messages to me stopped being
delivered to my INBOX. /var/spool/mail shows:
-rw-rw 1 rshepard mail 207100 Jan 15 12:30 /var/spool/mail/rshepard
Messages from mail lists are
On Mon, 13 Nov 2017, Viktor Dukhovni wrote:
IIRC your original message showed a delayed message addressed to
you. I failed to notice that this one was addressed to a different
domain...
Victor,
Yes, one of the delayed messages was the pflogsumm report; it was
delivered when I took the new
On Mon, 13 Nov 2017, John Stoffel wrote:
Could it be that you mail server is looking up and finding IPv6 addresses,
but you don't have IPv6 enabled on your setup? Try forcing postfix to only
use IPv4.
John,
I will check. A new router was installed Friday and these delays showed up
starting
On Mon, 13 Nov 2017, Viktor Dukhovni wrote:
Where should the mail be going? Is the obfuscated host[ip] to which
connections are failing the right destination?
Victor,
They are a mail list. It doesn't really need obfuscation:
thales.memphis.edu[141.225.8.55]:25
Your configuration shows:
On Mon, 13 Nov 2017, Simon Matthews wrote:
I would hazard a guess that your outbound email packets are being dropped
somewhere. Try using telnet on your mail server to connect to port 25 of
the remote mail server (mail.appl-ecosys.com.) and see what happens.
Simon,
I can telnet to port 25
On Mon, 13 Nov 2017, Viktor Dukhovni wrote:
http://www.postfix.org/DEBUG_README.html#mail
Victor,
I had looked at that page and checked many of the items.
Include logs showing the complete history of a delayed message (all
log entries with the problem queue-id).
The only one found in
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
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
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
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:
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
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 =
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,
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
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/maillog:
Mar 5 08:33:50
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. If
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,
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=root
Mar 3 05:50:32 salmo postfix/cleanup[13188]: 241BB9929C: message-id=20150
303135032.241bb99...@salmo.appl-ecosys.com
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
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;
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
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
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
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
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
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
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 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
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, 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
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
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
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 seems
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 spaces
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:
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
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
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
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
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
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];
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
server.
Thanks
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:
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
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
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
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
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,
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
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
appeared
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
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
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
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
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=usern...@gte.net, size=4572, nrcpt=1 (queue active)
Feb 11 11:33:33 salmo postfix/qmgr[21684]:
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:
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
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
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
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 and
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
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
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
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.
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.
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
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
1 - 100 of 107 matches
Mail list logo
