The IP address is propagated to the Milter as part of the SMFIC_CONNECT
event.
Therefore, configure the Milter with the SMTPD process that talks
to the IP address in question.
Wietse
On 10/13/18 9:46 AM, Matus UHLAR - fantomas wrote:
this is useless. milter is designed to be run directly at messsage
receiving, not during further processing.
On 13.10.18 09:59, pg...@dev-mail.net wrote:
I've had a production system with a different set of milters in 'the same
place' in Postf
On Sat, Oct 13, 2018, at 10:41 AM, Viktor Dukhovni wrote:
> As yet, I see no compelling reason to disable TLS 1.0 in SMTP.
Noted.
> What you can and should now disable is SSLv2 and SSLv3, which Postfix
> now disables by default.
Already done.
Ironically, FinCo's online 'security/privacy' mi
On Sat, Oct 13, 2018 at 12:12:21PM -0400, Bill Cole wrote:
> 2. As TLSv1.0 is increasingly abandoned by both TLS implementations and
> in operational configurations, novel vulnerabilities in the old protocol
> are more likely to remain covert and hence highly useful, especially if
> they are le
On 10/13/18 9:46 AM, Matus UHLAR - fantomas wrote:> this is useless. milter is
designed to be run directly at messsage
> receiving, not during further processing.
I've had a production system with a different set of milters in 'the same
place' in Postfix config running for quite awhile:
...
[
On 12.10.18 17:24, pg...@dev-mail.net wrote:
I'm experimenting with setting up & using various milters in my inbound
processing.
Atm, I have an internal postfix instance that receives mail from a pre-Q
instance of amavisd, which then submits the mail to a chain of milters,
then subsequently pass
On 12.10.18 17:01, K F wrote:
I will only activate it for our outgoing send array, not for incoming. I
know it will take up space, but our customers have expressed some wishes
about more knowlegde of the smtp transaction, and apparently can't Seattle
for the postfix error messages.
you can temp
On 12 Oct 2018, at 23:04, Peter wrote:
Issue #1 the use of TLSv1.0. Unless I'm mistaken the only actual
vulnerability to TLSv1.0 is BEAST, which can be (and likely is)
mitigated client-side, so if your version of openssl mitigates BEAST
then TLSv1.0 should actually be safe to use as a client.
On October 13, 2018 5:32:54 PM GMT+02:00, Gary wrote:
>
>https://support.google.com/mail/answer/81126?hl=en
>
>Look at "authenticate your mail" in the above link. Gmail required 1024
>bits. Google market dominance makes it a defacto standard.
They require to use at least 1024 bits keys for dk
On 13 Oct 2018, at 0:33, Bill Cole wrote:
TLSv1.0 with decent ciphers is unequivocally better than cleartext
transport, and most people do not have email worth the effort of
cracking TLSv1.0 to anyone capable of doing so.
CLARIFYING:
There's nothing (yet) known that makes all implementation
On Sat, Oct 13, 2018, at 8:32 AM, Gary wrote:
> Look at "authenticate your mail" in the above link. Gmail required 1024
> bits. Google market dominance makes it a defacto standard.
In this case, yes, that's a helpful reference to point folks at.
Generally, I don't accept/agree in the slightest
https://support.google.com/mail/answer/81126?hl=en
Look at "authenticate your mail" in the above link. Gmail required 1024 bits.
Google market dominance makes it a defacto standard.
Original Message
From: pg...@dev-mail.net
Sent: October 13, 2018 7:40 AM
To: postfix-users@postfix.org
Subje
I appreciate the comments on this.
Boils down to:
> ... moral of this story is
in no particular order,
**'Best/current Practice' _is_ better than sha1/dkim & TLSv1
**FinCo's lazy & sloppy, not worth rejecting, but I can flag & watch
**I've checked my ~12 month logs; FinCo re
On Saturday, October 13, 2018 2:02 AM, wrote:
> My suspicion is that this is NOT rising to "nuke the basatards" >smtp
> response, and that I should figure out how to get the >attention of the right
> persons (NOT 'customer service') at FinCo. >TBH, how to make that contact is
> beyond me; pu
14 matches
Mail list logo
