Michael Adkins wrote:
I would agree with you that valid signatures still require help in the
area of positive reputations. But IMO, failure detection provided
with DKIM+POLICY is where you don't really need reputation.
Just consider reputation is already widely in practice in many forms.
Many believe that good signatures will not trump a bad rap and vice
a versa, bad signatures will not trump a good rap. So whats the rule
here? Does reputation trump DKIM/POLICY? Is it don't by weights? Or
some does certified trusted service govern who is good or bad?
Whether or not you should apply someone's policy declarations is more of
a function of their class than their reputation. You can't assume that
'significant' is the same thing as 'reputable'.
If I think social networks have a reasonable use case for policy
declaration, then it doesn't really matter how heavily one is abused
versus another. I'm going to apply both their policies regardless.
We'll never get anywhere if we keep dragging 'good' and 'bad' into it.
+1. 100% agree. I was making reference to how the term "significant"
was used here as to suggest it is the only thing that matters in the
decision process.
From my perspective, we (always) needed something that will help
better define or rather "justify" the growing mail DISCARD ideas that
are needed to fight back scatters and malicious mail.
This, in light of the fact that as of 2008, RFC 5321 (formerly 2821)
now has semantics that allows operations to justify not adhering to
the MUST BOUNCE requirement.
Systems that operate at the accept first (POST SMTP) payload checking
MUST support SMTP requirements for bouncing. From RFC 5321
6.1. Reliable Delivery and Replies by Email
When the receiver-SMTP accepts a piece of mail (by sending a "250
OK" message in response to DATA), it is accepting responsibility
for delivering or relaying the message. It must take this
responsibility seriously. It MUST NOT lose the message for
frivolous reasons, such as because the host later crashes or
because of a predictable resource shortage. Some reasons that are
not considered frivolous are discussed in the next subsection and
in Section 7.8.
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message.
What is new to SMTP developers and operators via the new 5321
guidelines is 7.8:
7.8. Resistance to Attacks
In recent years, there has been an increase of attacks on SMTP
servers, either in conjunction with attempts to discover addresses
for sending unsolicited messages or simply to make the servers
inaccessible to others (i.e., as an application-level denial of
service attack). While the means of doing so are beyond the scope
of this Standard, rational operational behavior requires that
servers be permitted to detect such attacks and take action to
defend themselves.
7.8 is new to 5321 as of 2008. This was never a "written"
consideration for this in the past 25 years. User expectation for
"notification" was "natural law."
But people did it anyway - the growing abusive era required it.
The point:
For growing systems who will perform DATA checking dynamically at the
SMTP level, an ADSP discard policy will behave as a SMTP compliant 55x
reject response. No mail notification is required. No SMTP violation.
On the other hand, systems that accept first then analyze the payload
are pressured with a bounce requirement. If ADSP is followed, it is
not a REJECT, but a DISCARD idea.
Mail reliability decreases if we don't give systems new non-frivolous
justifications to apply via the new 7.8 semantics.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html