Re: [Asrg] SHOULD filtering be done as part of SMTP transaction

> From: "Jon Kyme" <jrk@merseymail.com>

> 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

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    vjs@rhyolite.com
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg