[nzlug] (OT) Sorbs etc, was Exim: Limiting outgoing connections on Debian

[Daniel Pittman]

Cliff Pratt <enkidu at cliffp.com> writes:
> Daniel Pittman wrote:
>> Cliff Pratt <enkidu at cliffp.com> writes:
>>> Donald Gordon wrote:
>>>> On Fri, 06 Oct 2006 15:12:37 +1300, Tony Wills <ajwills at paradise.net.nz> wrote:
>>>>
>>>>> I still get tons of SPAM via my ISP (although the amount that
>>>>> they're syphoning into the Spam folder at their end seems to have
>>>>> diminished).  I get none through my own server which uses
>>>>> greylisting - a very effective idea for small email servers - I get
>>>>> an awful lot of "unexpected disconnectsion"s from spammers that are
>>>>> asked to wait :-)
>>>>
>>>> Greylisting is not terribly wonderful.  It cuts down on some spam,
>>>> but breaks an expectation that many users have: that their email is
>>>> sent instantaneously.  And I have a client whose odd Mac-based
>>>> mailserver package doesn't know what retrying is :-(
>>> Greylisting is an evil perversion of the SMTP protocol and if I find
>>> any servers using it I blacklist them. Nasty obnoxious bandwidth and
>>> spool space wasters!
>>
>> I don't think that word means what you think it means...
>>
>> The SMTP protocol defined soft error cases specifically because there
>> *are* cases where a later attempt to deliver the same message will
>> succeed.
>>
>> The traditional examples were a host that had mail down for maintenance,
>> a mailbox over quota or a site that was under too much load.[1]
>>
>> So, whatever else greylisting may be, it is *not* a perversion of the
>> SMTP protocol.  It is, in fact, a use of the SMTP protocol as designed.
>>
>> That fact doesn't contribute anything to the debate on the use of
>> greylisting, but neither do false claims about "perversion" of
>> protocols.
>
> "Perversion" has, these days, unpleasant connotations that I did not
> intend. I was thinking of the word in the sense of the "WordNet"
> definition on Dictionary.com: "The action of perverting something
> (turning it to a wrong use)".
>
> I'm not going to prolong the discussion on this topic, so my final
> word is that I dispute that greylisting is a "use of the protocol as
> designed". The temporary error facility is intended to provide the
> ability to recover from a situation, as you say, where the receiving
> SMTP server is unable to accept the message. 

Unable or unwilling -- in the case of a mailbox over quota it certainly
/could/ accept the message[1], or in the case where the load is higher
than a systems administrator configured value.

> In other words, it was for the benefit of the sender. It was never
> intended to introduce an intentional delay and was never intended to
> be used to the benefit of the receiving SMTP server!

Actually, it was always intended to benefit the receiving server, as
they were signalling that they could later accept the message and,
please, would you mind trying again later?

It was also intended to introduce an intentional delay in, as a concrete
example, the sendmail behaviour where it will issue a 4xx code to
request the sender retry later because current machine load is too high.


That is an entirely optional use of the 4xx code: Postfix doesn't bother
with that, for example, and nor does qmail.

It is an entirely receiving side benefit: the server can allow load to
reduce naturally before it accepts more mail and, therefore, more work
to do.

It introduces a deliberate delay into the SMTP process: the sender is
required to wait, and to retry at a later date, entirely at the whim of
the recipient server.


The use of a 4xx code is really at the whim of the receiving server, and
can certainly be for no better reason than that it doesn't want to talk
to you now, please try again later.


So, which I can understand that you might see greylisting as a new and
unpleasant change to the protocol I can't agree that it is substantially
different to existing, common practice on the Internet long before the
idea even came to light in an anti-SPAM context.

Regards,
        Daniel

Footnotes: 
[1]  At least, in cases where the quota is a soft quota implemented only
     in the mail handling facilities.  This is not uncommon in, say,
     most large scale commercial mail products.
-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/