Re: [exim] Client SMTP keepalive methods?

On 6/6/06 12:24 PM, "Alan J. Flavell" <a.flavell@???> wrote:

> Senders who give up prematurely in the face of a modest delay
> ("modest" in terms of the published specification, I mean) are usually
> spammers. I don't see any reason not to treat anyone behaving like
> that as suspects.

Generally (not always), Outlook connecting to one's server should be one's
client (customer, student, etc).

It makes sense, I think, to accommodate such people (not doing so increases
support costs). And it should be true that a server can tell connections
from its customers apart from connections from the world (ours come in via
different server IP addresses and except for travelers from addresses we
recognize, and [should be] authenticated).

Having made that distinction, one then has to ask whether the human behind
the client software gets more understandable messages from an SMTP-time
reject or from a later bounce. If it is intended to give a multi-line
rejection message, the bounce is usually better unless you know the MUA
everyone uses, since some will show only the first line, some only the last
line, some the whole thing, and there are probably other variants. (Then,
too, some MUAs neatly hide the fact that anything went wrong at all, for
SMTP-time rejections. That leads to support calls--in some cases--about
being unable to *RECEIVE* mail [the client has a message to send, that
fails, so it doesn't try to receive but hides the error in a little yellow
icon].)

Outlook is, after all, widely used.

--John