Mailing List Archive

Thus said "John Levine" on 27 Aug 2022 18:03:10 -0400:

> >As far as what would happen if all SMTP did that? It would likely
> >have minimal impact on legitimate senders.
>
> Adding an extra 90 seconds per connection?

I did not suggest that at all, and quite frankly, neither did the study.
90 seconds was merely the value used to perform the experiment, it is
not a final value. It was set high at 90 seconds so that the behaviors
of different MTAs could be observed. Of course, since you read the
study, you should already know that 90 seconds was not suggested as a
general rule.

When George asked the question about "what would happen if all
SMTP imposed greeting delay", no specific timeout value had been in
discussion. I offered a link to the "study" to show that some greeting
delay is actually quite effective in blocking spam.

> A greet pause of 10 seconds would be as effective as 90 seconds, and
> there is no point to doing it on any IP that has waited on previous
> connections.

I think you're observation is proper. Again, nobody suggested 90 seconds
was a "good" value for a greeting delay.

I assume that you didn't read the entire study or you would have read
this:

"A possible improvement would be to record those hosts that pass
the 'wait test' and allow them to connect without delay in the
future."

And:

"This host now implements a one second 220 delay for all hosts,
and rejects transfer attempts from any that send data in that
period."

I think 1 second isn't enough and some values between 10--30 are best.

Andy

Thus said Michael Sierchio on Sat, 27 Aug 2022 18:15:43 -0400:

> Your second point requires maintaining a list of (presumed) legitimate
> SMTP sources after you've conversed. That's likely to be burdensome,
> and addresses shouldn't be considered permanent.

Maintaining a list of those that pass the "greeting" test is a simple
task for any administrator worth his salt. It could be easily automated.
However, I also don't think it's worth it. No human is going to notice a
10 second delay in SMTP delivery.

Andy

After an admittedly small-scale empirical testing period, I landed on 15
seconds as my GREETDELAY value. 10 seconds was also effective.

- David Bell
===========================
A good traveler has no fixed plans and is not intent on arriving.
O bom viajante não tem planos fixos e não se concentra apenas em chegar.
— Lao Tzu


On Sat, Aug 27, 2022 at 3:31 PM Andy Bradford <
amb-sendok-1664231110.labemeahfbdkaimkiicf@bradfords.org> wrote:

> Thus said "John Levine" on 27 Aug 2022 18:03:10 -0400:
>
> > >As far as what would happen if all SMTP did that? It would likely
> > >have minimal impact on legitimate senders.
> >
> > Adding an extra 90 seconds per connection?
>
> I did not suggest that at all, and quite frankly, neither did the study.
> 90 seconds was merely the value used to perform the experiment, it is
> not a final value. It was set high at 90 seconds so that the behaviors
> of different MTAs could be observed. Of course, since you read the
> study, you should already know that 90 seconds was not suggested as a
> general rule.
>
> When George asked the question about "what would happen if all
> SMTP imposed greeting delay", no specific timeout value had been in
> discussion. I offered a link to the "study" to show that some greeting
> delay is actually quite effective in blocking spam.
>
> > A greet pause of 10 seconds would be as effective as 90 seconds, and
> > there is no point to doing it on any IP that has waited on previous
> > connections.
>
> I think you're observation is proper. Again, nobody suggested 90 seconds
> was a "good" value for a greeting delay.
>
> I assume that you didn't read the entire study or you would have read
> this:
>
> "A possible improvement would be to record those hosts that pass
> the 'wait test' and allow them to connect without delay in the
> future."
>
> And:
>
> "This host now implements a one second 220 delay for all hosts,
> and rejects transfer attempts from any that send data in that
> period."
>
> I think 1 second isn't enough and some values between 10--30 are best.
>
> Andy
>
>

On Sat, 27 Aug 2022, Michael Sierchio wrote:
> Your second point requires maintaining a list of (presumed) legitimate SMTP
> sources after you've conversed. That's likely to be burdensome, and
> addresses shouldn't be considered permanent.

My greylist daemon remembers addreses and it's no big deal. It forgets
IPs that have sent no mail for 90 days to keep the table from getting too
large. It currently has about 4000 entries.

Keep in mind that you don't have to remember addresses perfectly or across
every MTA you operate. If each MTA keeps its own list that's good enough
since it in practice most of the legit mail you get comes from hosts that
have sent you mail before.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

It appears that Andy Bradford <amb-sendok-1664231262.jcakmepobneebgoinnkd@bradfords.org> said:
>Maintaining a list of those that pass the "greeting" test is a simple
>task for any administrator worth his salt. It could be easily automated.
>However, I also don't think it's worth it. No human is going to notice a
>10 second delay in SMTP delivery.

You're right about the humans and the per-message delay, but if a
typical delivery takes about 10 seconds, you're cutting the rate at
which you accept mail in half when you're near your concurrency limit.
That's something humans are likely to notice. You could increase the
limit but then you're making it easier to get yourself DoS'ed by a
bunch of giant messages.

R's,
John

Hi,

(sorry to be late in the threat; hardisk failure).

I've implemented both

- greylisting (working with Schweikert's Postfix Greylisting daemon) in
qmail-smtpd and
- Greetdelay as feature of rblsmtpd

in my packages (s/qmail, ucspi-tcp6).

On the bottom line, they work both effectively. However, Greetdelay is
stateless and does not require a database to consider. With some useful
settings in the tcpd.smtp cdb's you have the advantage that mails are
NOT delayed except for the given Greetdelay period. 
Here 60s seems to be a good bargain to exclude botnet devices.

Regards.
--eh.



Am Samstag, dem 27.08.2022 um 15:42 -0700 schrieb David I. Bell:
> After an admittedly small-scale empirical testing period, I landed on
> 15 seconds as my GREETDELAY value. 10 seconds was also effective.
>
> - David Bell
> ===========================
> A good traveler has no fixed plans and is not intent on arriving.
> O bom viajante não tem planos fixos e não se concentra apenas em
> chegar.
> — Lao Tzu
>
>
> On Sat, Aug 27, 2022 at 3:31 PM Andy Bradford
> <amb-sendok-1664231110.labemeahfbdkaimkiicf@bradfords.org> wrote:
> > Thus said "John Levine" on 27 Aug 2022 18:03:10 -0400:
> >
> > > > As far  as what would  happen if all SMTP  did that? It  would
> > > > likely
> > > > have minimal impact on legitimate senders.
> > >
> > > Adding an extra 90 seconds per connection?
> >
> > I did not suggest that at all, and quite frankly, neither did the
> > study.
> > 90 seconds  was merely the value  used to perform the  experiment,
> > it is
> > not a final value.  It was set high at 90 seconds  so that the
> > behaviors
> > of  different MTAs  could be  observed. Of  course, since  you
> > read  the
> > study, you  should already know that  90 seconds was not  suggested
> > as a
> > general rule.
> >
> > When  George  asked  the  question  about  "what  would  happen 
> > if  all
> > SMTP  imposed greeting  delay", no  specific timeout  value had 
> > been in
> > discussion. I offered  a link to the "study" to  show that some
> > greeting
> > delay is actually quite effective in blocking spam.
> >
> > > A greet pause of  10 seconds would be as effective  as 90
> > > seconds, and
> > > there is no  point to doing it  on any IP that has  waited on
> > > previous
> > > connections.
> >
> > I think you're observation is proper. Again, nobody suggested 90
> > seconds
> > was a "good" value for a greeting delay.
> >
> > I assume that  you didn't read the  entire study or you  would have
> > read
> > this:
> >
> >     "A possible improvement would be to record those hosts that
> > pass
> >     the 'wait test'  and allow them to connect without  delay in
> > the
> >     future."
> >
> > And:
> >
> >     "This host now implements a one  second 220 delay for all
> > hosts,
> >     and rejects  transfer attempts from  any that send data  in
> > that
> >     period."
> >
> > I think 1 second isn't enough and some values between 10--30 are
> > best.
> >
> > Andy
> >

--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E

Thus said Erwin Hoffmann on Fri, 09 Sep 2022 00:20:34 +0200:

> On the bottom line, they work both effectively. However, Greetdelay is
> stateless and does not require a database to consider.

This is precisely why I continue to use greetdelay. It's overhead is
miniscule, it's benefits are decent, so while it doesn't block as much
as I would like, the fact that it is 99% hands free makes it an
attractive mechanism for me.

As for greylisting, at one point I used it heavily, but lately I haven't
actually needed it (probably due to manually maintained RBLs), and in
the cases where I do need it, I offload it to OpenBSD's spamd(8) to keep
qmail's sources smaller.

http://man.openbsd.org/spamd

Andy

On Fri, 9 Sep 2022, Erwin Hoffmann wrote:
> - greylisting (working with Schweikert's Postfix Greylisting daemon) in
> qmail-smtpd and
> - Greetdelay as feature of rblsmtpd
>
> in my packages (s/qmail, ucspi-tcp6).
>
> On the bottom line, they work both effectively. However, Greetdelay is
> stateless and does not require a database to consider. With some useful
> settings in the tcpd.smtp cdb's you have the advantage that mails are
> NOT delayed except for the given Greetdelay period.
?? Here 60s seems to be a good bargain to exclude botnet devices.

As I said a few messages ago, if you do a greet delay on every connection,
rather than only on unknown hosts, you will vastly decrease the throughput
of your mail server. Every delivery that used to take 3 seconds now takes
63 seconds. On tiny servers I suppose that is OK, but if you have a
significant amount of traffic, that would be bad news.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

FWIW I’ve been using a combination of “greetdelay” and greylisting for years … every connection has a ten-second greetdelay, and … I *think* my greylist timer is on the order of five minutes, I haven’t really had to think about it much for the past few years.

At one point I was toying with the idea of tying the two together, so that “known” IPs don’t have to deal with a greetdelay at all, but $DAYJOB keeps me pretty busy so I haven’t had time to think about it in detail.

Sent from my iPad

> On Sep 8, 2022, at 22:35, Andy Bradford <amb-sendok-1665282367.haoagkmocnilgmnmfici@bradfords.org> wrote:
>
> ?Thus said Erwin Hoffmann on Fri, 09 Sep 2022 00:20:34 +0200:
>
>> On the bottom line, they work both effectively. However, Greetdelay is
>> stateless and does not require a database to consider.
>
> This is precisely why I continue to use greetdelay. It's overhead is
> miniscule, it's benefits are decent, so while it doesn't block as much
> as I would like, the fact that it is 99% hands free makes it an
> attractive mechanism for me.
>
> As for greylisting, at one point I used it heavily, but lately I haven't
> actually needed it (probably due to manually maintained RBLs), and in
> the cases where I do need it, I offload it to OpenBSD's spamd(8) to keep
> qmail's sources smaller.
>
> http://man.openbsd.org/spamd
>
> Andy
>