ietf-mxcomp
[Top] [All Lists]

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

2004-04-13 01:08:16

--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... otherwise 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 that you trust another forwarder to do the proper checks for you, but you would not want to upgrade something to a "confirmed good" status if the forwarder just had "unknown" and passed it along.


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?

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)

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).

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.


--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>