https://github.com/smtpd/qpsmtpd/pull/18
Matt
On Jun 1, 2012, at 8:34 PM, Ask Bjørn Hansen wrote:
> On Jun 1, 2012, at 20:25, Matt Simerson wrote:
>
>> Which is preferred within a plugin?
>>
>> $self->qp->connection->notes
>>
>> or
>>
>> $self->connection->notes
>
> Assuming the second m
On Jun 1, 2012, at 20:25, Matt Simerson wrote:
> Which is preferred within a plugin?
>
> $self->qp->connection->notes
>
> or
>
> $self->connection->notes
Assuming the second method is just a proxy for the first, then use the shorter
version.
Ask
On 26-May-08, at 5:24 PM, John Peacock wrote:
Those are *connection* attributes, not *transaction* attributes.
If a plugin is storing them in the transaction object, that is a
mistake. We can and probably should maintain the connection notes
from before the TLS reset, but I maintain that
Matt Sergeant wrote:
OK, I'm fine with that.
Hopefully to put this thread to rest, I committed my one line change to preserve
the connection notes. If anyone's favorite core plugin stashes
connection-related stuff (like dnsbl) in the transaction notes, let's start
individual threads (with p
Chris Lewis wrote:
SMTP state and qpsmtpd/filtering state are not the same thing. The RFCs
talk about destroying SMTP state. It already does that without having
to destroy any notes() AFAICT. But it shouldn't blithely throwing away
qpsmtpd/filtering state - it's none of the RFC's business.
John Peacock wrote:
On a more pragmatic note: do we have any evidence whatsoever that
spammers are using TLS at all? This may be a completely theoretical
exercise, since AFAIK, all standard MTA's will switch to TLS as soon as
the received the EHLO prompt, in which case there is no transaction
Matt Sergeant wrote:
On 22-May-08, at 10:45 PM, John Peacock wrote:
STARTTLS is not required to happen immediately after EHLO (not HELO,
which doesn't support ESMTP extensions). And yes, you must completely
discard every portion of the SMTP state that has occurred up to that
point (just like
Matt Sergeant wrote:
I don't think we should care so much about the RFCs. If there are bits
in connection notes that might help determining if this is spam (or some
other thing we're trying to detect) before STARTTLS we need to allow
qpsmtpd to keep that information.
I'm talking about keeping
On 22-May-08, at 10:45 PM, John Peacock wrote:
STARTTLS is not required to happen immediately after EHLO (not
HELO, which doesn't support ESMTP extensions). And yes, you must
completely discard every portion of the SMTP state that has
occurred up to that point (just like with RSET).
The
On Thu, 22 May 2008, Chris Babcock wrote:
Chris Lewis wrote:
...
Killing transaction/connection notes() is a bit of a kludge, because
there's lots of other plugins who may be relying on the data being
persistent.
Without killing connection notes, I don't see any sane way to determine what
On 22 May 2008 10:34:46 -0700
"Chris Babcock" <[EMAIL PROTECTED]> wrote:
> Chris Lewis wrote:
> Without killing connection notes, I don't see any sane way to determine
> what notes were generated before vs after TLS was enabled.
> Unfortunately, for some plugins that determination may be critica
On Thu, 22 May 2008 22:45:20 -0400
John Peacock <[EMAIL PROTECTED]> wrote:
> The argument can be made that only the *transaction* should be reset, and the
> connection notes can be kept around. I specifically chose to tie
> Connection::start and Connection::clone together with the minimal list o
Chris Lewis wrote:
John Peacock says:
It's a required part of the RFC, see RFC-2487 Section 5.2:
Upon completion of the TLS handshake, ... [t]he server MUST discard any
knowledge obtained from the client...
Do you even have to purge envelope addresses per-se? It doesn't say it,
but doesn'
Chris Lewis wrote:
Charlie Brady wrote:
On Wed, 21 May 2008, Hanno Hecker wrote:
On Wed, 21 May 2008 10:39:37 -0400 (EDT)
Charlie Brady <[EMAIL PROTECTED]> wrote:
On Wed, 21 May 2008, Hanno Hecker wrote:
- if you use the tls plugin, all connection notes are lost after the
TLS setup is comp
Charlie Brady wrote:
On Wed, 21 May 2008, Hanno Hecker wrote:
On Wed, 21 May 2008 10:39:37 -0400 (EDT)
Charlie Brady <[EMAIL PROTECTED]> wrote:
On Wed, 21 May 2008, Hanno Hecker wrote:
- if you use the tls plugin, all connection notes are lost after the
TLS setup is complete
Why? Isn't th
On Wed, 21 May 2008, Hanno Hecker wrote:
On Wed, 21 May 2008 10:39:37 -0400 (EDT)
Charlie Brady <[EMAIL PROTECTED]> wrote:
On Wed, 21 May 2008, Hanno Hecker wrote:
- if you use the tls plugin, all connection notes are lost after the
TLS setup is complete
Why? Isn't that a bug in the tls pl
On Wed, 21 May 2008, Hanno Hecker wrote:
On Wed, 21 May 2008 10:39:37 -0400 (EDT)
Charlie Brady <[EMAIL PROTECTED]> wrote:
On Wed, 21 May 2008, Hanno Hecker wrote:
- if you use the tls plugin, all connection notes are lost after the
TLS setup is complete
Why? Isn't that a bug in the tls pl
On 9-Aug-06, at 12:47 PM, Michael Holzt wrote:
I consider TLS beeing implemented by unrecognized_command unclean
anyway.
Ironically I consider the way AUTH was implemented to be unclean.
It's all a matter of perspective.
Oh, i'm sure we can agree that both ways are not too clean. I think
the
> >I consider TLS beeing implemented by unrecognized_command unclean
> >anyway.
> Ironically I consider the way AUTH was implemented to be unclean.
> It's all a matter of perspective.
Oh, i'm sure we can agree that both ways are not too clean. I think
the new proposal for registering extension
On 9-Aug-06, at 7:17 AM, Michael Holzt wrote:
I consider TLS beeing implemented by unrecognized_command unclean
anyway.
Ironically I consider the way AUTH was implemented to be unclean.
It's all a matter of perspective.
Michael Holzt wrote:
But if the switch to TLS has basically the same effect as opening a new
connection, we should probably run the connect-hook again at that time.
Or we could have an additional 'connect_tls' (or 'connect_restart'?)
hook (which could also be used on port 465 for the deprecated
> No, the connect hook has already fired by the time that the TLS connection is
> established.
But if the switch to TLS has basically the same effect as opening a new
connection, we should probably run the connect-hook again at that time.
Or we could have an additional 'connect_tls' (or 'connect_
On Tue, 8 Aug 2006, John Peacock wrote:
> [EMAIL PROTECTED] wrote:
> > Can anyone please suggest a simple way to pass a note from the
> > connection plugin to everything after TLS?
>
> You can't. What information are you trying to pass? Can you redo whatever
> analysis you performed before,
[EMAIL PROTECTED] wrote:
> I think that sounds appropriate, as TLS essentially starts a new
> connection.
It's a required part of the RFC, see RFC-2487 Section 5.2:
> Upon completion of the TLS handshake, ... [t]he server MUST discard any
> knowledge obtained from the client...
> Ca
24 matches
Mail list logo
