> On 2021 Aug 14, at 12:27, Viktor Dukhovni wrote:
>
> On Sat, Aug 14, 2021 at 11:54:12AM -0600, @lbutlr wrote:
>
>> On 10 Aug 2021, at 17:48, raf wrote:
>>> Note: I'm not recommending this. I expect that the existing default
>>> has been arrived at after much observation and careful thought
On Sat, Aug 14, 2021 at 11:54:12AM -0600, @lbutlr wrote:
> On 10 Aug 2021, at 17:48, raf wrote:
> > Note: I'm not recommending this. I expect that the existing default
> > has been arrived at after much observation and careful thought.
> > But the option to do this is there if that's what you wan
On 10 Aug 2021, at 17:48, raf wrote:
> Note: I'm not recommending this. I expect that the existing default
> has been arrived at after much observation and careful thought.
> But the option to do this is there if that's what you want.
It may be worth testing, as the setting may date from days in
Viktor Dukhovni:
> On Wed, Aug 11, 2021 at 09:48:24AM +1000, raf wrote:
>
> > If you want postfix to reject a connection immediately
> > after the first SMTP protocol error it encounters,
> > without the need to construct in advance a list of all
> > possible errors, just set smtpd_hard_error_limi
On Tue, Aug 10, 2021 at 07:54:35PM -0400, Viktor Dukhovni
wrote:
> On Wed, Aug 11, 2021 at 09:48:24AM +1000, raf wrote:
>
> > If you want postfix to reject a connection immediately
> > after the first SMTP protocol error it encounters,
> > without the need to construct in advance a list of all
On Wed, Aug 11, 2021 at 09:48:24AM +1000, raf wrote:
> If you want postfix to reject a connection immediately
> after the first SMTP protocol error it encounters,
> without the need to construct in advance a list of all
> possible errors, just set smtpd_hard_error_limit = 0.
>
> http://www.post
On 2021-08-10 16:07:48, Mono DHS wrote:
> And the right to reject non-SMTP input follows from operating an
> SMTP MTA on the well-known TCP port 25, while at the same time holding
> up the fundamental principle upon which the success of the Internet is
> based, namely of being liberal in what one
On Tue, Aug 10, 2021 at 02:45:06PM -0400, Wietse Venema
wrote:
> Wietse Venema:
> > I see. We're splitting hairs the difference between 'not implemented'
> > versus 'not recognized'. In that light, the patch looks correct to me.
>
> Implemented :-)
>
> Wietse
That'll be a relief to non-
Wietse Venema:
> I see. We're splitting hairs the difference between 'not implemented'
> versus 'not recognized'. In that light, the patch looks correct to me.
Implemented :-)
Wietse
Hello,
On 2021-08-10, at 07:39 (UTC-0700), Stephen Satchell had the following to say:
: On 8/10/21 7:00 AM, Mono DHS wrote:
: > Are there plans to revisit the SMTP command parsing and handling logic
: > in the server in one form or another? Are people making active use of
: > the smtpd_forbidde
Viktor Dukhovni:
> On Tue, Aug 10, 2021 at 10:50:56AM -0400, Wietse Venema wrote:
>
> > A reasonable person would agree that the parameter syntax of an
> > unimplemented command cannot be validated.
>
> FWIW, the pedantically standards-compliant response to an unknown
> SMTP command is in fact 50
On Tue, Aug 10, 2021 at 10:50:56AM -0400, Wietse Venema wrote:
> A reasonable person would agree that the parameter syntax of an
> unimplemented command cannot be validated.
FWIW, the pedantically standards-compliant response to an unknown
SMTP command is in fact 500, rather than 502:
ht
Mono DHS:
> First, upon receiving input consisting of the three tokens "POST",
> "/", and "HTTP/1.0", the server should have recognised that such a
> token sequence does not constitute a valid SMTP command line.
>From the server's point of view, the POST command is unimplemented.
It could have bee
On 8/10/21 7:00 AM, Mono DHS wrote:
Are there plans to revisit the SMTP command parsing and handling logic
in the server in one form or another? Are people making active use of
the smtpd_forbidden_commands parameter?
Short answer: yes
Longer answer: See this shell sequence:
# postconf s
Hello again,
On 2021-08-09, at 09:39 (UTC-0400), Wietse Venema had the following to say:
: There was a Postfix-users thread that led to this.
: https://marc.info/?t=11012289581&r=1&w=2
Uh, oh. The example conversation is noteworthy for two reasons.
First, upon receiving input consisting of
While this is true, if I write and operate an SMTP server, and someone
sends HTTP commands to it, I consider my responsibility to them to end
at sending back a "Please speak SMTP" response and closing the
connection.
Thank goodness postfix agrees and does this.
On 8/9/21 6:49 PM, post...@ptld.com wrote:
>> Oh, no, I assume that we speak SMTP when it is agreed upon to do so,
>> and nothing else
>>
>> at least systems people should be able to keep separate things
>> separate, simple and robust.
>
>
> What you don't take into account is that there are bad
Oh, no, I assume that we speak SMTP when it is agreed upon to do so,
and nothing else
at least systems people should be able to keep separate things
separate, simple and robust.
What you don't take into account is that there are bad actors who do not
follow your agreed upon standards. People
Hello,
On 2021-08-09, at 09:39 (UTC-0400), Wietse Venema had the following to say:
: > Haven't seen anything even remotely concerning HTTP in any SMTP standard.
:
: You assume that clients will adhere to the SMTP standard.
Oh, no, I assume that we speak SMTP when it is agreed upon to do so,
and
Wietse:
> Postfix 2.2 added both the GET etc. configurable forbidden word
> list and header detection (changelog says 20041124).
Mono DHS:
> Out of utter bewilderment and honest curiosity, I'd be interested
> to know how and why /non/-SMTP commands would be considered for
> the implementation of
Hello,
On 2021-08-03, at 14:11 (UTC-0400), Wietse Venema had the following to say:
: > Just wondering, did you add the anti-http stuff because of ALPACA or was it
already there?
: >
:
: Postfix 2.2 added both the GET etc. configurable forbidden word
: list and header detection (changelog says
On Tue, Aug 03, 2021 at 02:11:12PM -0400, Wietse Venema wrote:
> John Levine:
> > It appears that Wietse Venema said:
> > >Here's a nice writeup that illustrates why Postfix blocks ALPACA attacks.
> > >
> > >https://nakedsecurity.sophos.com/2021/06/11/alpaca-the-wacky-tls-security-vulnerability-wi
On 8/3/2021 12:23 PM, John Levine wrote:
It appears that Wietse Venema said:
Here's a nice writeup that illustrates why Postfix blocks ALPACA attacks.
https://nakedsecurity.sophos.com/2021/06/11/alpaca-the-wacky-tls-security-vulnerability-with-a-funky-name/
Just wondering, did you add the
John Levine:
> It appears that Wietse Venema said:
> >Here's a nice writeup that illustrates why Postfix blocks ALPACA attacks.
> >
> >https://nakedsecurity.sophos.com/2021/06/11/alpaca-the-wacky-tls-security-vulnerability-with-a-funky-name/
>
> Just wondering, did you add the anti-http stuff bec
On Tue, Aug 03, 2021 at 01:23:32PM -0400, John Levine wrote:
> >https://nakedsecurity.sophos.com/2021/06/11/alpaca-the-wacky-tls-security-vulnerability-with-a-funky-name/
>
> Just wondering, did you add the anti-http stuff because of ALPACA or was it
> already there?
Postfix is written *defensi
On Tue, Aug 03, 2021, John Levine wrote:
> Just wondering, did you add the anti-http stuff because of ALPACA or was it
> already there?
As a simple look at the source code of older releases shows
it was already there.
It appears that Wietse Venema said:
>Here's a nice writeup that illustrates why Postfix blocks ALPACA attacks.
>
>https://nakedsecurity.sophos.com/2021/06/11/alpaca-the-wacky-tls-security-vulnerability-with-a-funky-name/
Just wondering, did you add the anti-http stuff because of ALPACA or was it
Here's a nice writeup that illustrates why Postfix blocks ALPACA attacks.
https://nakedsecurity.sophos.com/2021/06/11/alpaca-the-wacky-tls-security-vulnerability-with-a-funky-name/
Wietse
28 matches
Mail list logo
