smtpd_recipient_limit and the corresponding error pop up on secure smtp

[francis picabia]

Hi,

The number of phishing or otherwise compromised accounts is needing
an automation to manage it.  Last night the spammers waited until
the evening and simultaneously used 3 compromised accounts to send
spam over secure smtp.  A nagios alert on number of messages
in the queue was our only alarm, and in only a couple of hours
the reputation of the server and domain is damaged for awhile (both in and out).

I added smtpd_recipient_limit=20 to the options for secured SMTP.
The error it produced when tested (with Thunderbird) is confusing:

The size of the message you are trying to send exceeds a temporary size
limit of the server.  The message was not sent; try to reduce the message size
or wait some time and try again.  The server responded: 4.5.3 Error: too many recipients.

If the user patiently reads to the end, the last statement is the only thing they
need to know.  However, the previous statements are wrong and misleading.
How can this error be made better?

[k...@rice.edu]

Hi Francis,

The error from postfix is very clear: 4.5.3 Error: too many recipients.

The remaining exposition is from Thunderbird so you may want to take
this question up with their developers.

Cheers,
Ken

[Reindl Harald]

Am 27.02.2013 15:11, schrieb francis picabia:
> The size of the message you are trying to send exceeds a temporary size
> limit of the server. The message was not sent; try to reduce the message size
> or wait some time and try again. The server responded: 4.5.3 Error: too many recipients.
>
> If the user patiently reads to the end, the last statement is the only thing they
> need to know. However, the previous statements are wrong and misleading.
> How can this error be made better?

and the last statement is the only ony which comes from
postfix as "the server responded:" indicates, so you
can only patch the mail client or live with it

[Viktor Dukhovni]

On Wed, Feb 27, 2013 at 10:11:08AM -0400, francis picabia wrote:

> The number of phishing or otherwise compromised accounts is needing
> an automation to manage it. Last night the spammers waited until
> the evening and simultaneously used 3 compromised accounts to send
> spam over secure smtp. A nagios alert on number of messages
> in the queue was our only alarm, and in only a couple of hours
> the reputation of the server and domain is damaged for awhile (both in and
> out).

You need to deploy a policy service that rate limits the total
number of recipients a customer account can reach in any suitable
time interval.

> I added smtpd_recipient_limit=20 to the options for secured SMTP.
> The error it produced when tested (with Thunderbird) is confusing:

RFC 5321 requires support for at least 100 recipients per message.

https://tools.ietf.org/html/rfc5321#section-4.5.3.1.10

If at all possible allow a single mailing at least that large in
by setting the time interval long enough that it is reasonable to
let users send mail to at least 100 recipients in that time.

> The size of the message you are trying to send exceeds a temporary size
> limit of the server. The message was not sent; try to reduce the message
> size or wait some time and try again. The server responded:
> 4.5.3 Error: too many recipients.

Actually the Postfix error response is:

452 4.5.3 Error: too many recipients

while the "452" SMTP response is potentially ambiguous, and can mean
message temporary lack of storage, the "4.5.3" is unambiguous:

https://tools.ietf.org/html/rfc3463#section-3.6

X.5.3 Too many recipients

More recipients were specified for the message than could have
been delivered by the protocol. This error should normally
result in the segmentation of the message into two, the
remainder of the recipients to be delivered on a subsequent
delivery attempt. It is included in this list in the event
that such segmentation is not possible.

> If the user patiently reads to the end, the last statement is the only
> thing they need to know. However, the previous statements are wrong and
> misleading. How can this error be made better?

The mail user-agent needs to implement RFC 3463, and only fall back
on RFC 5321 when the server does not support ENHANCEDSTATUSCODES.

https://tools.ietf.org/html/rfc2034#section-3
https://tools.ietf.org/html/rfc2034#section-6

--
Viktor.

[francis picabia]

On Wed, Feb 27, 2013 at 10:11 AM, francis picabia <fpic...@gmail.com> wrote:

Hi,

The number of phishing or otherwise compromised accounts is needing
an automation to manage it.  Last night the spammers waited until
the evening and simultaneously used 3 compromised accounts to send
spam over secure smtp.  A nagios alert on number of messages
in the queue was our only alarm, and in only a couple of hours
the reputation of the server and domain is damaged for awhile (both in and out).

I added smtpd_recipient_limit=20 to the options for secured SMTP.
The error it produced when tested (with Thunderbird) is confusing:

The size of the message you are trying to send exceeds a temporary size
limit of the server.  The message was not sent; try to reduce the message size
or wait some time and try again.  The server responded: 4.5.3 Error: too many recipients.

If the user patiently reads to the end, the last statement is the only thing they
need to know.  However, the previous statements are wrong and misleading.
How can this error be made better?

Thanks for the answers everyone.  Crystal clear the vagueness is all Thunderbird's.

I had a set of cascading iptables rules to rate limit new connections,
but they circumvented this as well.  Based on the IP, there were 5 connections
per minute and 15 connections per 5 minutes.  If those were exceeded, iptables
would block that IP for 20 minutes.

Here is what they did:

Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of
compromised credentials.

I looked at one IP, and it connected 59 times over 2 hours, sending one recipient per email.

If that is indicative, then 59 * 390 = 23128 email.

It looks like we need something which limits based on the authenticating sender
connection counts, not IP or recipient count.

[Reindl Harald]

Am 27.02.2013 21:45, schrieb francis picabia:
> I had a set of cascading iptables rules to rate limit new connections,
> but they circumvented this as well. Based on the IP, there were 5 connections
> per minute and 15 connections per 5 minutes. If those were exceeded, iptables
> would block that IP for 20 minutes.

this is bullshit

if you where my mail-admin i would call you something
not friendly - 15 connections and so 15 messages per
5 minutes

thank you if i check my mails in the morning and
reply to at least 50 of them due my first coffee

things like the follwoing are working much better
because a average over 30 minutes allows natural
peaks
anvil_rate_time_unit = 1800s
smtpd_client_connection_rate_limit = 80

> Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of
> compromised credentials.
>
> I looked at one IP, and it connected 59 times over 2 hours, sending one recipient per email.
>
> If that is indicative, then 59 * 390 = 23128 email.
>
> It looks like we need something which limits based on the authenticating sender
> connection counts, not IP or recipient count

or get rid of users which are compromised

[Noel Jones]

On 2/27/2013 2:45 PM, francis picabia wrote:

> Over 390 unique IPs simultaneously sent email at a gradual rate
> using 3 sets of
> compromised credentials.

Use postfwd or similar policy service to rate-limit the total
recipients per account over some period of time.

http://www.postfix.org/SMTPD_POLICY_README.html
http://www.postfix.org/addon.html#policy
http://postfwd.org/



-- Noel Jones

[francis picabia]

On Wed, Feb 27, 2013 at 4:52 PM, Reindl Harald <h.re...@thelounge.net> wrote:

Am 27.02.2013 21:45, schrieb francis picabia:

> I had a set of cascading iptables rules to rate limit new connections,
> but they circumvented this as well.  Based on the IP, there were 5 connections
> per minute and 15 connections per 5 minutes.  If those were exceeded, iptables
> would block that IP for 20 minutes.

this is bullshit

Thanks for the technical expose.
 

if you where my mail-admin i would call you something
not friendly - 15 connections and so 15 messages per
5 minutes

The fact is, those rules have been in place for over
a year without any grief for the users (and they would
complain quite liberally).  This only impacts roaming
users, and the count on new connections.   You don't
have enough information to understand our set up, nor do you
have a right to complain!

thank you if i check my mails in the morning and
reply to at least 50 of them due my first coffee

things like the follwoing are working much better
because a average over 30 minutes allows natural
peaks
anvil_rate_time_unit = 1800s
smtpd_client_connection_rate_limit = 80

This would have done nothing to address the situation I explained.
Each IP connects about once every 2 minutes.

> Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of
> compromised credentials.
>

> I looked at one IP, and it connected 59 times over 2 hours, sending one recipient per email.
>
> If that is indicative, then 59 * 390 = 23128 email.
>
> It looks like we need something which limits based on the authenticating sender
> connection counts, not IP or recipient count

or get rid of users which are compromised

You are funny.  They pay the bills.

[francis picabia]

On Wed, Feb 27, 2013 at 5:22 PM, Noel Jones <njo...@megan.vbhcs.org> wrote:

On 2/27/2013 2:45 PM, francis picabia wrote:

> Over 390 unique IPs simultaneously sent email at a gradual rate
> using 3 sets of
> compromised credentials.

Use postfwd or similar policy service to rate-limit the total
recipients per account over some period of time.

http://www.postfix.org/SMTPD_POLICY_README.html
http://www.postfix.org/addon.html#policy
http://postfwd.org/

Thanks for the pointer.  Another swiss army knife to learn about.
I'll take a look.