Re: comments on refuse

[Michael Haardt <[e-mail]>]

On Thu, Aug 04, 2005 at 05:45:04AM -0700, Philip Guenther wrote:
> draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
> based on a claimed ability to reduce the amount and/or likelihood
> of joe-job spam.  By my reading, there is only a reduction in amount
> by replacing one or more MDNs (one per recipient using 'reject')
> with one DSN and no reduction in likelihood.  While a message that
> is refused by all recipients can indeed be refused at the SMTP-level
> at the final dot, a DSN will still be generated unless the message
> was received directly from the submitting software by the SMTP-based
> sieve implementation.  That doesn't apply when open relays ("open
> proxies" in the draft) are involved or if the sieve implementation
> is behind any MTAs that don't synchronously pass-through messages.

You are correct, but as a matter of fact, I do receive quite a bunch
of spam right from the sending host (spam companies or compromised (?)
dial-up systems) to a single recipient.  I have no numbers, though.

IMHO, messages should be refused at the earliest possible point.  I do not
like that refuse is not defined that way, leaving open where that point
is for a specific system.  I would prefer an action like "refuse at the
earliest point, and if that means bouncing, then bounce it".  As it is,
we have reject, which always bounces, and refuse, which always refuses.
I have to remember which system offers what for avoiding bounces where
possible.

>  - shouldn't "open proxies" be "open relays"?  This is a reference
>    to MTAs that relay without limits, right?

Open proxies may be correct.  For one, there is a bunch SOCKS proxies.
For another, there are many MTAs that do not count syntax errors
or enforce SMTP synchronisation points, thus being vulnerable to HTTP
proxies being used to CONNECT to port 25.  Sending spam through open
relays has become a little old-fashioned.

Michael