* Marvin Renich [140722 13:12]:
> * Wietse Venema [140722 12:59]:
> > /etc/postfix/main.cf:
> > submission ...
> > -o cleanup_service=cleanup-outbound
> >
> > /etc/postfix/master.cf:
> > cleanup-outbound .. .. .. .. cleanup
> > -o sender_bcc_maps=$outgoing_bcc_maps
>
> Thanks!
Marvin Renich:
> * Wietse Venema [140722 12:59]:
> > sender_bcc_maps is not implemented by smtpd(8) but by cleanup(8).
> > This is consistent with the information in the manpage.
>
> Okay, now I see it in cleanup(8); I was looking in postconf(5) under
> sender_bcc_maps.
>
> > You can work around
* Wietse Venema [140722 12:59]:
> sender_bcc_maps is not implemented by smtpd(8) but by cleanup(8).
> This is consistent with the information in the manpage.
Okay, now I see it in cleanup(8); I was looking in postconf(5) under
sender_bcc_maps.
> You can work around this with:
>
> /etc/postfix/m
Marvin Renich:
> I have enabled the submission service in master.cf:
>
> submission inet n - - - - smtpd
> -o syslog_name=postfix/submission
> -o smtpd_tls_security_level=encrypt
> -o smtpd_sasl_auth_enable=yes
> -o smtpd_reject_unliste
I have enabled the submission service in master.cf:
submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions
Ed W:
> Therefore I'm suggesting that the out of the box config matches the
> *RFC*. Then if the mail owner wants to lock it down to some non RFC
> suggested spec they can read the instructions.
Wietse:
> SHOULD does not forbid mandatory TLS; only a twisted mind will read
> this as "support for p
On 2012-03-16 6:41 AM, Ed W wrote:
You are arguing in circles. The original point of this thread was to
suggest the defaults better match sensible out of the box defaults.
The specs say "may" offer TLS (not required).
No, they say *should*, which, in my book, is the best argument for the
de
On 16/03/2012 11:57, Wietse Venema wrote:
Ed W:
Therefore I'm suggesting that the out of the box config matches the
*RFC*. Then if the mail owner wants to lock it down to some non RFC
suggested spec they can read the instructions.
SHOULD does not forbid mandatory TLS; only a twisted mind will
Ed W:
> Therefore I'm suggesting that the out of the box config matches the
> *RFC*. Then if the mail owner wants to lock it down to some non RFC
> suggested spec they can read the instructions.
SHOULD does not forbid mandatory TLS; only a twisted mind will read
this as "support for plaintext i
On 16/03/2012 07:06, Robert Schetterer wrote:
I forget the exact issue now, but note that I'm not saying that it
*can't* work. What I'm saying is that I have a bunch of "normal" non
technical users. "Johnny" runs through the wizard on his favourite
device and then costs me money in tech support
Am 16.03.2012 00:02, schrieb Ed W:
> On 15/03/2012 13:01, Victoriano Giralt wrote:
>>
>> DTNX/NGMX Postmaster wrote:
>>
>>> I don't know about Android, but we have not seen any issues with the
>>> iPhone/iPad. Works fine with TLS 'encrypt' in our setups, as suggested
>>> above.
>> In my experience
On 15/03/2012 13:01, Victoriano Giralt wrote:
DTNX/NGMX Postmaster wrote:
I don't know about Android, but we have not seen any issues with the
iPhone/iPad. Works fine with TLS 'encrypt' in our setups, as suggested
above.
In my experience, both the manufacturer provided and added mail clients
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
DTNX/NGMX Postmaster wrote:
>I don't know about Android, but we have not seen any issues with the
>iPhone/iPad. Works fine with TLS 'encrypt' in our setups, as suggested
>above.
In my experience, both the manufacturer provided and added mail clie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
SamLT wrote:
>Sorry for the OT, but does s_client even works with IPv6? I've never
>found how?
In my experience, limited to bare IPv6 addresses, it does not.
- --
Victoriano Giralt
Enviado desde el movil / Sent from mobile
-BEGIN PGP SIGNATU
On Mar 14, 2012, at 21:03, Patrick Ben Koetter wrote:
> * Charles Marcus :
>> On 2012-03-14 2:39 PM, Ed W wrote:
>>> I see no reason to *require* encryption on the submission port (RFC
>>> aside).
>>
>> Unless you prefer that sniffers not be able to see your passwords
>> crossing the wire in pla
ut one mail client, I think it might be an
> Android or iPhone mail client(?) defaults to using the submission service but
> without encryption. The error messages were confusing and unhelpful to the
> customer and I just recall it took some time to realise that it was the
> enforc
On Thu, Mar 15, 2012 at 10:44:33AM +0100, Victoriano Giralt wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> Victoriano Giralt wrote:
>
> >And I have found that gnutls-climate is better for testing IPv6
> >servers.
> Stupid autocorrection, I meant gnutls-cli
Sorry for the OT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Victoriano Giralt wrote:
>And I have found that gnutls-climate is better for testing IPv6
>servers.
Stupid autocorrection, I meant gnutls-cli
- --
Victoriano Giralt
Enviado desde el movil / Sent from mobile
-BEGIN PGP SIGNATURE-
Version:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ulrich Zehl wrote:
>For basic testing, I tend to use "gnutls-cli --starttls", where it
>starts a
>plain text session, and only begins TLS negotiation when you send it
>EOF
>(or SIGALRM, but ^D has always been easy enough for me).
>As far as I kno
On Wed, Mar 14, 2012 at 08:52:54PM -0500, Noel Jones wrote:
> Yes, I would always choose telnet first. Unfortunately, if you want
> to test an encrypted session telnet fails miserably.
>
> The [press R to renegotiate] behavior of s_client is documented and,
> last time I looked, can't be disabled
On 3/14/2012 5:09 PM, Patrick Ben Koetter wrote:
> * Noel Jones :
>> AFAIK OpenSSL works OK for testing SMTP as long as you avoid
>> sending/pressing the upper-case "R" character, which triggers TLS
>> renegotiation (and an SMTP error). Issuing the SMTP commands in
>> lower-case is the usual worka
On 03/14/2012 04:03 PM, Patrick Ben Koetter wrote:
* Charles Marcus:
On 2012-03-14 2:39 PM, Ed W wrote:
I see no reason to *require* encryption on the submission port (RFC
aside).
Unless you prefer that sniffers not be able to see your passwords
crossing the wire in plaintext?
I think "may
* Noel Jones :
> On 3/14/2012 4:50 PM, Patrick Ben Koetter wrote:
> > * Wietse Venema :
> >> Patrick Ben Koetter:
> >>>>> That's not a problem for me. I don't use the submission service
> >>>>> and rely on input from the real world
On 3/14/2012 4:50 PM, Patrick Ben Koetter wrote:
> * Wietse Venema :
>> Patrick Ben Koetter:
>>>>> That's not a problem for me. I don't use the submission service
>>>>> and rely on input from the real world for this.
>>>>
>&
* Wietse Venema :
> Patrick Ben Koetter:
> > > > That's not a problem for me. I don't use the submission service
> > > > and rely on input from the real world for this.
> > >
> > > Meaning, "may", combined with a setting that allow
Patrick Ben Koetter:
> > > That's not a problem for me. I don't use the submission service
> > > and rely on input from the real world for this.
> >
> > Meaning, "may", combined with a setting that allows plaintext
> > passwords only over en
_level=encrypt
> > >
> > > I forget the exact details now, but one mail client, I think it might be
> > > an Android or iPhone mail client(?) defaults to using the submission
> > > service but without encryption. The error messages were confusing and
> > &
* Charles Marcus :
> On 2012-03-14 2:39 PM, Ed W wrote:
> >I see no reason to *require* encryption on the submission port (RFC
> >aside).
>
> Unless you prefer that sniffers not be able to see your passwords
> crossing the wire in plaintext?
>
> >I think "may" is a more appropriate default?
>
>
act details now, but one mail client, I think it might be
> > an Android or iPhone mail client(?) defaults to using the submission
> > service but without encryption. The error messages were confusing and
> > unhelpful to the customer and I just recall it took some time to
t might be
> an Android or iPhone mail client(?) defaults to using the submission
> service but without encryption. The error messages were confusing and
> unhelpful to the customer and I just recall it took some time to realise
> that it was the enforced tls requirement that was the p
On 2012-03-14 2:39 PM, Ed W wrote:
I see no reason to *require* encryption on the submission port (RFC
aside).
Unless you prefer that sniffers not be able to see your passwords
crossing the wire in plaintext?
I think "may" is a more appropriate default?
Disagree vehemently.
--
Best reg
(?) defaults to using the submission
service but without encryption. The error messages were confusing and
unhelpful to the customer and I just recall it took some time to realise
that it was the enforced tls requirement that was the problem
I see no reason to *require* encryption on the submission
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
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
>
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 lo
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
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 o
* 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
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
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 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.
* 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
--
* Wietse Venema :
> Patrick Ben Koetter:
> > 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
Patrick Ben Koetter:
> 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
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 general
nature.
Now that submission has become more p
service. Now the submission
service is tied up to storage instance.
I want to do the same thing with the submission - to have a dedicated
submissions server and all clients tot use a global/unified submission
server.
I have a unified database with all users/pass/storage and from the
thread
On Tue, 8 Jun 2010, Phil Howard wrote:
On Tue, Jun 8, 2010 at 13:06, Larry Stone wrote:
And did you even read what I wrote? I am well aware you made a typo earlier.
I understand what you meant and said nothing about the mistake.
I think this is a case of users being mixed up. I did not mak
On Tue, Jun 8, 2010 at 13:06, Larry Stone wrote:
> And did you even read what I wrote? I am well aware you made a typo earlier.
> I understand what you meant and said nothing about the mistake.
I think this is a case of users being mixed up. I did not make the
typo ... Dan did. I reported the
On Tue, 8 Jun 2010, Phil Howard wrote:
On Tue, Jun 8, 2010 at 09:47, Larry Stone wrote:
On Tue, 8 Jun 2010, Phil Howard wrote:
On Fri, Jun 4, 2010 at 18:31, Sahil Tandon wrote:
On Fri, 04 Jun 2010, Dan Burkland wrote:
Relevant configuration entries:
---main.cf
smtpd_recipie
On Tue, Jun 8, 2010 at 09:47, Larry Stone wrote:
> On Tue, 8 Jun 2010, Phil Howard wrote:
>
>> On Fri, Jun 4, 2010 at 18:31, Sahil Tandon wrote:
>>>
>>> On Fri, 04 Jun 2010, Dan Burkland wrote:
>>>
Relevant configuration entries:
---main.cf
smtpd_recipient_restrict
Using all of your helpful suggestions I was able to properly configure my
Postfix server. The purpose behind master.cf makes a bit more sense now after
reading your replies. Thanks again!
Dan
On Tue, 8 Jun 2010, Phil Howard wrote:
On Fri, Jun 4, 2010 at 18:31, Sahil Tandon wrote:
On Fri, 04 Jun 2010, Dan Burkland wrote:
Relevant configuration entries:
---main.cf
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
^
---mas
On Fri, Jun 4, 2010 at 18:31, Sahil Tandon wrote:
> On Fri, 04 Jun 2010, Dan Burkland wrote:
>
>> Relevant configuration entries:
>>
>> ---main.cf
>> smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
> ^
>
>> ---master.cf---
>> submissio
On Fri, 04 Jun 2010, Dan Burkland wrote:
> Relevant configuration entries:
>
> ---main.cf
> smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
^
> ---master.cf---
> submissioninetn - n - - smtpd
>
Phil Howard:
> On Fri, Jun 4, 2010 at 17:16, Wietse Venema wrote:
>
> > You need -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
> > to get relay permissions.
>
> Is that for the submission entry or the smtp entry (that he didn't
> provide)?
Allow me to place my advice in cont
On Fri, Jun 4, 2010 at 17:16, Wietse Venema wrote:
> You need -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
> to get relay permissions.
Is that for the submission entry or the smtp entry (that he didn't
provide)? It looks to me like he used mostly the example for
submission.
Dan Burkland:
> Hello all,
>
> I have been trying to setup my Postfix server as follows:
>
> a) Clients need to use STARTTLS + Authentication in order to send mail using
> my SMTP Server. They can only submit mail on port 587 (25 for submission is
> disallowed).
> b) Port 25 is to be used for
On Fri, Jun 4, 2010 at 16:52, Dan Burkland wrote:
> My apologies, I typed the parameter in the email incorrectly. It is entered
> correctly in main.cf
> (smtpd_client_restrictions=permit_sasl_authenticated,reject)
OK, then that looks fine. Since you are having trouble on port 25,
can you show
-Original Message-
My apologies, I typed the parameter in the email incorrectly. It is entered
correctly in main.cf
(smtpd_client_restrictions=permit_sasl_authenticated,reject)
Regards,
Dan
-Original Message-
Seems like I am dyslexic today, I meant to say master.cf (TGIF :))
-Original Message-
From: Phil Howard [mailto:ttip...@gmail.com]
Sent: Friday, June 04, 2010 3:48 PM
To: Dan Burkland
Cc: Postfix users
Subject: Re: Submission service
On Fri, Jun 4, 2010 at 16:21, Dan Burkland wrote:
> ---main.cf
> smtpd_recipient_restri
On Fri, Jun 4, 2010 at 16:21, Dan Burkland wrote:
> ---main.cf
> smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
>
> ---master.cf---
> submission inet n - n - - smtpd
> -o smtpd_enforce_tls=yes
> -
Hello all,
I have been trying to setup my Postfix server as follows:
a) Clients need to use STARTTLS + Authentication in order to send mail using my
SMTP Server. They can only submit mail on port 587 (25 for submission is
disallowed).
b) Port 25 is to be used for MTA-to-MTA communication and
Noel Jones wrote:
To fix this, just add
-o receive_override_options=
(ie. an empty value)
to your submission service.
Now it's working.
Thanks.
rafael.
rafa wrote:
Hello everyone,
I created a second cleanup for the submission service to have separate
header checks from incoming emails.
cleanup-out unix n - - - 0 cleanup
-o header_checks=pcre:/etc/postfix/header_checks-out
-o body_checks=pcre
Hello everyone,
I created a second cleanup for the submission service to have separate
header checks from incoming emails.
cleanup-out unix n - - - 0 cleanup
-o header_checks=pcre:/etc/postfix/header_checks-out
-o body_checks=pcre:/etc/postfix
66 matches
Mail list logo
