hyndavirap...@bel.co.in:
I have enabled enable_long_queue_id = yes
That is a non-existent parameter.
Now my doubt is how long, queueids will be unique, for 150 mails/min mail
flow?
http://www.postfix.org/postconf.5.html#enable_long_queue_ids
enable_long_queue_ids (default: no)
Enable
On 1/22/2015 3:13 AM, Joe Acquisto-j4 wrote:
Thanks. I appreciate the reminder. The methodology is long standing
and should be altered. The users have only the tools offered to them.
However, not trying to be argumentative at all -
While I agree Bcc is correct, I am having difficulty
On 1/21/2015 at 10:37 PM, Viktor Dukhovni postfix-us...@dukhovni.org
wrote:
On Wed, Jan 21, 2015 at 09:08:19PM -0500, Joe Acquisto-j4 wrote:
This appeared to work fine and does, for most messages. However,
our org often sends an email to thousands of users with in our
system. These
Am 22.01.2015 um 12:13 schrieb Joe Acquisto-j4:
On 1/21/2015 at 10:37 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote:
On Wed, Jan 21, 2015 at 09:08:19PM -0500, Joe Acquisto-j4 wrote:
This appeared to work fine and does, for most messages. However,
our org often sends an email to
Am 2015-01-22 10:26, schrieb hyndavirap...@bel.co.in:
I have enabled enable_long_queue_id = yes
Now my doubt is how long, queueids will be unique, for 150 mails/min
mail
flow?
The id is build from the time and the file-id within the filesystem.
So each queue_id should be locally unique.
The
Hi,
I have a query regarding queue ids.
In my mail system, 150 mails/min flow is there and I need to keep track of
mails and DSN for atleast 24 hours. To achieve this functionality, I have
modified code as follows.
1. I am logging all mails Queue ids in a text file.(Queueid represents
On 2015.01.22 10.35, wie...@porcupine.org (Wietse Venema) wrote:
btb:
we have a small local blacklist, mostly used for clients which
aren't listed in dnsbls.
postscreen_access_list =
cidr:$table_directory/postscreen_access_list-rejects.cidr
sometimes when a larger netblock gets listed, it
Hi
After setting up a single instance firewall/gateway, I'm now working my way
through a MULTI_INSTANCE setup. Been reading the docs and working on examples,
and am a little unclear.
I have a question about SOURCE of config parameter inheritance.
Say I have a main and 1 secondary Postfix
each instance has it's own copy of main.cf and master.cf so you have
to duplicate values. If you think most will be the same, perfect the
first instance and then copy that file to the new ones, and change
accordingly.
If I am wrong, someone please correct me, but I've never heard of any
kind of
On Thu, Jan 22, 2015 at 04:46:44PM -0500, Paul C wrote:
Each instance has it's own copy of main.cf and master.cf so you have
to duplicate values. If you think most will be the same, perfect the
first instance and then copy that file to the new ones, and change
accordingly.
If I am wrong,
rogt3...@proinbox.com:
Hi
After setting up a single instance firewall/gateway, I'm now working
my way through a MULTI_INSTANCE setup. Been reading the docs and
working on examples, and am a little unclear.
I have a question about SOURCE of config parameter inheritance.
As documented,
On Thu, Jan 22, 2015 at 06:13:30AM -0500, Joe Acquisto-j4 wrote:
While I agree Bcc is correct, I am having difficulty accepting,
logically, not in fact, that the forwarded message should fail.
After all, it is actually addressed to only one person.
The SMTP envelope is one person, but many
we have a small local blacklist, mostly used for clients which aren't listed in
dnsbls.
postscreen_access_list =
cidr:$table_directory/postscreen_access_list-rejects.cidr
sometimes when a larger netblock gets listed, it can have the unintended
consequences of blocking well behaved clients
On 1/22/2015 8:42 AM, Joe Acquisto-j4 wrote:
A better analogy perhaps: it's as if the Postal Service refused to deliver an
envelope with one
addressee because it contained another envelope with several addressees on
it.
A better analogy is the post office refusing to deliver paint
btb:
we have a small local blacklist, mostly used for clients which
aren't listed in dnsbls.
postscreen_access_list =
cidr:$table_directory/postscreen_access_list-rejects.cidr
sometimes when a larger netblock gets listed, it can have the
unintended consequences of blocking well behaved
Please excuse the top post. the web client . . .
Thanks for expanding on this.
I've hacked a means of getting around this for the time being, until we
can change the addressing of the lists. A simple fix, technically
but a cautious tradition exists.
Thanks for all the comments.
joe a.
Daniel Miller dmil...@amfes.com 01/22/15 9:03 AM
On 1/22/2015 3:13 AM, Joe Acquisto-j4 wrote:
Thanks. I appreciate the reminder. The methodology is long standing
and should be altered. The users have only the tools offered to them.
However, not trying to be argumentative at all -
While I
Hi,
I'm setting up a postscreen instance in a multi_instance setup.
I've read the docs on the Deep Protocol Tests stage. The tests seem helpful
but for course there's the fact that on a PASS of good-to-this-point mail, it
waits for the client to disconnect. The next time the client connects
Paul, Viktor
On Thu, Jan 22, 2015, at 02:12 PM, Viktor Dukhovni wrote:
On Thu, Jan 22, 2015 at 04:46:44PM -0500, Paul C wrote:
Each instance has it's own copy of main.cf and master.cf so you have
to duplicate values. If you think most will be the same, perfect the
first instance and then
Wietse:
In the CIDR table, specify netblocks as follows:
192.168.1.1 dunno
192.168.1.0/24reject
I.e. specify the good clients before the bad ones. Instead of
dunno specify permit if you are certain that the host is not
a bot.
btb:
right. we do that now. taking advantage of
Hi again,
After some tinkering, I fixed the
ERROR:root:No parser implemented for Data
It appears that ppymilter uses milter protocol 2, and main.cf had milter
protocol 6 defined. After adjusting main.cf, this error dissapeared.
The other error has also a fix:
On 2015.01.22 12.18, wie...@porcupine.org (Wietse Venema) wrote:
Wietse:
In the CIDR table, specify netblocks as follows:
192.168.1.1 dunno
192.168.1.0/24 reject
I.e. specify the good clients before the bad ones. Instead of
dunno specify permit if you are certain that the host is not
a
On 01/23/2015 04:16 AM, Noel Jones wrote:
Ugly workaround until you fix your mail tool:
use smtp_header_checks to mangle broken To: and CC: headers.
If you can get away with it a better solution may be to reject the
mailings based on the headers being too long from postfix rather than
23 matches
Mail list logo
