Subject: [Asrg] SHOULD filtering be done as part of SMTP transaction (was RE: Som e data on the validity of MAIL FROM addresses)

From: Paul Judge <[email-masked]>
Date: Wed, 21 May 2003 11:09:20 -0400

> -----Original Message-----
> From: Vernon Schryver [mailto:[email-masked]] 
> Sent: Wednesday, May 21, 2003 10:41 AM

> We have agreed is that as people configure and run STMP 
> servers for various good and bad reasons, an SMTP server may 
> not know the final address and so may have problems doing 
> proper spam filtering.
> 
> However, that fact does not imply that filtering cannot be 
> done before the end of the SMTP transaction or that it is not 
> best done then. You seem to be asserting to the contrary that 
> filtering must or should be done primarily during final 
> delivery.  We certainly have not agreed on that, although 
> there have been some recent statements by others in support 
> of that view.
> 
> That fact also does not conflict with the fact that most 
> filtering could be done during the STMP transaction given 
> perhaps onerous efforts to synchronize user databases, 
> whitelists, logs, and so forth among SMTP servers.
> 
> I suspect that most filtering today does not need any 
> synchronizing among SMTP servers but could be done during the 
> SMTP transaction given appropriate filtering software.  For 
> example, it sounds as if the SpamAssassin milters need work.
> 
> None of that implies that additional filtering during final 
> delivery cannot or must not be done.

It is clear that there are reasons to do filtering as part of the SMTP
transaction as well as difficulties in doing so. In many cases this is
straightforward; in other cases, there are substantial efforts to achieve
this in some cases; and in other situations, there are limitations that may
make this inachievable.

> An IETF/IRTF working group mailing list is not like netnews 
> or SPAM-L. It is not merely a forum for stating positions and 
> exchanging views. It is a tool for generating and guaging 
> consensus on technical issues. Regardless of heat, this 
> mailing list must address the issue of whether filtering 
> SHOULD (in the special meaning of RFC 2119) be done during 
> the SMTP transaction.  If we can't reach consensus on such a 
> fundamental and simple issue, then this mailing list is 
> distinctly worse than useless.

We should articulate the benefits of providing filtering within the
transaction as well as explain the implications of not doing so.

This also depends on the document that this will be a part of and the
context of the statement.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 21 May 2003 20:27:32 +0100

> transaction as well as explain the implications of not doing so.

I'd be happy to have a go at getting this together.

--

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 23 May 2003 14:32:46 +0100

I've made a start on an overview of filtering in SMTP
(regarding anti-spam efforts).

It's very preliminary.

It'd be very grateful for any comments and suggestions.
It's here:
http://www.merseymail.com/asrg/Filter-SMTP-0-1.txt

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 23 May 2003 14:01:58 -0600 (MDT)

> From: "Jon Kyme" <[email-masked]>

> http://www.merseymail.com/asrg/Filter-SMTP-0-1.txt

Assuming this text is intended for an RFC, I'd recommend avoiding
shortcuts and imprecise language.  For example, instead of "Rejection
in SMTP," I would write "Rejection during the SMTP transaction" no
matter how boring it is to repeatedly write "SMTP transaction."

Overall, it is a good start, but I think it needs to be far longer.
It should be more discoursive, including stating underlying assumptions
and commonly shared notions.  What are "false positives"?  What are
examples of the relevant "support and maintenance issues"?

What are the types of filtering in section 2?  They need to be
spelled out.  I've few or now cluse about 2.4, 2.5 and 2.6.  It
would be good to use words defined in other documents, but their
definitions should be copied here them here if they are not obvious.

The opportunities for decisions in the diagram at the end of section
2 are good, but it should be noted that deferring action can be
profitable.  For example, it is effective to delay rejecting spam
identified by SMTP client IP addresses (e.g. with DNS blacklists)
until the message body has been received and sent to a filter such as
the DCC or Vipul's Razor or a "Bayesian trainer."

Section 3 should mention other alternatives such as rejecting with a
4yz response recipients whose filtering preferences differ from the
first recipient.

The phrase "boundary MTA" in section 4 is too restrictive.  The problems
occur whenever there is more than one MX server for a domain.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg