Subject: comments on refuse

From: Philip Guenther <[email-masked]>
Date: Thu, 04 Aug 2005 05:45:04 -0700

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.

I therefore suggest that the introduction and abstract limit
themselves to claims that can then be justified in the body of the
draft.

Editorial:
 - shouldn't "open proxies" be "open relays"?  This is a reference
   to MTAs that relay without limits, right?
 - there are many sentences that contain too many commas.  Most
   simply need one or more commas removed; some should be split
   into two sentences
 - abstracts may not contain references
 - the second paragraph of section 3 should be rephrased to state
   that it applies only to SMTP and not LMTP from the start, ala
	"If the implmentation receives a message via SMTP that
	 has multiple valid recipients and at least...

Philip Guenther

---

From: Michael Haardt <[email-masked]>
Date: Fri, 5 Aug 2005 20:19:35 +0200

> 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.

>    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

---

From: Matthew Elvey <[email-masked]>
Date: Sat, 06 Aug 2005 15:11:15 -0700

I'd like to solve the spam problem (see 
www.rhyolite.com/anti-spam/you-might-be.html ) but we're just proposing 
a small improvement to SIEVE, that will help in a small but significant 
way reduce resource usage, but doesn't require changes that break 
existing Sieve or SMTP implementations.  That implies some serious 
constraints!
'Refuse' only claims to be _less_ likely to result in backscatter to an 
innocent victim.  It is not 'discard', or CSV (the 'best' spam remedy, 
IMO - see 
http://wiki.fastmail.fm/index.php/Certified_Server_Validation), or BATV.

On 8/5/05 11:19 AM, Michael Haardt sent forth electrons to convey:
>> with one DSN and no reduction in likelihood.
This is not consistent with what you say later; I think you've 
misunderstood the spec.  'Refuse' will replace one notification with 
another in a small fraction (my estimate: 10% of the time(a few % due to 
the exception in section 3, a few % due to 5xx errors to unidentified or 
unblocked relays, etc.) ; certainly << 100%) of the time it acts.  My 
estimate implies a 90% reduction in backscatter for those replacing 
reject with refuse.
>>   While a message that
>> sieve implementation.  
I find that this exception is actually a common case, accounting for >> 
17% of mail delivery attempts.  And in this case, neither an MDN nor a 
DSN is generated. (The research paper at 
http://www.ceas.cc/papers-2005/120.pdf confirms that some 17% of mail 
delivery attempts these days are made from SMTP malware that can't even 
retry, and hence almost certainly can't create DSNs either)
>> That doesn't apply when open relays ("open
>> proxies" in the draft) are involved 
Let me know if I need to explain the difference between open relay and 
open proxy and how each is used by spammers to send spam.

I believe that most mail servers on the Internet do not accept mail from 
identifiable open relays and open proxies at all, and for them 'refuse' 
has no impact on backscatter.

Supporting argument: Most such systems are on blacklists such as 
[http|socks|smtp|web].dnsbl.sorbs.net (see 
http://www.us.sorbs.net/using.shtml for definitions; MAPS and others 
have similar lists among their offerings). In particular they are on the 
blacklists that a consensus of reports state have the lowest risk of 
being used to block non-spam (that is, even lower risk than the SBL 
blacklist, which protects half a billion mailboxes) and hence are the 
most widely used.  When such blacklists are used, mail is often blocked 
before sieve even sees the message. Blocking could occur at EHLO or 
earlier, such as at a border firewall.
>> or if the sieve implementation
A careful reading of the draft will show that such implementations 
cannot support the refuse extension.  Please reread the draft and let me 
know if this is not clear. (Section 3, first paragraph)
> is for a specific system.  
OK, I agree with you here.  Now we just have to come up with wording to 
make this clearer in the draft. 
Also, I have noticed that most drafts addressing spam have weak language 
such as:

"The handling of such messages is at the discretion of the verifier or 
final recipient."
              -DKIM draft ( 
http://ietf.org/internet-drafts/draft-allman-dkim-ssp-00.txt )
or
"... system MAY choose to reject or discard email on the
   basis of local policy...  The
   actual policy decisions are outside the scope of this document."
              - http://spf.pobox.com/spf-draft-200406.txt (SenderID has 
very similar language.)
Then again, CSV has somewhat stronger language:
"...caution is required. The receiving SMTP server might:
    - Generate an SMTP session error, as suggested below.
    - Mark the message, to indicate that it failed validation.
    - Place the message into a special queue, for separate handling."
               CSV CSA draft ( 
http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.html#anchor4 )

Would you be satisfied if I added this at the beginning of section 3?:
"Messages should be refused at the earliest possible point."

[Alexey: I am going to steal back the virtual edit baton, OK?  Or have 
you already started making edits?  IIRC you are holding it.]
> I would prefer an action like "refuse at the
> earliest point, and if that means bouncing, then bounce it".
How exactly does what you prefer differ from the action as I defined it 
in the current spec?   The current spec indicates (several times!) that 
bouncing is a last resort and lists several negative side effects.
>   As it is,
Backwards compatibility is a #1$@%.  I expected there would be multiple 
objections if I tried redefining reject, which is the only reason I 
haven't tried.
> relays has become a little old-fashioned.
"Open proxies" is correct.  With "open relays", the sentence doesn't 
make sense.
> Michael

P.S.:  Alexey: 3042bisv4 gets a belated nod from me.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 13 Aug 2005 20:02:07 +0100

Matthew Elvey wrote:

> cannot support the refuse extension.

Uh, no. This is not what the current text says and I don't think we 
should prohibit deployment of refuse for such configurations.

> Please reread the draft and let me know if this is not clear. (Section 
> 3, first paragraph)