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.
