Chris Babcock wrote on 22.05.2008 19:36:
Does anybody here have any code they use to remove stale (expired)
entries from the greylist dbm file?
You might have to use a cronjob.
Please have a look at my db/suite.
Although on http://dienstleistung-kultur.de/qpsmtpd/db_greylist.shtml it
reads:
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-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
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
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
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
