[Top] [All Lists]

Re: [ietf-smtp] Dombox - A Zero Spam Mail System

2019-10-05 06:36:12

notwithstanding the usefulness of the ideas, provided that new rules are 
supposed to be applied at SMTP level right
after the RCPT TO:, and let each recipient tweak these rules, based on 
destination address and other criteria, the next
step would be to extend Sieve to accommodate these filtering rules.

Sieve can already deal with the fact that a single (natural) recipient can have 
several addresses and apply different
logic based on the envelope destination for that natural recipient.  But it 
cannot check directly DNS.  It could check
however over “external lists” if DNS/SPF matches (but this could be done also 
by matching against the Authentication-
Results header).

Has anybody tried to parse the Authentication-Results header in Sieve?  Does it 

Perhaps you can write guidelines how to use Sieve to perform (further) per 
recipient rules, reusing the capabilities the
language already has, possibly extending the language, is the way to go.

Or, adding new checks, that are inserted in the AR header.

Or, if the concepts can be applied independent of each other, describe each 
idea in a separate document (internet


On Fri, 2019-10-04 at 23:59 -0400, Hector Santos wrote:

What would you like to be extracted from your extensive work?  Do you 
have a protocol in mind? a method? an Extended SMTP proposal? a rule 
to be applied at SMTP? At the MSA, the MDA, the MFA (Mail Filtering 
Agent) or the MUA?

There are SMTP documents for Sender Rewriting rules, to rewrite the 
reverse-path.  I recall one was used with the idea to circumvent the 
SPF Node Transition problems when the IP changes but the reverse-path 
domain does not.  The reverse-path is a persistent identity.

Keep in mind that SMTP does not do what your MUA is doing.  SMTP is 
about the transport of mail.  The filtering, the classification, the 
RBM, the once patented concept "Rule-Based Messaging," is generally an 
implementation (product) specific thing and would normally be 
something that separate us.

What you can do, in my opinion, is write an individual draft proposal 
with a status of "Informational" that describes your method.  If you 
can isolate it to a general algorithm without mentioning your product 
and implementation method, i.e., using Chrome extensions for your UI, 
which makes it a web base UI, but your protocol, your rules, would be 
independent of that UI.

This would be one way I see some traction with this. Give us protocol 
rules for handing the SMTP Process Entities which are:

CIP - Connection IP
CDN - Client Domain Name (presented at EHLO/HELO)
RP  - Reverse Path
FP  - Forwarding Path
DATA  RFC5322 payload

Those are the SMTP process parameters.  Present a proposal for using 
these parameters for the betterment of email-kind.

ietf-smtp mailing list