Re: [Asrg] Soundness of silence

Bill Cole wrote:
> Different people (and mail systems) have different spam problems.
I tend to understand that as different classes of spam. For an 
example, consider a creditor of mines who solicits payment by sending 
me reminders. Assume I'm not going to pay and I just discard them. If, 
by chance, they end up in the spam folder, would I be willing to train 
my Bayesian filter to avoid that? Probably no. And, are those 
reminders spam? In some acceptation of the term, yes. Thus, a fax or a 
registered letter is better than email...
> Many people have come up with  "good enough" solutions for their own 
> spam problems, but they are no all the same solutions. The idea that 
> there is or could be one solution that works for everyone has largely 
> fallen into disrepute because all of the attempts at it have fallen far 
> short of the goal. Unfortunately, many of the de facto best current 
> practices are completely unsuited for technical standardization. I don't 
> think anyone wants to see any sort of RFC that recommends using any 
> specific DNSBL, but for many people running mail systems of a wide 
> variety the use of the Spamhaus Zen DNSBL is their most effective single 
> anti-spam tactic. Recommending the shunning of specific whole countries 
> certainly does not belong in anything that anyone might see as a 
> "standard" but as a matter of practicality, many mail systems do so to 
> great benefit and at no tangible cost.
I don't see why such techniques are not amenable to standardization. 
Actually, there is a couple of DNSBL drafts that are slowly moving 
forward.
It should be possible for my SMTP server to accept mail only from, 
say, an office opposite with whom I do most business, and shunning all 
the rest except, say, Gmail, thereby relying on their filtering. 
There's nothing wrong with that, except for technical problems that 
make it difficult to set it up properly.
> Because spam is fundamentally a social problem rather than a technical 
> problem, the technical approaches to fixing it are all imperfect, many 
> subsets are subject to "arms race" problems, and the only generalizable 
> solution is that everyone running a mail system should apply a mix of 
> tactics suited to their spam and their non-spam (based on the locally 
> relevant definition of "spam") and pay attention to how those tactics 
> work *for them* rather than seek to locally deploy some global solution.
Yes, that's the conclusion I also reached. Spam is a universal plague 
and we must live with it. It is indecent to egoistically take oneself 
away from it. Therefore, solutions to get rid of spam are not wanted, 
not even discussed. BTW, discussion implies that someone will try to 
also get rid of direct marketing, in the bargain. So, let's keep all 
of it, even the inadmissible zombie-generated spam.
> > In particular, I'm puzzled as to why I got no answer to my yesterday's
> > message. A previous message by Amir, DNS-based Email Sender
> > Authentication Mechanisms: a Critical Review, had several responses.
> You should keep in mind that the short-term level of response here to an 
> idea is going to be somewhat inversely related to how well it is 
> reasoned and presented. I think if you look at the nature of the early 
> responses to that post you will find that the first day was dominated by 
> people complaining about the manner of presentation.
Someone suggested I should also have posted an URL. Those are just 
practical issues.
> > * Because nobody is interested in the subject.
> > Already ruled out: it is the same subject of Amir's paper (rDNS, SPF,
> > DKIM, and the like.) How come nobody is interested?
> It's not the same. It's an actual new idea rather than a rehash/critique 
> of existing tools. Many people here have already thought about (and in 
> some cases used) the various MARID tactics. It does not take a lot of 
> new thought to throw the same old rocks at their pet targets, but it 
> does require new careful thought to discuss a new idea.
That's partially correct. OTOH, it is just a mashup of those same 
existing tools, providing a framework for letting senders know.
> I also think that the difference in media is important. An I-D is 
> presumably intended as a step towards a RFC, and people here ought to 
> understand that public discussions of I-D's should be done carefully.
Being an I-D _and_ a proposed solution emphasize each other, 
conflicting with the universal plague requirement above. However, it 
is also important to reach some form of agreed failure diagnosis. 
Question 12 in http://asrg.sp.am/about/faq.shtml is just too generic.
> Your proposal is complex enough that making a careful analysis takes 
> real effort. A casual scan of the document doesn't yield obvious fatal 
> flaws, nor does it provide any instant 'AHA!' response of how the VHLO 
> mechanism would provide a clear fix for a major problem. That results in 
> it seeming like a low-yield chore to go through 23 pages of details to 
> figure out whether this idea is sound and useful. Maybe improving 
> sections 1.1-1.3 to more directly and concisely define the problem VHLO 
> is meant to address would encourage more attention.
That's what I've been trying to do in the last two rounds. Any 
explicit hint?
> If I understand it correctly, the problem VHLO is trying to address is 
> that sending and receiving sides may not always agree on which name(s) 
> to use in application of which DNS-based authentication and 
> authorization schemes and how strongly the results of those schemes 
> should be interpreted as the name owner vouching for the non-spam 
> quality of the messages involved. This tends to force receivers into 
> complex scoring of their DNS-based and content-based filtering, making 
> deliverability for legitimate senders highly uncertain and opaque.
Yes, the overall idea is simply to allow whitelisted ("first-class"?) 
delivery for senders who ask for it, and are eligible. Eligibility 
criteria already exists, based on those DNS techniques. VHLO is mainly 
meant for those servers who already implement various forms of 
whitelisting.
For example, Spamhaus lookup, when used to reject, usually gives a 
clear response as to why rejection occurred, both to end user and log 
files. However, DNSBLs used for scoring, as well as positive listings 
and vouching, that lead a server to accept messages with suspicion, is 
highly uncertain and opaque, as you say.
> If I understand it correctly, you are proposing that VHLO be used to 
> address that problem by providing a way for a SMTP sending system to 
> provide the names, schemes, and strengths that should be used for all 
> messages in a particular VHLO session. This allows receivers to layer 
> DNS-based mechanisms as absolute criteria ahead of expensive and fuzzy 
> content filters, instead of using them (as is common in tools like 
> SpamAssassin) as scored criteria in a large collection of other 
> similarly imperfect scored criteria.
Correct. And also feedback, without which a sender cannot know which 
vouching services would provide which benefits.
> Of course, I may just be projecting my own ideas about spam control onto 
> a very quick scan of your draft in full attention-deficit mode, and I 
> don't have any opinion on whether the mechanical details you define will 
> do the job that I think you want done.
Some mechanical details may need to be amended/discussed, in case.

> More telling: I'm not convinced that any new technical approach to spam 
> control has any chance of widespread adoption or even careful attention. 
> The jungle of existing tactics combined with a drop in user expectations 
> has resulted in a circumstance where the demand for better mail service 
> is not enough to get significant new technical approaches deployed.
Great! I cannot tell it better than that. It obviously implies that 
email is going to die out. Newcomers don't perceive it as something 
new and exciting, but rather as an obsolete communication system used 
predominantly by elder people, generally left in a state of 
regrettable neglect.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg