Restricting number of mails per connection

Greetings,


Unfortunately spammers are evolving and we are now seeing a number of
hijacked windows boxes, that instead of sending spam directly to
Recipients MX (We have blocked outgoing port-25 traffic due to prior
abuse cases) are now figuring out what our outgoing mailserver is and
relay their spam through our main server.

Not good.

We operate an outgoing mailserver, that can only be reached from
internal networks and will relay everything. Authenticated SMTP is
possible, but at the moment optional and this cannot be changed quickly.

I am looking for a way to quickly control sending rate of clients. The
normal client seems to send very moderate amounts of email, so a limit
should be invisible to all but a few.

I would prefer sendmail internal features over a milter.

So far I am looking at:
MaxRecipientsPerMessage
ratecontrol
concontrol

However from what I have seen it would be important to limit the amount
of separate mails being sent within one existing connection. Is this
possible?

We might also try a very brief greetpause (say 1 second).
Does anyone know whether this could cause problems with legitimate MUAs?


Thanks in advance
Sue

Re: Restricting number of mails per connection

On 04/16/08 07:34, Susan Barnes wrote:
(I'll let others more experienced with throttling answer your other
questions.)

> We might also try a very brief greetpause (say 1 second). Does anyone
> know whether this could cause problems with legitimate MUAs?

I've been running GreetPause on all my DaemonPorts for a while with out
any problem. Globally (port 25) I'm running a 3 second GreetPause and
internally (port 587) I'm running a 1 second GreetPause. I have yet to
see any problems related to this other than someone asking "Why does
take about a second longer to send emails than it did
before?". When I tell them that it is a new anti-spam technique that we
are using they hem and haw for a few moments and then realize that a
second wait is not really noticeable especially in comparison to the
little spam that they do (rather the lots that they do not) get. I've
also found that these same people don't notice the pause after about a
week. If you want, start with a very low GreetPause and slowly work it
up over the coming weeks. Give your users a chance to ease in to it.



Grant. . . .

GreetPause based on DUL status and reputation [Was: Restricting number of mails per connection]

Grant Taylor wrote:

> On 04/16/08 07:34, Susan Barnes wrote:
> (I'll let others more experienced with throttling answer your other
> questions.)
>
>> We might also try a very brief greetpause (say 1 second). Does
>> anyone know whether this could cause problems with legitimate MUAs?
>
> I've been running GreetPause on all my DaemonPorts for a while with
> out any problem. Globally (port 25) I'm running a 3 second GreetPause
> and internally (port 587) I'm running a 1 second GreetPause. I have
> yet to see any problems related to this other than someone asking "Why
> does take about a second longer to send emails than it
> did before?". When I tell them that it is a new anti-spam technique
> that we are using they hem and haw for a few moments and then realize
> that a second wait is not really noticeable especially in comparison
> to the little spam that they do (rather the lots that they do not)
> get. I've also found that these same people don't notice the pause
> after about a week. If you want, start with a very low GreetPause and
> slowly work it up over the coming weeks. Give your users a chance to
> ease in to it.

What is you opinion about using different GreetPause for
a) DUL addresses (synamic IP ranges)
b) worse reputation nets
[e.g. L2.APEWS.org lists "the worse half" of the Internet]

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Death didn't answer. He was looking at Spold in the same way as a dog looks
at a bone, only in this case things were more or less the other way around.
-- Terry Pratchett, "The Colour of Magic"

Re: GreetPause based on DUL status and reputation [Was: Restrictingnumber of mails per connection]

Andrzej Adam Filip wrote:
> What is you opinion about using different GreetPause for
> a) DUL addresses (synamic IP ranges)
> b) worse reputation nets
> [e.g. L2.APEWS.org lists "the worse half" of the Internet]
>

DO NOT USE ANY APEWS lists unless you don't want any email.

APEWS blocks more then just spammers. They also block legit mailers just
because they can and do not care.

Re: GreetPause based on DUL status and reputation [L2.APEWS.org]

Scott Grayban wrote:

> Andrzej Adam Filip wrote:
>> What is you opinion about using different GreetPause for a) DUL
>> addresses (synamic IP ranges)
>> b) worse reputation nets [e.g. L2.APEWS.org lists "the worse
>> half" of the Internet]
>>
>
> DO NOT USE ANY APEWS lists unless you don't want any email.
>
> APEWS blocks more then just spammers. They also block legit mailers
> just because they can and do not care.

Do you pay attention to "details"? [Plain english: Are you stupid?]

I do not recommend L2.APEWS.org use for "simple blocking"
("classic" DNSBL use), hardly anyone thinks it is fit for
such purpose (beyond APEWS.org maintainers). To be useful
it must be used in *other* (more complicated) ways.

*In this thread* I recommend considering using longer GreetPause delay for
"the worse half of the Internet". It is not "outright blocking".

*In other threads* I do recommend use of L2.APEWS.org for selecting
extra few checks of "classic DNSBL" lists. It is based on assumption
that for better half of the Internet the extra checks introduce
* needless delays (or risk of such delays)
* increase risk of "false positives"
but for worse half of the Internet the extra checks are truly "cost effective".
I have created FEATURE(`anfi/rsdnsbl') for the task available at
http://open-sendmail.sourceforge.net/

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Life is like a sewer. What you get out of it depends
on what you put into it.
-- Tom Lehrer

Re: GreetPause based on DUL status and reputation [Was: Restricting number of mails per connection]

On 04/16/08 10:44, Andrzej Adam Filip wrote:
> What is you opinion about using different GreetPause for
> a) DUL addresses (synamic IP ranges)
> b) worse reputation nets [e.g. L2.APEWS.org lists "the worse half"
> of the Internet]

Personally I do not do that, but I see no problem with doing that. I
think doing such would be a PITA to manage. If you want to update your
(what will be complex) GreetPause configuration go for it.

Though I doubt that you will see much ROI for your trouble. I think it
would be better to set your GreetPause low and start raising it while
watching how many times it is triggered. You decide if you want to
alter it based on location or not. Keep in mind that GreetPause is
intended to cause sending systems to wait for your server's HELO
*BEFORE* the client sends its HELO / EHLO to your server. So if there
is a GreetPause that is sufficiently long enough to catch senders that
are not pausing (or are pausing in between commands regardless of reply)
I don't think raising it much higher will catch any (vary few) more
systems that are actually waiting for a reply and following SMTP state
like they should be. In short, if the sending system is willing to wait
for your HELO, I don't think it will matter if the wait is 1 second or
30 seconds or something else as the client *IS* (most likely) following
proper SMTP state which is what GreetPause is intending to catch (those
that are not playing by the rules).



Grant. . . .

Re: GreetPause based on DUL status and reputation

Grant Taylor wrote:

> On 04/16/08 10:44, Andrzej Adam Filip wrote:
>> What is you opinion about using different GreetPause for
>> a) DUL addresses (synamic IP ranges)
>> b) worse reputation nets [e.g. L2.APEWS.org lists "the worse
>> half" of the Internet]
>
> Personally I do not do that, but I see no problem with doing that. I
> think doing such would be a PITA to manage. If you want to update
> your (what will be complex) GreetPause configuration go for it.
>
> Though I doubt that you will see much ROI for your trouble. I think
> it would be better to set your GreetPause low and start raising it
> while watching how many times it is triggered. You decide if you want
> to alter it based on location or not. Keep in mind that GreetPause is
> intended to cause sending systems to wait for your server's HELO
> *BEFORE* the client sends its HELO / EHLO to your server. So if there
> is a GreetPause that is sufficiently long enough to catch senders that
> are not pausing (or are pausing in between commands regardless of
> reply) I don't think raising it much higher will catch any (vary few)
> more systems that are actually waiting for a reply and following SMTP
> state like they should be. In short, if the sending system is willing
> to wait for your HELO, I don't think it will matter if the wait is 1
> second or 30 seconds or something else as the client *IS* (most
> likely) following proper SMTP state which is what GreetPause is
> intending to catch (those that are not playing by the rules).

Setting GreetPause involves balancing between the gain
(detecting "inpatient" sources of most likely spam)
and pain (blocking *some* legitimate sources).
Some people recommended even using *very long* GreetPause delays,
IMHO *TOO* long to make them fit for "good reputation nets.

I merely suggest that it may be worthwhile to evaluate the best
"balance point" separately for the better and the worse halves of
the Internet.

--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
The 11 is for people with the pride of a 10 and the pocketbook of an 8.
-- R. B. Greenberg [referring to PDPs?]

Re: GreetPause based on DUL status and reputation

On 04/16/08 12:26, Andrzej Adam Filip wrote:
> I merely suggest that it may be worthwhile to evaluate the best
> "balance point" separately for the better and the worse halves of the
> Internet.

*nod*

I would be interested in seeing the differences between the ""good and
""bad portions of the internet. However I'm betting that you would
hardly need a GreetPause at all for the ""god portion of the internet.



Grant. . . .

Re: GreetPause based on DUL status and reputation and p0f

Grant Taylor wrote:

> On 04/16/08 12:26, Andrzej Adam Filip wrote:
>> I merely suggest that it may be worthwhile to evaluate the best
>> "balance point" separately for the better and the worse halves of
>> the Internet.
>
> *nod*
>
> I would be interested in seeing the differences between the ""good and
> ""bad portions of the internet. However I'm betting that you would
> hardly need a GreetPause at all for the ""god portion of the internet.

There are DUL ranges in the "good half".
There are MS "operating systems" connected directly :-)

The best combination may use:
* DUL info (yes/no from PBL.spamhaus.org or sorbs.net)
* passive OS fingerprinting info provided by p0f
* reputation info from L2.APEWS.org or DNSWL.org (white list)

URL(s):
* p0f : http://lcamtuf.coredump.cx/p0f.shtml

--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
On a clear disk you can seek forever.
-- P. Denning

Re: GreetPause based on DUL status and reputation

Post removed (X-No-Archive: yes)

Re: Restricting number of mails per connection

Grant Taylor wrote:
> internally (port 587) I'm running a 1 second GreetPause. I have yet to

Greetpause on the submission Port? Sorry, but I fail to see any good
reason for that, as you are only accepting authenticated SMTP there.
Don't you?

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: Restricting number of mails per connection

On Apr 17, 6:28 am, Clemens Zauner wrote:
> Grant Taylor wrote:
> > internally (port 587) I'm running a 1 second GreetPause. I have yet to
>
> Greetpause on the submission Port? Sorry, but I fail to see any good
> reason for that, as you are only accepting authenticated SMTP there.
> Don't you?
>
> cu
> Clemens.


Even if Grant is accepting only authenticated mail on his MSA port,
what is to prevent spam submission by an "owned" machine? The spam
software will have no great trouble obtaining the password, if one is
required. AFAIK most ISPs "authenticate" only by sender IP address. By
the same token it will have no trouble waiting for the greet pause.
However, maybe this week it doesn't yet have that ability, and a
temporary reduction in spam throughput can be achieved. That is not a
bad thing, and if few ISPs follow this route the spam software might
never be updated to have these new abilities. It is easy to test.

There is a long run logic behind setting quantity limits on outbound
authenticated mail, however. It may allow the ISP to discover and
correct problems before massive amounts of spam are sent. I am not
sure what form the correction might take, given the reluctance of ISPs
to get involved in virus removal from customer systems. Perhaps they
could just remove the ability to send email through the MTA and let
the user obtain a webmail account for email if the ISP doesn't want to
do anything more.

Daniel Feenberg

Re: Restricting number of mails per connection

Clemens Zauner wrote on 17-4-2008 12:28:
> Grant Taylor wrote:
>> internally (port 587) I'm running a 1 second GreetPause. I have yet to
>
> Greetpause on the submission Port? Sorry, but I fail to see any good
> reason for that, as you are only accepting authenticated SMTP there.
> Don't you?

There already have been people mentioning spammers phishing for e-mail
credentials. At first only for webmail, but lately also for
authenticated SMTP sessions.

Peter

Re: Restricting number of mails per connection

Grant Taylor wrote:
> On 04/16/08 07:34, Susan Barnes wrote:
> (I'll let others more experienced with throttling answer your other
> questions.)
>
>> We might also try a very brief greetpause (say 1 second). Does anyone
>> know whether this could cause problems with legitimate MUAs?
>
> I've been running GreetPause on all my DaemonPorts for a while with out
> any problem. Globally (port 25) I'm running a 3 second GreetPause and
> internally (port 587) I'm running a 1 second GreetPause. I have yet to
> see any problems related to this other than someone asking "Why does
> take about a second longer to send emails than it did
> before?". When I tell them that it is a new anti-spam technique that we
> are using they hem and haw for a few moments and then realize that a
> second wait is not really noticeable especially in comparison to the
> little spam that they do (rather the lots that they do not) get. I've
> also found that these same people don't notice the pause after about a
> week. If you want, start with a very low GreetPause and slowly work it
> up over the coming weeks. Give your users a chance to ease in to it.

Hi Grant,


Thanks for the information. I would think, that even a very brief
greetpause would do the trick, unless the spambot does actually speak
SMTP, in which case it is useless anyway...

I was just worried about normal MUAs getting into trouble.


Regards
Sue

Re: Restricting number of mails per connection

On 04/18/08 08:31, Susan Barnes wrote:
> Thanks for the information. I would think, that even a very brief
> greetpause would do the trick, unless the spambot does actually speak
> SMTP, in which case it is useless anyway...

You are welcome.

Indeed, GreetPause will only catch senders that do not follow SMTP state
correctly.

> I was just worried about normal MUAs getting into trouble.

I think you can be fairly safe in the fact that MUAs will follow the
SMTP state a *LOT* better than spam bots. Now, if you are using
something crazy like 90 (or more) seconds, things will start timing out
on you.



Grant. . . .