MTA closing connection after 552 response

What is considered the proper thing for an MTA to do when a client
sends more than an allowed amount of content in the DATA portion of an
SMTP dialogue?

Assuming the ESMTP SIZE option is being used, then the client has
already been informed of the maximum allowable size, so if the client
exceeds the size, the MTA should have the right to assume the client is
either broken or malicious. Either way, it would be fair for the MTA to
close the connection. However, according to section 3.9 of RFC 2821:
=======================================
An SMTP server MUST NOT intentionally close the connection except:

- After receiving a QUIT command and responding with a 221 reply.

- After detecting the need to shut down the SMTP service and
returning a 421 response code. This response code can be issued
after the server receives any command or, if necessary,
asynchronously from command receipt (on the assumption that the
client will receive it after the next command is issued).
=======================================

So, if an MTA knows that a client has "broken the rules" and sent more
than it was allowed to send what safe thing can it do? If it continues
reading, looking for a QUIT or RSET, what if the client sends multiple
terabytes of data? This sounds like a denial of service attack that the
MTA MUST deal with...

Thanks,
-Eric

Re: MTA closing connection after 552 response

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-24783-1154559096-0005
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

eric.havens@gmail.com writes:

> So, if an MTA knows that a client has "broken the rules" and sent more
> than it was allowed to send what safe thing can it do? If it continues
> reading, looking for a QUIT or RSET, what if the client sends multiple
> terabytes of data? This sounds like a denial of service attack that the
> MTA MUST deal with...

The MTA can deal with it in any meaningful way. There is no mandate to take
any specific action. The MTA can certainly drop the connection, or just
keep reading until it gets to the end of the message. The MTA does not have
to save the message, just keep reading it until it gets the terminating dot,
then return an 5xx error.



--=_mimegpg-commodore.email-scan.com-24783-1154559096-0005
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQBE0Sx4x9p3GYHlUOIRAl1RAJwK/iADiB4OxDtvDynZQ3uuZgp7zwCg gA50
GWtz39xJ7OCqykRgfIKCv00=
=I/Vp
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-24783-1154559096-0005--

Re: MTA closing connection after 552 response

On 08/02/06 17:51, Sam wrote:
> The MTA can deal with it in any meaningful way. There is no mandate to
> take any specific action. The MTA can certainly drop the connection, or
> just keep reading until it gets to the end of the message. The MTA does
> not have to save the message, just keep reading it until it gets the
> terminating dot, then return an 5xx error.

I would think that the MTA should keep reading the message and let
something else deal with the security of this issue. I would be tempted to
set up something in the firewall that would intelligently interrupt the
stream. Namely have the firewall issue a RST FIN to the sending party.
Then have the firewall reconstruct a new stream to end out the packet.
I.e. have the firewall not send any more of the broken stream, but rather
end the message at that point and issue a RSET. The MTA should issue a 5xx
series error, if not a 57x error for policy reasons and disregard the message.



Grant. . . .

Re: MTA closing connection after 552 response

eric.havens@gmail.com writes:

> What is considered the proper thing for an MTA to do when a client
> sends more than an allowed amount of content in the DATA portion of an
> SMTP dialogue?
>
> Assuming the ESMTP SIZE option is being used, then the client has
> already been informed of the maximum allowable size, so if the client
> exceeds the size, the MTA should have the right to assume the client is
> either broken or malicious. Either way, it would be fair for the MTA to
> close the connection. However, according to section 3.9 of RFC 2821:

If client uses SIZE -option on MAIL FROM, that announced size of message is
not always exact.

Servers announce of maximum size on EHLO response is one way. There is
no negotation. This just informs that which messages server will reject
saving work from client. Although work on this case is just
MAIL FROM:<...> SIZE=xxx
-command.

If client uses SIZE option on MAIL FROM, server is assumed that it check
that value and gives error message if needed
452 insufficient system storage
or
552 message size exceeds fixed maximium message size



Then on RFC 1870 there is chapter "6.3 Messages larger than the declared size."



Client calculated size may be little wrong on some implementations. It
may be just size of submitted message. This mabe is not taken account
such thing as LF => CR LF conversion when submitted message is converted
for SMTP world and is not perhaps account also headers which are needed
add to submitted message, before it is ready for SMTP world. And also
mey perhaps not taken account Receibed: -header which is added my MTA.


/ Kari Hurtta

Re: MTA closing connection after 552 response

Taylor, Grant wrote:

> I would think that the MTA should keep reading the message and let
> something else deal with the security of this issue. I would be tempted
> to set up something in the firewall that would intelligently interrupt the
> stream.

Eek... that sounds complex and error-prone.

I think if a server advertises a maximum message size of X bytes, it's
reasonable for it to close the connection abruptly if some small multiple
of X bytes is read (lets say 2X). Because receiving a message double the
size of the maximum you've said you will accept is clear evidence
of malicious intent or a broken SMTP client.

(Of course, this only applies if the SMTP client said EHLO. If it said
HELO, it's a tougher decision...)

Regards,

David.

Re: MTA closing connection after 552 response

David F. Skoll wrote:

> I think if a server advertises a maximum message size of X bytes, it's
> reasonable for it to close the connection abruptly if some small multiple
> of X bytes is read (lets say 2X). Because receiving a message double the

So the client will try again and again and again ...

> size of the maximum you've said you will accept is clear evidence
> of malicious intent or a broken SMTP client.

Then sendmail 8 has "malicious intent or a broken SMTP client."

Re: MTA closing connection after 552 response

Claus Aßmann wrote:

>> I think if a server advertises a maximum message size of X bytes, it's
>> reasonable for it to close the connection abruptly if some small multiple
>> of X bytes is read (lets say 2X). Because receiving a message double the

> So the client will try again and again and again ...

Yeah, but how do you combat someone who's trying to DoS you by sending
you gigabytes of data? At some point, you have to block it. I don't
think the *only* step should be closing the connection abruptly;
firewall-level responses are appropriate in extreme cases.

>> size of the maximum you've said you will accept is clear evidence
>> of malicious intent or a broken SMTP client.

> Then sendmail 8 has "malicious intent or a broken SMTP client."

If Sendmail 8 client uses ESMTP, and tries to send an e-mail larger than
the maximum advertised SIZE, and lies about it in the SIZE argument
to MAIL FROM:, then yes, it's broken or malicious. I do not believe
Sendmail 8 does that.

Regards,

David.

Re: MTA closing connection after 552 response

David F. Skoll wrote:
> Claus Aßmann wrote:

> >> I think if a server advertises a maximum message size of X bytes, it's
> >> reasonable for it to close the connection abruptly if some small multiple
> >> of X bytes is read (lets say 2X). Because receiving a message double the

> > So the client will try again and again and again ...

> Yeah, but how do you combat someone who's trying to DoS you by sending
> you gigabytes of data? At some point, you have to block it. I don't

How do you know it's meant as a DoS?

> think the *only* step should be closing the connection abruptly;
> firewall-level responses are appropriate in extreme cases.

Sure, if you can figure out that it is "malicious".

> >> size of the maximum you've said you will accept is clear evidence
> >> of malicious intent or a broken SMTP client.

> > Then sendmail 8 has "malicious intent or a broken SMTP client."

> If Sendmail 8 client uses ESMTP, and tries to send an e-mail larger than

Yes (if available).

> the maximum advertised SIZE, and lies about it in the SIZE argument

Yes.

> to MAIL FROM:, then yes, it's broken or malicious. I do not believe

That's a new item that wasn't in your original posting.

> Sendmail 8 does that.

sendmail 8 does all but the last. It relies on the server to reject the
mail: if the server doesn't reject the transaction at MAIL (due to the
SIZE= parameter), then sm8 will try to transfer the entire data.
See the source code (look for _FFR_CLIENT_SIZE).

Re: MTA closing connection after 552 response

Claus Aßmann wrote:

> How do you know it's meant as a DoS?

You don't know for sure, but given my conditions, it's a good assumption.

[snip]
>> the maximum advertised SIZE, and lies about it in the SIZE argument
>> to MAIL FROM:, then yes, it's broken or malicious.

> That's a new item that wasn't in your original posting.

Well, a client speaking ESMTP could not even get into the DATA phase
with an oversized e-mail unless it lied about the SIZE in MAIL FROM.

And I did mention that all of this applies only for ESMTP, not plain SMTP.

Regards,

David.

Re: MTA closing connection after 552 response

On 08/03/06 08:27, David F. Skoll wrote:
> Eek... that sounds complex and error-prone.

I did not say that it would be simple. I suspect that this would be easier
implemented as an application layer proxy. However it would be nice if
Sendmail it's self would handle this.

Is it possible for an SMTP server to send a result code back to the sending
side while it's in the DATA phase? I think a 5xy series error should be
sent back just in case the sending side will honor such a code. However,
if the sending side is blatantly exceeding the SIZE= value, then there is
also a good chance that it will not honor the 5xy code.

However, if it would be possible to send a 5xy code to the sending side, it
might also be possible to send a non ESMTP client a closer before the end
of the message.

> I think if a server advertises a maximum message size of X bytes, it's
> reasonable for it to close the connection abruptly if some small multiple
> of X bytes is read (lets say 2X). Because receiving a message double the
> size of the maximum you've said you will accept is clear evidence
> of malicious intent or a broken SMTP client.

I don't think that you even need to go as high as two times. I would think
10% over would be enough.

I also think that some sort of code needs to be sent back to the sending
side even if you know the sending side will not honor it. If for thing
else as a good faith / better person gesture.

> (Of course, this only applies if the SMTP client said EHLO. If it said
> HELO, it's a tougher decision...)

Eh, I think an async result code could help.



Grant. . . .

Re: MTA closing connection after 552 response

"David F. Skoll" writes:

> Claus Aßmann wrote:
>
> > How do you know it's meant as a DoS?
>
> You don't know for sure, but given my conditions, it's a good assumption.
>
> [snip]
> >> the maximum advertised SIZE, and lies about it in the SIZE argument
> >> to MAIL FROM:, then yes, it's broken or malicious.
>
> > That's a new item that wasn't in your original posting.
>
> Well, a client speaking ESMTP could not even get into the DATA phase
> with an oversized e-mail unless it lied about the SIZE in MAIL FROM.

Well, client do not need announce SIZE. Using EHLO do not mean that
client supports SIZE

This also assumes that server check given SIZE argument.

I wrote about that an another article.

> And I did mention that all of this applies only for ESMTP, not plain SMTP.

Actually you are assuming more.

> Regards,
>
> David.

/ Kari Hurtta

Re: MTA closing connection after 552 response

On 08/06/06 12:24, Kari Hurtta wrote:
> Well, client do not need announce SIZE. Using EHLO do not mean that
> client supports SIZE
>
> This also assumes that server check given SIZE argument.

It is my understanding that if a server advertises that it supports "SIZE"
it mus check the size argument. Or are you indicating that there are
servers that are broken in this regard?

> I wrote about that an another article.

Do you mind providing a location for said article? I'd be interested in
reading it.



Grant. . . .

Re: MTA closing connection after 552 response

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-1294-1154906951-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Taylor, Grant writes:

> On 08/06/06 12:24, Kari Hurtta wrote:
>> Well, client do not need announce SIZE. Using EHLO do not mean that
>> client supports SIZE
>>
>> This also assumes that server check given SIZE argument.
>
> It is my understanding that if a server advertises that it supports "SIZE"
> it mus check the size argument.

RFC 1870 says it must, but the SIZE argument itself is defined as only an
"estimate". A client is certainly free to send a larger SIZE estimate, and
the server is free to reject it, or accept it.


--=_mimegpg-commodore.email-scan.com-1294-1154906951-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQBE1ntHx9p3GYHlUOIRAktzAJ9c/8MJqiZgw/ipGSiqG1NZ7AIMrwCc C0fS
YonxsOCaNarR0bVV9E+NSNg=
=kYR4
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-1294-1154906951-0001--

Re: MTA closing connection after 552 response

"Taylor, Grant" writes:

> > I wrote about that an another article.
>
> Do you mind providing a location for said article? I'd be interested
> in reading it.

I wrote on earlier:

From: Kari Hurtta
Subject: Re: MTA closing connection after 552 response
Newsgroups: comp.mail.misc
Date: 03 Aug 2006 07:24:42 +0300

<...>

If client uses SIZE -option on MAIL FROM, that announced size of message is
not always exact.

Servers announce of maximum size on EHLO response is one way. There is
no negotation. This just informs that which messages server will reject
saving work from client. Although work on this case is just
MAIL FROM:<...> SIZE=xxx
-command.

If client uses SIZE option on MAIL FROM, server is assumed that it check
that value and gives error message if needed
452 insufficient system storage
or
552 message size exceeds fixed maximium message size



Then on RFC 1870 there is chapter "6.3 Messages larger than the declared size."



Client calculated size may be little wrong on some implementations. It
may be just size of submitted message. This mabe is not taken account
such thing as LF => CR LF conversion when submitted message is converted
for SMTP world and is not perhaps account also headers which are needed
add to submitted message, before it is ready for SMTP world. And also
mey perhaps not taken account Receibed: -header which is added my MTA.


/ Kari Hurtta

Re: MTA closing connection after 552 response

Sam writes:

> Taylor, Grant writes:
>
> > On 08/06/06 12:24, Kari Hurtta wrote:
> >> Well, client do not need announce SIZE. Using EHLO do not mean that
> >> client supports SIZE This also assumes that server check given SIZE
> >> argument.
> > It is my understanding that if a server advertises that it supports
> > "SIZE" it mus check the size argument.
>
> RFC 1870 says it must, but the SIZE argument itself is defined as only
> an "estimate". A client is certainly free to send a larger SIZE
> estimate, and the server is free to reject it, or accept it.

Well, it says "should":

6.1 Server action on receipt of the extended MAIL command

Upon receipt of an extended MAIL command containing a SIZE parameter,
a server should determine whether the declared message size exceeds
its fixed maximum message size. If the declared message size is
smaller than the fixed maximum message size, the server may also wish
to determine whether sufficient resources are available to buffer a
message of the declared message size and to maintain it in stable
storage, until the message can be delivered or relayed to each of its
recipients.



/ Kari Hurtta

Re: MTA closing connection after 552 response

Kari Hurtta writes:

> Client calculated size may be little wrong on some implementations. It
> may be just size of submitted message. This mabe is not taken account
> such thing as LF => CR LF conversion when submitted message is converted
> for SMTP world and is not perhaps account also headers which are needed
> add to submitted message, before it is ready for SMTP world. And also
> mey perhaps not taken account Receibed: -header which is added my MTA.



Or perhaps even miscalculation of size because of conversion.

Server do not announce 8BITMIME but client have announced 8BITMIME.

So smtp client does content-transfer-encodong change 8bit->base64
or 8bit->quoted-printable --

this adds about 30% to size for base64, and adds 200% to size on
worst case for quoted-printable.

but client uses original size for SIZE= -parameter.

/ Kari Hurtta