Grant,
Postfix speak for its authors. I'm grateful for it, like many others in IT
tech and business fields.
Since I'm not so experienced in TLS, maybe my answer is more close to your
level:
1) Have in mind that SMTP client servers are not web browsers, thus, they
don't act the same.
2) Removing
grantksupp...@operamail.com:
> Viktor,
>
> > Your server is fine. Google is using RC4 outbound, and it is their
> > responsibility to improve that, not yours.
>
> Thanks, for the pointers. That's cleared up & understood now.
>
> On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote:
> > Inste
Viktor,
> Your server is fine. Google is using RC4 outbound, and it is their
> responsibility to improve that, not yours.
Thanks, for the pointers. That's cleared up & understood now.
On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote:
> Instead of tinkering with carefully-chosen Postfix d
grantksupp...@operamail.com:
>
>
> On Sat, Jun 21, 2014, at 11:41 AM, Viktor Dukhovni wrote:
> > I repeat, these aren't the droids you're looking for.
>
> ok, no longer looking for those droids.
>
> returning to why I started looking for them in the 1st place, trying to
> understand/control the
On Sat, Jun 21, 2014 at 01:13:35PM -0700, grantksupp...@operamail.com wrote:
> looking at headers of mail sent FROM my my postfix server TO my gmail
> account
>
> Received: from mx.grantkX.com (mx.grantkX.com.
> [##.##.##.##])
> by mx.google.com with ESMTPS id
>
On Sat, Jun 21, 2014, at 11:41 AM, Viktor Dukhovni wrote:
> I repeat, these aren't the droids you're looking for.
ok, no longer looking for those droids.
returning to why I started looking for them in the 1st place, trying to
understand/control the strength of encryption to/from my server, maki
Wietse Venema:
> In that case the syntax would be:
>
> cache:!memcache:/etc/postfix/whatever!0:pipeline:
>
> There should be a "source" feature in the memcache client that is
> like a read-only version of "backup". Then, one could say:
>
> /etc/postfix/main.cf:
> whatever = ... memca
On Sat, Jun 21, 2014 at 03:06:53PM -0400, Wietse Venema wrote:
> Recent Postfix SMTP clients randomly select between IPv4 and IPv6
> so that mail won't get stuck when one of the two is down.
I had another look at the logs and as it turns out, that's exactly what
happens — I just happened to get th
Nils Steinger:
> Hi,
>
> my (dual-stack IPv4/6) mail server consistently delivers mails to
> @googlemail.com recipients via IPv6, but falls back to IPv4 for
Recent Postfix SMTP clients randomly select between IPv4 and IPv6
so that mail won't get stuck when one of the two is down.
Perhaps you hav
Hi,
my (dual-stack IPv4/6) mail server consistently delivers mails to
@googlemail.com recipients via IPv6, but falls back to IPv4 for
@gmail.com — even though it uses the same relay hostname
(gmail-smtp-in.l.google.com) in both cases.
What could possibly cause this behavior?
I've attached a singl
On Sat, Jun 21, 2014 at 10:49:17AM -0700, grantksupp...@operamail.com wrote:
> > See also:
> >
> > http://www.postfix.org/FORWARD_SECRECY_README.html
>
> Right. That's one of the specific documents I'd already referenced as
> having read in my OP. It's thorough, and to me, confusing. Whic
hi
On Sat, Jun 21, 2014, at 10:36 AM, Viktor Dukhovni wrote:
> The *default* Postfix TLS cipherlist settings are chosen with care.
> Best pracice is to leave them as-is.
>
> See also:
>
> http://www.postfix.org/FORWARD_SECRECY_README.html
Right. That's one of the specific documents I'd alr
On Sat, Jun 21, 2014 at 10:26:41AM -0700, grantksupp...@operamail.com wrote:
> I think I see the variety of options, and understand some of the
> pitfalls, as discussed, but TBH am a bit lost as to what the 'best
> practices' *recommendation* for the cipher list to use is? specifically
> for a PFS
On Sat, Jun 21, 2014, at 10:07 AM, Viktor Dukhovni wrote:
> > During a security audit, it was determined that the MX supported what
> > the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
> > RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
> > disable all those -
On Sat, Jun 21, 2014 at 01:11:04PM +0200, Stefan Foerster wrote:
> During a security audit, it was determined that the MX supported what
> the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
> RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
> disable all those -
Jose Borges Ferreira:
> Due to the limitation of not have the full recipient list in policy
> daemon ate OEM stage, a milter would be the best tool to achieve this.
Each recipient can be reported with the Milter RCPT event handler.
This combined with the queue ID, allows the Milter to maintain a
c
Jose Borges Ferreira:
> > Why not implement a cache: maptype that you can prepend to the
> > source (a pipeline any simple lookup table):
> >
> > cache:!maptype:mapname!ttl!pipeline...
> >
> > where maptype:mapname implements persistent storage. This searches
> > the persistent storage first, and i
On Wed, Jun 18, 2014 at 10:36 AM, mailing lists wrote:
> Hello all
>
> I'm trying to limit big mails to local lists using postfix+postfwd but I must
> be missing something because it seems too complex to me.
>
> Mail size is available in END-OF-MESSAGE (E-O-M) so I do size checks in this
> phase
On Sat, Jun 21, 2014 at 1:47 PM, Wietse Venema wrote:
> Jose Borges Ferreira:
>> Can you consider a similar behavior to allow caching.
>> Something like:
>>
>> if ( value = get_table1 () ) {
>> return value
>> } else {
>> value = get_table2();
>> set_table1(value,ttl);
>> return
> On 06/21/2014 01:11 PM, Stefan Foerster wrote:
>
> our current situation is as follows:
>
> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
> 2. Senders aren't known beforehand, i.e. no previous business relationship.
> 3. Senders' IT usually doesn't support DANE.
> 4. I
Jose Borges Ferreira:
> On Wed, Jun 18, 2014 at 10:15 PM, Wietse Venema wrote:
> > Each "pipeline:" query is given to the first table. Each table
> > lookup result becomes the query for the next table in the pipeline,
> > and the last table produces the final result. When any table lookup
> > pro
On Wed, Jun 18, 2014 at 10:15 PM, Wietse Venema wrote:
> Each "pipeline:" query is given to the first table. Each table
> lookup result becomes the query for the next table in the pipeline,
> and the last table produces the final result. When any table lookup
> produces no result, the entire pipe
On Sat, Jun 21, 2014 at 12:45 PM, Stefan Foerster
wrote:
> While I certainly share your view on this - though I would have worded
> it less strongly - my question still stands: Does anyone have real world
> data to share (e.g. "we disabled ciphers X, Y and Z and then N percent
> of clients failed
On Sat, Jun 21, 2014 at 12:21 PM, li...@rhsoft.net wrote:
>
>
> Am 21.06.2014 13:11, schrieb Stefan Foerster:
>> our current situation is as follows:
>>
>> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
>> 2. Senders aren't known beforehand, i.e. no previous business rela
* "li...@rhsoft.net" :
> Am 21.06.2014 13:11, schrieb Stefan Foerster:
> > Could someone share experience with or point me to some kind of "best
> > practices" regarding opportunistic TLS, or explain the reasoning for
> > banning "weak" ciphers/protocols on a public MX? (again, not talking
> > abou
Am 21.06.2014 13:11, schrieb Stefan Foerster:
> our current situation is as follows:
>
> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
> 2. Senders aren't known beforehand, i.e. no previous business relationship.
> 3. Senders' IT usually doesn't support DANE.
> 4. Inco
Hello world,
our current situation is as follows:
1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
2. Senders aren't known beforehand, i.e. no previous business relationship.
3. Senders' IT usually doesn't support DANE.
4. Incoming mail is considered highly(!) valuable to
27 matches
Mail list logo
