Hello,
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
work?
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
draft).
Greetings
Дилян
On Fri, 2019-10-04 at 23:59 -0400, Hector Santos wrote:
Viruthagiri,
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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp