ietf-mxcomp
[Top] [All Lists]

Re: A proposal on identities

2004-04-18 23:37:57

Interesting ideas... It sounds like CID might be moving one step closer to SPF/DMP...

--Harry Katz <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:

Q2:  Why not put RFC2821 MAIL FROM as the first identity in step 2?
A:  Because that would *force* adoption of SRS.  MAIL FROM is only empty
in cases of bounce messages so we would only ever fall through and check
the other headers on bounces.   As I said above, if organizations choose
to implement SRS, that's their business, but it shouldn't be a
requirement.  Or in RFC lingo, SRS can be a MAY, but not a MUST.


While reviewing your message, I noted that you listed 2821 MAIL FROM last, and I was going to ask, since this comes first in the transaction, before DATA, why not check it first?

The answer given here sort of assumes that there will be a PASS or FAIL at any step, but not an UNKNOWN. It seems to be assuming that you may only choose one of the identities on the list and validate that. Why not validate any or all data?

More to the point, if the From: address and/or Sender: address publishes info and it checks out OK, BUT they use a different return address (MAIL FROM) and that returns a definite FAIL result, what then? Can someone create mail that bounces back to me without my permission, even with a CID seal of approval?

My initial concern with narrowing down to a small list of identities and a specific order was that some might be good for one thing and some might be good for another. If MAIL FROM and From: and Sender: (and even HELO) are all different domains, why not check each one against its published info? (Given a choice, if I have the info on each and each sending domain wishes it to be applied, I will apply it :)


Q3:  Spammers can still insert headers pointing to their own throwaway
domains that will enable them to pass the spoof check, right?   A:  True,
but senders can place the directOnly flag on their EPD to indicate that a
further validation against the recipient's safe list ought to be
performed.


For those that choose to use directOnly, it's a great thing to have. But, there are other domains that can't use it. For example, Microsoft Co. might decide to use "microsoft.com" for official communication (and make it directOnly) but if their employees send to mailing lists using <name(_at_)exchange(_dot_)microsoft(_dot_)com> then that domain can't use directOnly.

I wonder if this alternative angle might help put a different spin on things: If checking the From: address passes, this is the best case. You could label this address Direct,Verified. If you need to dip into the other headers to get a match, you could label that other match as Indirect,Verified, and hopefully make it clear to the user that this is "forwarded" mail. (This is a different angle on the non-binary nature of it all... It's not all Pass/Fail, there's also Unknown, and Indirect now too)



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


<Prev in Thread] Current Thread [Next in Thread>