On Mon, Jul 07, 2014 at 08:38:02PM -0400, James Cloos wrote:
> VD> What sort of limit did you have in mind. The default is 20 per
> VD> nexthop domain (per recipient when the transports recipient
> VD> concurrency is 1). Split randomly across the domain's MX hosts.
> VD> This is unlikely to be a
> "ln" == lists@rhsoft net writes:
>> but still get as many Verified TLS connection established messages in
>> the logs as status=sent lines
ln> that is nonsense and don't say anyhting about *concurrent* connections
I don't know what you think is nonsense.
The MXs also show one mail per so
> "VD" == Viktor Dukhovni writes:
VD> What sort of limit did you have in mind. The default is 20 per
VD> nexthop domain (per recipient when the transports recipient
VD> concurrency is 1). Split randomly across the domain's MX hosts.
VD> This is unlikely to be a problem.
One or two sockets
On Mon, Jul 07, 2014 at 04:59:32PM -0400, Wietse Venema wrote:
> Would check_ccert_access do the job in a restriction class (a kludge
> to pre-open Postfix access tables):
There is a simpler way:
http://www.postfix.org/postconf.5.html#permit_tls_clientcerts
http://www.postfix.org
Hello Wietse!
> Hi Claus. Yes, Postfix does not send its own Received: header to
> the Milter (or whatever the first line is after Milters have modified
> the message).
So the second part is the problem here; thanks for the clarification.
For MeTA1 I added a flag to the pmilter API so a milter ca
On Mon, Jul 07, 2014 at 06:17:05PM -0400, James Cloos wrote:
> It can generate a large number of mails in a short time, so I'm trying
> to limit how many concurrent sockets pf on that box opens with my MXs.
What sort of limit did you have in mind. The default is 20 per
nexthop domain (per recipi
Am 08.07.2014 00:17, schrieb James Cloos:
> I working with an application which collects data and emails me the
> results. Reading it in a mailinglist-like fashion is optimal for me.
>
> It can generate a large number of mails in a short time, so I'm trying
> to limit how many concurrent socket
I working with an application which collects data and emails me the
results. Reading it in a mailinglist-like fashion is optimal for me.
It can generate a large number of mails in a short time, so I'm trying
to limit how many concurrent sockets pf on that box opens with my MXs.
Each subset of me
Claus Assmann:
> > For Sendmail compatibility, Postfix does not show the first header
> > line. I suggest that you put new content further down in the message.
>
> Does "the first header line" refer to the (locally added) Received:
> header?
Hi Claus. Yes, Postfix does not send its own Received:
A. Schulze:
> Hello,
>
> Abstract problem:
> allow a external third party to relay messages with
> one fixed envelope sender. Certificates must be used to allow relay
> permissions.
> Do I really need additional UserID+Passwords to limit to a specific
> envelope sender
> or could infor
On 7. jul. 2014 19.58.46 CEST, Noel Jones wrote:
>> Jul 6 08:26:29 mta1 postfix/postscreen[16943]: PASS OLD
>> [10.36.40.26]:45643
>The better solution is to identify and fix your network delay.
And whitelist rfc 1918 in postscreen
Am 07.07.2014 22:44, schrieb Ben Johnson:
> On 7/7/2014 2:47 PM, Ben Johnson wrote:
>> Thanks, Leonardo and Noel! I really appreciate the prompt replies.
>>
>> Leonardo, I see no indication that whomever is sending this mail has
>> authenticated. And given that local connections are permitted to s
Christian Rößner:
Unfortunately I found out that always the very first header of an
earlier milter is not visible in my milter.
christian,
The milter API knows two ways to add header:
1) https://www.milter.org/developers/api/smfi_addheader
2) https://www.milter.org/developers/api/smfi_inshe
On 7/7/2014 2:47 PM, Ben Johnson wrote:
> Thanks, Leonardo and Noel! I really appreciate the prompt replies.
>
> Leonardo, I see no indication that whomever is sending this mail has
> authenticated. And given that local connections are permitted to send
> mail without authenticating on this serv
> For Sendmail compatibility, Postfix does not show the first header
> line. I suggest that you put new content further down in the message.
Does "the first header line" refer to the (locally added) Received:
header? If so, sendmail doesn't provide that to a milter as it is
not sent by the client
Hello,
>> I am currently trying to develop a milter for Postfix. I need all
>> headers from a mail. Unfortunately I found out that always the
>> very first header of an earlier milter is not visible in my milter.
>
> For Sendmail compatibility, Postfix does not show the first header
> line. I sug
Hello,
Abstract problem:
allow a external third party to relay messages with
one fixed envelope sender. Certificates must be used to allow relay
permissions.
Do I really need additional UserID+Passwords to limit to a specific
envelope sender
or could information from the ccert be used?
On 7/7/2014 1:45 PM, Noel Jones wrote:
> On 7/7/2014 11:56 AM, Leonardo Rodrigues wrote:
>> Em 07/07/14 13:24, Ben Johnson escreveu:
>>> Hello!
>>>
>>> I've noticed increased Postfix activity as of late and am
>>> concerned that
>>> something is configured inadequately (i.e., open-relay). For
>>>
Christian R??ner:
>
> I am currently trying to develop a milter for Postfix. I need all
> headers from a mail. Unfortunately I found out that always the
> very first header of an earlier milter is not visible in my milter.
For Sendmail compatibility, Postfix does not show the first header
line. I
Hi,
I am currently trying to develop a milter for Postfix. I need all headers from
a mail. Unfortunately I found out that always the very first header of an
earlier milter is not visible in my milter.
I run:
amavis, opendkim, …, my_milter
I am interested in header fields created by amavis.
I
btb:
> On 2014.07.07 12.39, Wietse Venema wrote:
> > Find out why it takes 6.2 seconds to connect over TCP and to
> > complete the SMTP handshake with the remote SMTP server.
>
> given postscreen_greet_wait, it's a coincidence that the remote server's
> postscreen logs show that same delay ~6 sec
On 7/7/2014 12:36 PM, btb wrote:
> On 2014.07.07 12.39, Wietse Venema wrote:
>> Find out why it takes 6.2 seconds to connect over TCP and to
>> complete the SMTP handshake with the remote SMTP server.
>
> given postscreen_greet_wait, it's a coincidence that the remote
> server's postscreen logs sh
On 7/7/2014 11:56 AM, Leonardo Rodrigues wrote:
> Em 07/07/14 13:24, Ben Johnson escreveu:
>> Hello!
>>
>> I've noticed increased Postfix activity as of late and am
>> concerned that
>> something is configured inadequately (i.e., open-relay). For
>> "postconf
>> -n" output, please skip to the end o
On 2014.07.07 12.39, Wietse Venema wrote:
Find out why it takes 6.2 seconds to connect over TCP and to
complete the SMTP handshake with the remote SMTP server.
given postscreen_greet_wait, it's a coincidence that the remote server's
postscreen logs show that same delay ~6 second delay, but lis
Am 07.07.2014 18:39, schrieb Wietse Venema:
> btb:
>> Jul 6 08:26:29 msa-aux postfix/example-internal/smtp[2553]:
>> 3h5pzz1NVpzyQm: to=,
>> relay=mta.example.com[10.3.70.5]:25, delay=6.4, delays=0.01/0.02/6.2/0.21,
>> dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
>
> It took 6.4 seconds to verify
Em 07/07/14 13:24, Ben Johnson escreveu:
Hello!
I've noticed increased Postfix activity as of late and am concerned that
something is configured inadequately (i.e., open-relay). For "postconf
-n" output, please skip to the end of this message.
It's much easier that you had some account hi
btb:
> Jul 6 08:26:29 msa-aux postfix/example-internal/smtp[2553]:
> 3h5pzz1NVpzyQm: to=,
> relay=mta.example.com[10.3.70.5]:25, delay=6.4, delays=0.01/0.02/6.2/0.21,
> dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
It took 6.4 seconds to verify this recipient, of which 6.2 seconds
were spent conne
On 2014.07.07 12.25, btb wrote:
we use recipient address verification amongst some of our own domains. on
occasion, i see the following log entries:
Jul 6 08:26:22 msa-aux postfix/smsp/smtpd[2545]: connect from
client.example.com[10.48.40.102]
Jul 6 08:26:22 msa-aux postfix/smsp/smtpd[2545]
we use recipient address verification amongst some of our own domains. on
occasion, i see the following log entries:
Jul 6 08:26:22 msa-aux postfix/smsp/smtpd[2545]: connect from
client.example.com[10.48.40.102]
Jul 6 08:26:22 msa-aux postfix/smsp/smtpd[2545]: Anonymous TLS connection
establ
Hello!
I've noticed increased Postfix activity as of late and am concerned that
something is configured inadequately (i.e., open-relay). For "postconf
-n" output, please skip to the end of this message.
So, I installed pflogsumm and my concerns seem valid. I'll address each
point of concern.
Fir
* Wietse Venema :
> Ralf Hildebrandt:
> > -DUSE_DYNAMIC_LIBS -DUSE_DYNAMIC_MAPS -g -O -I. -I../../include -DLINUX3
> > -Wl,-rpath,/usr/lib/postfix -o master master.o master_conf.o
> > master_ent.o master_sig.o master_avail.o master_spawn.o master_service.o
> > master_status.o master_listen.o mas
Ralf Hildebrandt:
> -DUSE_DYNAMIC_LIBS -DUSE_DYNAMIC_MAPS -g -O -I. -I../../include -DLINUX3
> -Wl,-rpath,/usr/lib/postfix -o master master.o master_conf.o
> master_ent.o master_sig.o master_avail.o master_spawn.o master_service.o
> master_status.o master_listen.o master_vars.o
> master_wakeup.o
After my initial (ultimately successful) attempts with shared=yes, I
gave "dynamicmaps=yes" a spin, like this:
make tidy
CCARGS="`pkg-config --cflags openssl libpcre libcdb` -DUSE_TLS -DHAS_PCRE
-DHAS_CDB -DHAS_LDAP" \
AUXLIBS="`pkg-config --libs openssl` -lnsl" \
AUXLIBS_CDB="`pkg-config --li
Am 07.07.2014 10:31, schrieb Toney Mareo:
>
> Hello
>
> I have the dmesg loaded with lmtp crash messages.
> My OS:
>
>
> No LSB modules are available.
> Distributor ID:Debian
> Description:Debian GNU/Linux 7.4 (wheezy)
> Release:7.4
> Codename:wheezy
>
> My postfix version:
Hello
I have the dmesg loaded with lmtp crash messages.
My OS:
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.4 (wheezy)
Release: 7.4
Codename: wheezy
My postfix version:
i postfix 2.9.6-2
35 matches
Mail list logo
