ietf-mxcomp
[Top] [All Lists]

Re: What to check? (was Re: Caller ID and ease of adoption

2004-05-13 13:25:48

<an old post that never made it to the list>

On Tue, 13 Apr 2004 01:08:15 -0700, "Greg Connor" 
<gconnor(_at_)nekodojo(_dot_)org> said:


--Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:

> Whaddya think of my fledgling idea for a solution to this problem
> ("Strong From: check seems possible")?


I read it but didn't reply. My quick initial read on it is that it's depending heavily on a third-party BL or WL... [as] with no BL or WL, unscrupulous mailers could fake the SRS (not even fake it, just accept forged mail and use SRS as normal) and pass themselves off as forwarders of known-good mail. A WL would work... basically you are stating you trust another forwarder to do the proper checks for you, but you wouldn't want to upgrade something to a "confirmed good" status if the forwarder just had "unknown" and passed it along.

Yes, this was explicit, and while BL and WL are imperfect, we're struggling with a hard problem and they're among the best tools we have, part of most effective anti-spam systems, and clearly part of SPF, at least in my view and in terms of spf.pobox.com, if not the I-D itself. Thanks for the feedback. I was particularly directing my question at Harry, but welcome your and others feedback.


Now, it also seemed like Meng's previous message about different
"classes" of mail was a really good idea. What were people's reactions to that?

I agreed with it, particularly the fact that we should be making rules that if met bump mail up a class or two, and others that if not met bump mail down a class or two. It's like my "how do we tighten the noose enough", but with a much better analogy.



It's an unfortunate fact that on mailing lists, good ideas attract less response than bad ideas.

Folks read a post with a good idea, say to themselves "wow, good idea", and move on, and are more likely to respond to bad ideas.

I keep thinking about how to solve the problem; I certainly would be interested in a forum designed to address this and generally improve the S/N ratio. A slashcode-based forum, or something like that... It's hard to interpret silence as approval or disapproval. Something more powerful than IETF+Censored. slashcode allows decent filtering without an unreasonable amount of overhead. Perhaps the next ASRG spin-off could use such a forum to complement (and hopefully folks would like it and it would largely replace) the usual mailing list. It would send mailings to folks whenever messages were posted, but they would be read on a website.



I've been feeling that we're actually in agreement on this groups first task: nearly all of us seem to concede that there are good reasons to look at both 2821 and 2822 headers, even though most of us also continue to criticize each other's posts, pointing out important but smaller points.



Basically, we know that the From: address will not always match up with
the MTA that gave it to us. But, if it DOES check out ok, that is VERY valuable information. Hence, a From: line that by itself passes the LMAP test can be given a status of "Confirmed, Direct". (As an extreme case, some senders may declare that they will always send direct and any list-type forwarding is disallowed. Most domains won't use this but some might)

And I discovered (or noted) that SRS can be used to make more From: lines pass the LMAP test, and with BL/WLs, it seems that ALL From: lines in non-spam can pass an LMAP test.



For something that was relayed to us from a list, the best we can do is confirm that the MTA is authorized for that list. In those cases Sender: probably matches up, and we can mark the message as "Confirmed, List or Remailer". We can't really trust the From: in this case unless we check the data provided by the listserver (and we trust that listserver to check correctly).

Building on Meng's class system, perhaps it would be reasonable from a UI standpoint to have such mail go into either a Verified Opt-in folder or a folder for other mailing list mail. The MUA could monitor outgoing confirmation emails or url clicks to auto-populate a list of mailing lists the user wants to be on. A standard format for confirmation emails could make this blue sky idea real. Not the focus of what I want to work on personally; anyone want to take the idea further? Has it been done already?


The same actually applies to greeting cards or mail-this-article services... the From: check is unknown or failed, and the best you can hope for is something that says "relay source confirmed, but no information on original author."

Stuff where the From: and Sender: checks both fail or cannot be checked
is sort of "third class" in this model.




Harry Katz said:

SRS creates addresses that are not intelligible to humans.

SRS creates addresses that are readily converted to a form that's intelligible to humans. One strips the hash and timestamp and prettyprints to make something like "From ann(_at_)orig(_dot_)com via bob(_at_)alias(_dot_)com". SRS could easily have a section that suggests that SRS MAIL FROMs SHOULD be displayed in a specified format in MUAs if they are going to be displayed.


<Prev in Thread] Current Thread [Next in Thread>
  • Re: What to check? (was Re: Caller ID and ease of adoption, Matthew Elvey <=