On Mar 13, 2012, at 17.01, mouss wrote:
> Le 13/03/2012 19:07, b...@bitrate.net a écrit :
>> i've been experimenting with delivery for the virtual domain class to
>> dovecot via lmtp - e.g.
>>
>>> postconf virtual_transport
>> virtual_transport = lmtp:[localhost]:lmtp-deliver
>>
>> this works f
I'm going to keep it simple: one template for the submission (port 587)
service, and one for smtps (which still seems to be needed in some
places). Three mail submission-like templates becomes unwieldy.
- Both templates override the main.cf settings for smtpd_*_restrictions
to avoid surprises when
* Nikolaos Milas :
> On 13/3/2012 9:51 μμ, Wietse Venema wrote:
>
> >I was looking for simple "yes" or "no" answers, not for protocol diagrams.
>
> Although Quanah is the real expert (and I am not , I would say that:
>
> Client and server must speak the same protocol: if client asks to
> talk v2
Hey mouss,
* mouss :
> Le 13/03/2012 00:25, Patrick Ben Koetter a écrit :
> > Wietse et al.
> >
> > With the arrival of postscreen, but also before I find myself repeatedly
> > changing the defaults for the 'submission' service in master.cf. I believe
> > the
> > changes I apply are not rooted i
Le 13/03/2012 00:25, Patrick Ben Koetter a écrit :
> Wietse et al.
>
> With the arrival of postscreen, but also before I find myself repeatedly
> changing the defaults for the 'submission' service in master.cf. I believe the
> changes I apply are not rooted in my local mail policies, but of genera
Le 13/03/2012 19:07, b...@bitrate.net a écrit :
> i've been experimenting with delivery for the virtual domain class to dovecot
> via lmtp - e.g.
>
>> postconf virtual_transport
> virtual_transport = lmtp:[localhost]:lmtp-deliver
>
> this works fine.
>
> out of curiosity, i wondered if the part
On 13/3/2012 9:51 μμ, Wietse Venema wrote:
I was looking for simple "yes" or "no" answers, not for protocol diagrams.
Although Quanah is the real expert (and I am not , I would say that:
Client and server must speak the same protocol: if client asks to talk
v2, server must support it explici
Quanah Gibson-Mount:
> --On Tuesday, March 13, 2012 3:00 PM -0400 Wietse Venema
> wrote:
>
> > Patrick Ben Koetter:
> >> While I am at it: Practically any LDAP server I connect Postfix to
> >> expects to speak LDAPv3. Shouldn't we bump up the default from 2 to 3?
> >> It would be one setting les
--On Tuesday, March 13, 2012 3:00 PM -0400 Wietse Venema
wrote:
Patrick Ben Koetter:
While I am at it: Practically any LDAP server I connect Postfix to
expects to speak LDAPv3. Shouldn't we bump up the default from 2 to 3?
It would be one setting less to provide explicitly.
I don't know wha
On Tuesday, March 13, 2012 07:46:09 PM Robert Schetterer wrote:
> Am 13.03.2012 17:37, schrieb Patrick Ben Koetter:
> > * Patrick Ben Koetter :
> >> * Wietse Venema :
> >>> Different sites have different needs, and perhaps it is an idea to
> >>> provide *multiple* submission service examples in mas
Patrick Ben Koetter:
> While I am at it: Practically any LDAP server I connect Postfix to expects to
> speak LDAPv3. Shouldn't we bump up the default from 2 to 3? It would be one
> setting less to provide explicitly.
I don't know what the consequences would be: can a v2 client talk
to a v3 server?
Am 13.03.2012 17:37, schrieb Patrick Ben Koetter:
> * Patrick Ben Koetter :
>> * Wietse Venema :
>>> Different sites have different needs, and perhaps it is an idea to
>>> provide *multiple* submission service examples in master.cf, all
>>> commented out of course. The first could be the recommende
i've been experimenting with delivery for the virtual domain class to dovecot
via lmtp - e.g.
>postconf virtual_transport
virtual_transport = lmtp:[localhost]:lmtp-deliver
this works fine.
out of curiosity, i wondered if the particulars could be somehow moved into a
service definition in maste
On 13/3/2012 7:20 μμ, Quanah Gibson-Mount wrote:
I do the following as part of CCARGS to postfix:
Thank you Quanah,
Your post certainly provides valuable info regarding building from source.
I am now mainly trying to research how to pass the paths through a spec
file... (I have been buildin
On Thu, Mar 08, 2012 at 07:47:47PM -0500, Wietse Venema wrote:
> Ben Rosengart:
> > If, upstream, I separate the recipients into different transports,
> > will this cause the upstream Postfix to "split the envelope" and send
> > the mail in >1 transaction, even though both transports are implemente
--On Tuesday, March 13, 2012 6:46 PM +0200 Nikolaos Milas
wrote:
Hello,
Now, how can we specify custom paths to LDAP libraries, header files,
etc. in the spec file ?
I do the following as part of CCARGS to postfix:
-DHAS_LDAP -DHAS_MYSQL -DUSE_TLS $(DBINC) $(PCRE_DEF)
$(PCRE_INCLUD
Hello,
This is a question to people who have some experience in building
Postfix RPMs.
I am trying to build Postfix RPMs for RHEL/CentOS 5 x86_64. These RPMs
should have standard options (those that are included in the standard
CentOS Postfix RPM).
The idea is to use
http://ftp.wl0.org/of
While I am at it: Practically any LDAP server I connect Postfix to expects to
speak LDAPv3. Shouldn't we bump up the default from 2 to 3? It would be one
setting less to provide explicitly.
p@rick
--
All technical questions asked privately will be automatically answered on the
list and archived
* Patrick Ben Koetter :
> * Wietse Venema :
> > Different sites have different needs, and perhaps it is an idea to
> > provide *multiple* submission service examples in master.cf, all
> > commented out of course. The first could be the recommended one:
> > not allowing plaintext sessions is good as
On 9/3/2012 7:09 μμ, Wietse Venema wrote:
Negative. The mail is rejected by a non-Postfix machine.
Just as a follow up, I would like to confirm that the message was indeed
from our gateway machine (Ironport).
Thank you for your help in resolving the issue.
Nick
Patrick Domack:
> Quoting Wietse Venema :
>
> > Patrick Ben Koetter:
> >> - Do not delay on port 25 for MTA to MTA communication
> >
> > With this. the sysadmin has no clue about what mail is blocked.
> > Even postscreen goes through great efforts to report the
> > sender and recipient of blocked
Thanks rob0,
Thanks for your reply.
I will try route sendmail to postfix, successful will update.
Regards,
Ramesh
From: /dev/rob0
To: postfix-users@postfix.org
Sent: Tuesday, 13 March 2012 6:26 PM
Subject: Re: relaying
On Tue, Mar 13, 2012 at 02:08:05PM
Quoting Wietse Venema :
Patrick Ben Koetter:
- Do not delay on port 25 for MTA to MTA communication
With this. the sysadmin has no clue about what mail is blocked.
Even postscreen goes through great efforts to report the
sender and recipient of blocked mail.
Along these lines, would patchin
On Tue, Mar 13, 2012 at 02:08:05PM +0800, Ramesh wrote:
> Is it possible to force sendmail on a remote host to relay
> all messages through server running postfix.
>
> currently email are sent through postini because domainX MX
> record points to postini, I want sendmail on domainX to send
> direc
On 03/13/2012 01:51 AM, Wietse Venema wrote:
> The first could be the recommended one:
> not allowing plaintext sessions is good as a general rule. The
> second example could allow plaintext sessions (level = may) but
> allow plaintext passwords only over encrypted sessions.
While ninjas are being
Patrick Ben Koetter:
> - Do not delay on port 25 for MTA to MTA communication
With this. the sysadmin has no clue about what mail is blocked.
Even postscreen goes through great efforts to report the
sender and recipient of blocked mail.
Recommending this change would be a major mistake.
On 2012-03-13 11:45 AM, Peter Bauer wrote:
> Additionally I don't like to pay for a TLS certificate, I would like to
> simply import the public key of the SMTP server of my friend into my local
> postfix installation (and vice versa for him).
>
> How can we do that? I found no possibility to add
Hello,
I would like to use only trusted TLS connections to a SMTP server of a friend
of mine.
If the trusted TLS connections fails, I would like that Postfix abort the
sending or reception with appropriate error messages than the sender or
receiver will be notified about that mail could not be
* Patrick Ben Koetter :
> You would not recommend it in general or not on 587? The latter would be my
> recommendation:
>
> - Do not delay on port 25 for MTA to MTA communication
> - Delay on port 587 for MUA to MTA communication
I'd keep smtpd_delay_reject at its default for both 25 & 587
--
29 matches
Mail list logo
