On Tue, Jun 10, 2014 at 05:45:02PM -0500, Jay G. Scott wrote:
> After trying various combinations of things in
> main.cf and master.cf, I find that, using the script
> below, if the mail reaches the filter script, the
> resulting mail message bounces (too many hops)
> but the filter has processed
On 6/10/2014 5:45 PM, Jay G. Scott wrote:
>
> After trying various combinations of things in
> main.cf and master.cf, I find that, using the script
> below, if the mail reaches the filter script, the
> resulting mail message bounces (too many hops)
> but the filter has processed the input.
>
> If
On 6/10/2014 6:32 PM, uffe wrote:
>
> Now I got it working - thanks
>
> Are tcp_table lookup "deamon" instances supposed to exit themselves - for
> every lookup - or can postfix reuse them "persistent"
>
> I'm having a hard time understanding the comment in the bugs section: The
> client does
On 6/10/2014 3:39 PM, Wietse Venema wrote:
> Kai Krakow:
>> BTW: In this context, what's the best approach to put mailboxes on a
>> separate machine? Let the LDA drop mails into NFS mounts, or let postfix
>> transport the mails via transport_map into a machine which hosts the LDA
>> (dovecot in
Now I got it working - thanks
Are tcp_table lookup "deamon" instances supposed to exit themselves - for
every lookup - or can postfix reuse them "persistent"
I'm having a hard time understanding the comment in the bugs section: The
client does not hang up when the connection is idle for a l
After trying various combinations of things in
main.cf and master.cf, I find that, using the script
below, if the mail reaches the filter script, the
resulting mail message bounces (too many hops)
but the filter has processed the input.
If I turn content_filter off in main.cf the
mail gets delive
On Tue, Jun 10, 2014 at 03:37:34PM -0500, Noel Jones wrote:
> On 6/10/2014 3:05 PM, Jay G. Scott wrote:
> >
> > RE: the after-queue, simple filter example
> >
> > Just trying to figure out how it works.
> > I have a feeling I don't fully understand the full implications of
> > "after-queue".
> >
Thanks for your swift answers
I'll try the recommendations immediately.
English is not my native language - but it did not occour to me from reading
that documentation for tcp_table lookups that returning 500 would be
aproprialte - I would have believed that is would have stopped the while
delive
On 6/10/2014 2:59 PM, uffe wrote:
> Hello,
>
> Subject: Problem understanding check_client_access and tcp_table
>
> I have a problem understanding how to properly use check_client_access with
> an external tcp_table (daemon)
>
> in my main.cf i have put the following:
>
> smtpd_client_restricti
uffe:
> smtpd_client_restrictions = check_client_access tcp:[127.0.0.1]:1
>
> But what I was expecting was to receive lookup "get" requests with the raw
> source ip address as argument - as "unknown" is not of much use for spam
> analysis.
There will be no "get client-address" query when the
Kai Krakow:
> BTW: In this context, what's the best approach to put mailboxes on a
> separate machine? Let the LDA drop mails into NFS mounts, or let postfix
> transport the mails via transport_map into a machine which hosts the LDA
> (dovecot in our case)?
I recommend Dovecot via LMTP, but NFS
On 6/10/2014 3:05 PM, Jay G. Scott wrote:
>
> RE: the after-queue, simple filter example
>
> Just trying to figure out how it works.
> I have a feeling I don't fully understand the full implications of
> "after-queue".
>
> From master.cf:
> # custom filter
> filter unix- n
RE: the after-queue, simple filter example
Just trying to figure out how it works.
I have a feeling I don't fully understand the full implications of
"after-queue".
>From master.cf:
# custom filter
filter unix- n n - 10 pipe
flags=Rq user=filter null_se
Hello,
Subject: Problem understanding check_client_access and tcp_table
I have a problem understanding how to properly use check_client_access with
an external tcp_table (daemon)
in my main.cf i have put the following:
smtpd_client_restrictions = check_client_access tcp:[127.0.0.1]:1
The l
10.06.2014 22:43, Stan Hoeppner wrote:
> On 6/10/2014 1:24 AM, Michael Tokarev wrote:
[]
>> it all to one stage it becomes clumsier. Also, moving stuff which should
>> be run at connect or hello time to recipient time is kinda wrong.
>
> Postfix performs delayed evaluation of restrictions by defa
On Tue, Jun 10, 2014 at 01:43:50PM -0500, Stan Hoeppner wrote:
> > I'm sorry to say that, but this is wrong. All smtpd_*_restrictions give
> > precise control over all the restrictions and their order, if you move
>
> "will give you precise control". Note "you", meaning the user, not
> Postfix.
On 6/10/2014 1:24 AM, Michael Tokarev wrote:
> 10.06.2014 05:02, Stan Hoeppner wrote:
...
>> Yes. And if you have other separate smtpd_foo_restrictions sections you
>> should move those restriction parameters under
>> smtpd_recipient_restrictions as well. This will give you precise
>> control ove
On 6/10/2014 1:24 PM, Kai Krakow wrote:
> And those silly autodetection of older MUAs sticks to port 25
unencrypted. So even new customers who redo
> their installations on their own silently go back to port 25.
So... why on earth are you allowing UNENCRYPTED AUTH at ALL, let alone
on port 2
Peter schrieb:
> On 06/08/2014 08:17 PM, Kai Krakow wrote:
>> MX and Submission machine are the same postfix instance (and even the
>> same worker process on port 25), it won't work. I'm planning to maybe
>> change this in the future. But as with migrating all people to not submit
>> on port 25 i
Schwartz, Tobias (DAV):
> Dear Wietse,
>
> I apologize "accusing" Postfix.
> Looking at your answers, I think I have to investigate whether and
> why MailMan has put messages with the same message-id and same
> recipient multiple times to the smtp deamon.
When a mailing list has many recipients,
Dear Wietse,
I apologize "accusing" Postfix.
Looking at your answers, I think I have to investigate whether and why MailMan
has put messages with the same message-id and same recipient multiple times to
the smtp deamon.
Kindest regards,
Tobias
-Ursprüngliche Nachricht-
Von: owner-p
Schwartz, Tobias (DAV):
> Dear Wietse,
>
> thank you for your reply!
> You can find the log entries for a particular recipient below:
>
> Jun 5 15:25:18 172 postfix/smtpd[28500]: 9EE2B185BF0: client=unknown[::1]
> Jun 5 15:25:18 172 postfix/cleanup[29770]: 9EE2B185BF0:
> message-id=<1233AD723A
Ronald F. Guilmette:
>
> I really should have figured this out ages ago, but...
>
> Quite simply, there exits a small number of organizations that
> run afoul of my various smtpd_recipient_restrictions and/or my
> smtpd_helo_restrictions, but from which I need to be able to
> receive mail anyway.
Schwartz, Tobias (DAV):
> Do you know about any behavior of the qmgr, that could explain the
> duplicate transmission of messages?
You report a problem, and therefore it is your responsibility to
demonstrate that your claim is correct.
To prove that your claim is correct, you need to show logfile
On 10 Jun 2014, at 13:02, Eero Volotinen wrote:
> I need to rewrite incoming headers for one email address, how to do this?
>
> The main reason to do this is jira that accepts email only from one defined
> emails
> and I need to import mailinglist mails to that system.
>
> for example I need
Dear Postfix Community,
after reading the documentation "Postfix Architecture Overview", I thought that
"qmgr" would handle operations between the different queues correctly and
despite any connection or performance issues.
Our company uses Mailman via Postfix on a regular basis for mailings wi
Hi List,
I need to rewrite incoming headers for one email address, how to do this?
The main reason to do this is jira that accepts email only from one defined
emails
and I need to import mailinglist mails to that system.
for example I need to rewrite centos mailing-list from header to from
my@e
27 matches
Mail list logo