well, my initial reaction is that for 'applies-to' you need to be clear
about what this means. is it:
a. the address that appears in the From field (regardless of who
actually sent the message)
b. the address that appears in SMTP MAIL FROM / Return-Path
(regardless of who actually sent the message)
c. the address that sent the message (assuming some way to
identify/authenticate that party)
d. some other address
e. more than one of a-d
I meant the envelope recipient - the address in the RCTP TO
here's what I think consent looks like. this would be placed on a
net-accessible server in some place where it could be found using
the address moore(_at_)cs(_dot_)utk(_dot_)edu - probably you'd do a dns lookup
I'm keeping away from any implementation details - it's way too
early - I think. But yes, something like that, why not.
-
recipient moore(_at_)cs(_dot_)utk(_dot_)edu consents to having messages
matching any
of the following criteria not delivered normally, with the following
actions taken:
a) any message with more than 5 non-ASCII characters in the subject field
(action=discard)
b) any message with a MAIL FROM address that is invalid (action=discard)
c) any message with a From header address that is invalid
These would come under the heading of message classifications.
and the whole thing could be signed. (granted, details of establishing
reasonable trust in the signature could be tricky)
I think it's possible to limit the signing requirement.
Organisations and local systems have more direct means of
authenticating the source of a consent (does it come from
one of our subnets, or something).
this is a deliberately complex example, but I wanted to illustrate
several things:
1. a variety of kinds of criteria, some based on content, some based
on ability to identify the source, some based on trustworthiness
of the source, some based on volume, some based on criteria specified
elsewhere
all really part of some message classification component
2. a variety of actions: e.g. bounce, delay, discard, deliver,
and/or limit the kinds of messages I will accept
I only need to (accept | deny) really - the disposition of the
offending message is an issue of configuring the consent seeking
entity - what it does when a "deny" is obtained
- if this entity is my MUA that's covered separately.
If I need to control disposition, then I only ever issue consents
with local scope. Bingo.
3. filtering things that aren't of interest to me, whether or not they
meet anyone else's criteria for "spam". (like the annoying message
from djb insisting that everyone should adopt his method of composing
replies)
I can have my MUA (consulting a local consent) filter against local
classifications.. as well as more widely scoped ones.
btw, the sender-id tag is a tag that would be supplied by the sender
I have problems with identifying senders (as do others
- there's a lot on the list about this)
So I'm concentrating on the intended *recipient*
now, the purpose in supplying these criteria is to allow filtering
of the message *at any point upstream*. essentially it's saying
"I'm going to discard these anyway, so there's no point in sending
them to me." so one or more MTAs could query a recipient's filtering
criteria and then optionally apply whatever criteria they understood
and wished to apply - thus saving them bandwidth, etc.
Yes.
(it would be important to specify this carefully -in my example there
are criteria for delivery that are meant to pre-empt later criteria
for pessimal handling - e.g. if you're on my whitelist I want the message
delivered even if your ISP is untrustworthy. it would not be good to
have some MTA ignore the whitelist and apply the later criteria.)
This just needs "accept" to have higher priority than "deny" - I think?
I should have made that clear. I skipped that - it's probably in the
"folding" mechanism...
Thanks for your feedback.
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg