smtp server: treating large files

Hello everyone,

I am currently writing an SMTP server and would like to ask for some
clarification on the SMTP RFC. I currently have a case where someone
is sending a large file >10MB to me. My mail server, at 10MB point,
sends an ERR message back saying the file is too large, and then
subsequently closes the connection. The sending email server seems to
ignore this and simply restarts sending the message from the very
beginning around 10-30 seconds after my server sends the QUIT. This is
an indefinite loop, I have to refuse to accept connections from the
server in order to get out of it.

So now, besides actually writing some code to block such cases, I am
wondering if I'm not properly closing the connection. Can someone who
maybe knows more about the RFC tell me what is the correct procedure
in this case? I know that qmail doesn't comply with the RFC, maybe
there's some more commonly used method for doing this?

Thanks in advance.

Re: smtp server: treating large files

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-16419-1175901719-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

mno writes:

> Hello everyone,
>
> I am currently writing an SMTP server and would like to ask for some
> clarification on the SMTP RFC. I currently have a case where someone
> is sending a large file >10MB to me. My mail server, at 10MB point,
> sends an ERR message back

There's no such thing as an "ERR" message in the SMTP.

> saying the file is too large, and then
> subsequently closes the connection. The sending email server seems to
> ignore this and simply restarts sending the message from the very
> beginning around 10-30 seconds after my server sends the QUIT. This is
> an indefinite loop, I have to refuse to accept connections from the
> server in order to get out of it.
>
> So now, besides actually writing some code to block such cases, I am
> wondering if I'm not properly closing the connection.

You're not.

> Can someone who
> maybe knows more about the RFC tell me what is the correct procedure
> in this case?

The correct way is to wait until you receive the entire message, until you
receive the sequence CRLF.CRLF, then return an SMTP 5xx error code to the
sender, then wait for the sender's next command.

You cannot just send an error message whenever you feel like. Something
tells me that if _your_ mail server is in the middle of sending a message to
someone else, and in the middle of transmitting the message you receive an
error message, you will ignore it. You will rightfully wait until you've
finished sending the message, then wait for the receiver to respond to you.
Furthermore if your connection breaks in the middle of the transmission, you
will correctly interpret it as a temporary network problem, and try again
later. Which is exactly what you're seeing yourself.


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

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

iD8DBQBGFtYXx9p3GYHlUOIRAonoAJwL+fsOE5LLQ1jB0W/1yV9znevZNQCe IFYx
COj6EFyD2cW6oE0QXtC0Fhk=
=acpQ
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-16419-1175901719-0001--

Re: smtp server: treating large files

On Apr 7, 1:22 am, Sam wrote:
> There's no such thing as an "ERR" message in the SMTP.

Yes that's true. When I wrote ERR, I actually meant a 5xx message :)

> The correct way is to wait until you receive the entire message, until you
> receive the sequence CRLF.CRLF, then return an SMTP 5xx error code to the
> sender, then wait for the sender's next command.

Thanks. I was thinking along these lines, too, but then thought that
what's the point to wait for the whole message.

Thanks for the response.