ietf-mxcomp
[Top] [All Lists]

Re: when spoofing isn't

2004-03-19 11:37:33

On Fri, Mar 19, 2004 at 10:01:59AM -0800, Hallam-Baker, Phillip wrote:
For my particular domain verisign.com I want all email that does not
originate from the verisign email servers to be eliminated.

      * No Web mails
      * No postcards
      * No cartoons from Cagle
      * No unauthorized laptops sending email directly.

That is because we are in the payments and security business. I don't
want Phishing scams pretending to come from the VeriSign domain.

I don't think these are actually legit for any email address, the
message does not come from me, it comes from Cagle or whoever has
the web site. It should have their name on it, not mine.


Which don't you view as legitimate, the services you mention above, or
those services with verisign.com as the primary identity used in the
outgoing emails?


All we are doing here is listing out the edge mail servers. You can 
play whatever games you like but this is where implementers will make 
their own decisions. If they want to check 822 headers they will.


...which is fine, for people that want to have a way to authoritatively
identify a short list of allowed MTAs for a given domain.  But we
shouldn't necessarily break things for those who don't wish to or can't
o do so (e.g., MUA direct-to-recipient-MX connections).  If we are in
fact going down the path that leads to the end of MUA
direct-to-recipient-MX connections, we should acknowledge that.


Rather than telling the postcard web sites that nothing is going to 
change it would be better to tell them how to change in a way that
is going to maximize the chance their mail gets through.

That is the reason that people are putting these records up, they
want to maximize the probability that the email they source gets
through.


I was thinking about this yesterday.  The original trust model for email
is "trust everyone".  Obviously, that's led to some problems.  However,
the approach I see you taking  is changing the trust model to "trust no
one, except for [insert method here that modifies trust positively]."
We should also consider a third trust model, which would be
"trust-neutral":  Neither trust nor distrust a given piece of email,
except for [insert method here that alters trust positively or
negatively, and carry forward that trust to future interactions].


-- 
Mark C. Langston                                    Sr. Unix SysAdmin
mark(_at_)bitshift(_dot_)org                                       
mark(_at_)seti(_dot_)org
Systems & Network Admin                                SETI Institute
http://bitshift.org                               http://www.seti.org


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