By the way, as a test I put the bypass lines in
/etc/amavis/conf.d/15-15-content_filter_mode back to their default settings
and enabled them - mail is still being checked for spam and viri. So it
appears that piece also remains a bit mysterious.
--
View this message in context:
http://postfix.
That makes sense and seems to have done the trick. Thanks!!
What I still don't get (and maybe never will), is why...
1) On the Lenny server, the main.cf content_filter sent mail to 10028, the
relay port for dkim_proxy_out, and this system worked! I might be able to
accept sending to the listeni
Suspecting a mail routing issue, here is a summary of port assignments from
various config files (full config files are in original post). Maybe this
will allow someone to see a problem that I am missing.
Also, a bit of history may help... this server has been migrated from a
functional installat
Here is the relevant section of 15-av_scanners:
['ClamAV-clamd',
\&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.ctl"],
qr/\bOK$/, qr/\bFOUND$/,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],
--
View this message in context:
http://postfix.1071664.n5.nabble.com/postfix-amavis-
I tried using the following in /etc/amavis/conf.d/15-15-content_filter_mode:
@bypass_virus_checks_maps = ();
@bypass_spam_checks_maps = ();
This didn't help. Also, with the configs I originally posted, I do get spam
checking when from the server console I telnet to port 10024 and
Thanks for the reply.
chaouche yacine wrote
> You have uncommented the bypass instructions in amavis conf file, so it
> will bypass the scan. Keep them commented and amavis will scan.
I find that a bit confusing as every document I've read about setting this
up says to uncomment those lines. Her
It turns out the previous admin neglected to include a section in master.cf
to indicate the relay port that was specified in the dkimproxy_in.conf file.
Adding that section cured the problem. Apparently the old system running on
lenny somehow tolerates the omission without causing any problems.
Very good, then. Thanks!
--
View this message in context:
http://postfix.1071664.n5.nabble.com/Postfix-can-t-send-from-localhost-tp88417p88458.html
Sent from the Postfix Users mailing list archive at Nabble.com.
Scott - can you (or anyone else) shed some light on why there would be a DKIM
content filter on the pickup process? Nothing I've read about DKIM so far
has ever shown an example of why one might do that. As previously
indicated, I've inherited this server, so am trying to back-learn the
previous
Thank you Scott. Yes, I meant 2.11.3-1 for the postfix version. Per your
suggestion, I've posted this in the Debian forums as well.
--
View this message in context:
http://postfix.1071664.n5.nabble.com/Postfix-can-t-send-from-localhost-tp88417p88424.html
Sent from the Postfix Users mailing li
I have a newly installed Debian 8 server, created to replace an old postfix
server running on Debian Lenny. I've installed and reconfigured as needed
the following newer packages on the new server:
postfix 2.1.3-1
dovecot 2.2.13-12~deb8u1
amavisd-new 2.10.1-2~deb8u1
spamassasin 3.4.0-6
clamav 0.99
Wietse,
>> # check_sender_accesshash:/etc/posfix/mywhitelist <-- this
killed
> the pathname does not exist (you mis-typed it). In addition, you
Ok, that's embarrassing. Thanks for catching it, though. But even so, why
would pointing to a non-existent file completely halt incoming mail
I have inherited the management of a postfix mail server. The prior admin
is not available to consult. The server is working fine as he configured
it. Client access checks are used to whitelist by IP address for known mail
clients who would otherwise be rejected due to invalid helo information.
13 matches
Mail list logo
