I see countless Postscreen rejections of this type
Nov 14 13:28:58 mx postfix/postscreen[11068]: CONNECT from
[86.49.239.233]:19243 to [#.#.#.#]:25
Nov 14 13:28:58 mx postfix/dnsblog[11069]: addr 86.49.239.233 listed by
domain bl.spamcop.net as 127.0.0.2
Nov 14 13:28:58
Viktor
On Wed, Nov 7, 2018, at 8:34 AM, Viktor Dukhovni wrote:
> ...
Thx for the clarifications!
> That's TLS 1.3, which as I mentioned is a different beast. It
> always does PFS, and never RSA key exchange, but this is not reflected
> in the cipher name, because the ciphers no longer specify
Viktor,
On Wed, Nov 7, 2018, at 12:03 AM, Viktor Dukhovni wrote:
> Check your logs for evidence of TLS <= 1.2 ciphers
Doing the quick check you mentioned, first for my messy 'test' server, results
are just
11 TLS_AES_256_GCM_SHA384
Those log messages, for me, are all generated on
Hi
On Fri, Nov 2, 2018, at 12:28 PM, Scott Kitterman wrote:
> > Without a Postfix instance around, just 'echo' a message to the milter
> > listener?
>
> If you still want to go down this path, OpenDKIM has a miltertest component
> to
> drive it's test suite without an MTA present. I have not
> > Without a Postfix instance around, just 'echo' a message to the
> > milter listener?
>
> Nope. Milters speak a binary protocol. You can't just echo an email
> message into it.
>
> I think it would be easier to implement your tests with SMTP, using
> XCLIENT to impersonate any IP address,
I'm starting to work on writing my own outbound milter for a Postfix instance.
While working on it, I'll want to test with message submissions "to" it.
Is there a good example of manually submitting a robust -- i.e., exactly as
from a running, Postfix instance -- message example to a milter?
On Fri, Oct 19, 2018, at 10:31 AM, Bill Cole wrote:
> > Is there any particular significance to the complete lack of its
> > mention on:
> >
> > http://www.postfix.org/addon.html
>
> Certainly. It is very strong evidence that no one has ever bothered
> emailing Dr. Venema to ask for its
On Fri, Oct 19, 2018, at 8:37 AM, Bill Cole wrote:
> I use MIMEDefang, not because Amavis is bad (it's not) but because I
> prefer to have *all* of my message filtering & manipulation handled in
> one place and I've been using MD longer than Postfix. Postfix is NOT a
> robust message
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'
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 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
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
> RFC 8301 removes rsa-sha1 from DKIM, so "FinCo" isn't wrong to consider
> the signature invalid. It's a bit aggressive for my taste, be it's the
> receivers call. The most I might do is ignore the signature. It's
> definitely not a reason to block the message.
Thanks for the relevant
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 passes it onto a post-Q amavisd instance for
1st, this is -- for me -- a postix/mail-RELATED security question. But if it's
too general, I'm happy to take it elsewhere; suggestions as to the appropriate
forum, if not here, are welcome.
A 'major financial institution', call 'em "FinCo", sends email to users on my
server that arrives with
On Thu, Oct 11, 2018, at 3:51 PM, Viktor Dukhovni wrote:
> Check the user "named" runs as after chroot and dropping privs has
> write permissions to update the root trust-anchor file (may need
> write permissions to the containing directory to make the update
> atomic).
thanks! I _think_ I'm set
On Thu, Oct 11, 2018, at 2:33 PM, Bill Cole wrote:
> > Isn't 'hardwired' here afaict. Looking at the ICANN site -- again --
> > is probably best advice.
>
> Since you're running BIND, https://kb.isc.org/docs/aa-01182 might be
> more specifically helpful, although I'm not sure that you can
On Thu, Oct 11, 2018, at 11:03 AM, Jamie Nelson wrote:
> https://www.icann.org/dns-resolvers-checking-current-trust-anchors
was JUST looking for that! thx.
On Thu, Oct 11, 2018, at 10:58 AM, Viktor Dukhovni wrote:
> This does not look like a forwarder problem, your own trusted key
> list is not up to date. Either it is manually maintained, or
> automated updates are failing (perhaps permission problems to update
> the files, the keys need to be
On Thu, Oct 11, 2018, at 10:53 AM, Jim Reid wrote:
> Although switching off DNSSEC validation will keep the mail flowing, it
> only kludges around the underlying problem. Which might or might not be
> related to the rollover of the root KSK a few hours ago. It’s hard to
> tell from the
On Thu, Oct 11, 2018, at 9:40 AM, Viktor Dukhovni wrote:
> On Thu, Oct 11, 2018 at 11:24:13AM -0400, Viktor Dukhovni wrote:
>
> > In case you've not seen this many other places, just a friendly
> > reminder that ICANN is rolling the DNSSEC root KSK today. Make
> > sure your resolver (if it is
On Thu, Oct 11, 2018, at 1:21 AM, Dominic Raferd wrote:
> I have had no problems with opendkim
I didn't either. Do now. Consistent crashing whether distro-installed or
DIY-builds.
Crashes appear malloc related; reported to upstream. Unfortunately, LOTS of
bugs there with very little, if
On Thu, Oct 11, 2018, at 12:48 AM, B. Reino wrote:
> I can recommend rspamd. The DKIM module is very flexible, supports
> multiple domains, etc.
rspamd is in the same bucket as amavis from my perspective.
I prefer a single-function/focus tool rather than a 'swiss-army knife' approach
On Wed, Oct 10, 2018, at 7:23 PM, pg...@dev-mail.net wrote:
> Now to trundle off to see if your dkimpy supports/uses Signing/Key
> tables for multi-domain support ...
appears that's a "no" for now ...
"...
domains is implied by the lines in that file. [SigningTable NOT
On Wed, Oct 10, 2018, at 7:16 PM, Scott Kitterman wrote:
> I gave up on OpenDKIM
Same here. Too many crashes, and too little response. Moved on.
> and wrote my own:
> https://launchpad.net/dkimpy-milter
Gr8, thx. I've used a number of your products (thx agn!), but missed this
completly!
I'm setting up outbound DKIM signing for a Postfix instance.
I'd prefer something other that OpenDKIM or Amavisd.
Other than DIY, is there a solid/stable milter for outbound signing folks are
successfully using with Postfix?
Appreciate any references!
26 matches
Mail list logo
