On Friday, October 12, 2018 06:02:40 PM pg...@dev-mail.net wrote:
> > 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
> >
On 12 Oct 2018, at 21:02, pg...@dev-mail.net wrote:
Same question remains, and I suspect with a similar answer, re: TLSv1.
There's no reason for negotiating a TLSv1.0 session with a partner
capable of doing better other than being lazy, cheap, and/or generally
careless.
There are much
On 13/10/18 14:02, pg...@dev-mail.net wrote:
> I may have been unlcear -- it's my server receiving emails from the
> errant FinCo, dkim-signed with sha1 sigs. So up to me to determine
> if they are 'putting clients at risk' by being lazy about their
> security, and blocking their messages.
You're
> 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
On October 13, 2018 12:06:03 AM UTC, pg...@dev-mail.net wrote:
>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',
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
K F:
> Hi Wietse
>
> 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.
> Setting up 10
Hi Wietse
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.
Setting up 10 nginx just for
Yes, that's it. Thank you!
Am Fr., 12. Okt. 2018 um 14:27 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:
> That's the probe's 421 result:
>
> > Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412:
> to=,
> > relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0,
> >
K F:
> Is it by using debug? How do I set it best to get the smtp statements
> and their responses?
This is not part of routine logging, because it would allow an
adversary to fill your file system with garbage.
Postfix debug logging is for debugging and produces even more output.
That's a way
That's the probe's 421 result:
> Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412: to=,
> relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0,
> status=undeliverable (host 127.0.0.1[127.0.0.1] refused to talk to me: 421
> internal error: OpenResolveAddrFolder failed)
>
On 12.10.18 07:18, Stefan Bauer wrote:
But what was postfix reporting to the Appliance that tried to deliver to
postfix?
search for "smtpd" lines in logs.
According to your "unverified_recipient_reject_code = 550", it could be 550.
The 421 is what postfix got from the groupware. Not what it
Is it by using debug? How do I set it best to get the smtp statements and their
responses?
14 matches
Mail list logo