Hello,
I consider your plans to be a brilliant idea that would perfectly
help with some of the most recent problems we have:
- Customers with Mailservers that have a per-user-quota and
send a braindead 4xx-response to the "RCPT TO: <username@..>"
request
- Braindead MTAs and Firewalls that will timeout after the '.'-
command, if the E-Mail contains a '\0' at the end:
E.g. they would not recognize 'Bye, John\0\n.\n' as a valid
end of the DATA-section.
Braindead in this meaning are:
- StarGate
- WatchGuard Firewall
- A very silly Firewall SMTP-Implementation that tries to limit
the incoming mail size by "interrupting" the connection.
(Yes, it just drops the connection at x MB. This is really
good for ISPs having a volumne-based charge)
Beneath the traffic, other messages get stuck behind the
big one.
A few comments:
> (B) A message error is associated with a particular message when sent to a
> particular host, but not with a particular recipient of the message. The
> message errors are:
>
> . Any error response code to MAIL FROM, DATA, or "."
> . Timeout after MAIL FROM
. SIZE-feature in EHLO-response with a SIZE below the message size
. Timeout after DATA
(See above)
>
> (C) A recipient error is associated with a particular recipient of a message.
> The recipient errors are:
>
> . Any error response to RCPT TO
> . Timeout after RCPT TO
>
> A permanent error response (5xx) causes the recipient address to be
> failed, and a delivery error report to be returned to the sender. A
> temporary error or a timeout causes routing retry data to be created for
> the failing address.
> This means that the address will not be processed
> again, in any message, until its retry time arrives.
****************
I think this policy is acceptable, but this might be possible:
MAIL FROM: <mailing@???> SIZE=<the size is BIIIG>
250 You are welcome
RCPT TO: <gvz@???>
250 O.k., Georg love's to get big mails
RCPT TO: <poorboy@???>
420-Sorry, this user just has a 10 MB-POP3-box, your mail does not
420-fit in at the moment...
poorboy will get no further messages from us, till his retry time
is reached...
Greetings,
Georg
--
*** Exim information can be found at
http://www.exim.org/ ***
