On 1/24/11 7:55 PM, Dotzero wrote:
On Mon, Jan 24, 2011 at 10:24 PM, Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org>
wrote:
> Defeating spam requires the reputation of SMTP clients be weighed
> for rejection or acceptance!
Doug, could you share with us what reputation is?
Reputation Definition: An assessment of an identifier that accurately
reflects the behavior of the resource administrator. For example, these
identifiers might be the address of an SMTP client or the AS of the
network provider.
SPF represents a poor choice. SPF represents an unreliable
authorization mechanism that also fails at isolating behaviors of
resource administrators. Those who attempt to make use of this
mechanism often weaken the integrity of email delivery.
As far the mailbox providers are concerned (that I have spoken with)
it is reduced to "What have you done to me today".
Sorry, but this statement is vague, as is SPF. No one knows how SPF
might be used. A PASS used as a basis to verify an unseen Sender-ID PRA
header or Return-Path parameter can be highly deceptive and even place
recipients at risk. Malefactors can authorize anyone's resources, where
macros contained in SPF can also obfuscate their breath.
Their systems don't care whether you have had a good reputation for
the past 2 years. If you start spewing badness today and you start
generating complaints today then you will be throttled or blocked.
SPF does not help with this problem, nor can DKIM be safely used in this
manner, as it is designed to permit replays. See Reputation Definition.
If the time interval of reputation is that short then reputation
systems are not particularly useful as an absolute requirement for
defeating SPAM.
Systems are often in transition from compromised to cleaned. As such,
effective SPAM mitigation MUST be responsive, either by actions of
reputation services, or by resource administrators. A responsive
resource administrator represents by far the most effective actor in
SPAM mitigation.
> SPF failures say little about an SMTP client.
They may or may not say something about the client in and of itself
but they do say something about the relationship of the SMTP client
to the purported Mail From domain when a well constructed SPF record
ends in a -ALL
An "-all" suffix means what? Should MTAs refuse a message that fails a
check that may require 111 transactions to verify? An SMTP client
issuing a message by properly carrying forward the Return-Path to ensure
email delivery integrity may cause this check to fail and has done
nothing wrong!
> DKIM failures also say little about the SMTP client because either
> mechanism MUST be allowed to fail to retain email delivery
> integrity.
A purist always brings a smile to my face. I know quite a few folks
at large receivers who would disagree with your "MUST".
Are you saying that all SPF failures MAY be refused?
What they
are concerned about is ensuring the delivery integrity of mail their
users want. As far as delivery integrity of mail their users don't
want.....not so much. And that includes marketing emails their users
don't want. The issue for them is not generic email delivery
integrity but rather, how to find the sweet spot of
rejecting/blocking/discarding while minimizing (not eliminating
every single instance) performing such actions on mail their users
actually want.
Here is a truth for you. Mailbox providers will determine for
themselves what works for them irrespective of any "MUST" you seek
to impose on them. They will use standards based approaches and they
will use non-standards based approaches. They will discard mail in a
manner that offends your sensibilities. At the end of the day it is
not about you....it is about them and their relationship with their
customers.
Attempts to divine a recipient's desire has little to do with SPF. Are
you suggesting all failures be rejected, or all passes be accepted? Any
provider that hopes to meet the desires of their customers MUST look
elsewhere to determine proper message handling. For example, I have
advocated use of a third-party authorization scheme to assist with this
process.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg