On 26/12/04 01:38 +0000, gep2(_at_)terabites(_dot_)com wrote:
Maybe, but HEADER analysis might be helpful.
I don't think I quite understand your point here.
A mail transaction typically goes like this:
<tcp connection> from high port to port 25 of the server
The server checks up the reverse DNS of the client.
S: 220 <server.hostname> [ESMTP]
C: HELO <client.hostname> (or EHLO for ESMTP)
S: 250 Ok
C: MAIL FROM:<sender(_at_)example(_dot_)com>
S: 250 Ok
C: RCPT TO:<recipient(_at_)example(_dot_)net>
S: 250 Ok
... (client adds more RCPT TOs here)
C: Data
S: 354 Send CRLF.CRLF to end
Message headers
Message Body
.
S: 250 Ok
quit
S: 221 Ok
<tcp connection teardown>
Of course.
Now, you know the actual message size only after the data was sent.
Well, you know the maximum OFFERED size by then.
Offered? The server shows a limit on the message size offered. We
already know that. The question is whether the client will honour that
limit (real mail servers supporting ESMTP do, and won't send the message
on at all).
IF during the transfer, the recipient's inbox overflows (and, if they are the
ONLY addressee there for the message!) you no longer have to be concerned
about how much more there might be in the wings... once you've decided that
the message is "too big" and is going to be bounced. You don't HAVE to keep
receiving the rest of it, at that point.
You do have to receive the rest of it.
If the client sends a ehlo, it may send a size value, but that cannot be
known to be correct. The message headers and body are part of the
message itself, as part as SMTP is concerned.
Sure, but that doesn't mean that the connection can't be dropped DURING
the body transfer.
See the RFCs. It does mean exactly that.
Devdas Bhagat
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg