On Nov 5, 2014, at 10:35 AM, Terry Zink <tz...@exchange.microsoft.com> wrote:
>> Since SPF authorizes an often _shared_ outbound IP address, it has been >> accurately described >> as an authorization method. DMaRC permits a DKIM signature to be spoofed >> and still allow >> a message to be accepted solely on the basis of SPF. What magic turns >> authorization into >> authentication??? > > This is a good point and I can share some of our own experiences in > Microsoft's Office 365. > > We have a hosted service. Companies/users can either have hosted email > accounts wherein they login to the portal and send/receive email, or connect > to it via IMAP/POP3. The second option is an on-premise environment wherein > their email passes through us and we relay it to their on-premise machines. > They can send outbound email through us by connecting to the service by > specifying their outbound IP in a "Connector". > > We ask customers to add our service's SPF record to their own SPF records. > When they send outbound email through us, it will authenticate at the > destination. However, if Customer A ever spoofs Customer B, it will also > authenticate via SPF. This is a very real problem. > > So how are we fixing it? > > First, hosted email accounts cannot spoof another customer. If you login to > the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM > domain. You have to set it up in the portal and put a key into your TXT > record. That's not changeable. > > Second, for on-premise machines, they *can* spoof another customer. If they > connect over their IP, if the domain they connect with is not provisioned > with them, it is attributed to a "safe tenant" (a misnomer in my opinion). It > is here that they could spoof someone else. To get around this, we will check > DMARC on outbound mail before we relay it out. Dear Terry, What role does DMaRC play in a scheme that relies on the special TXT key you mentioned? If so, is this really even describing DMaRC? > If a domain fails DMARC when it connects to us, and it is an outbound email > intended for the rest of the Internet, we will reject the message so it > cannot be sent out to an unsuspecting third party that might pass SPF since > it came from our service's outbound IPs. Could this satisfy Intuit should their customers make use your services and assert p=reject? > This is not a perfect solution, but it does close a gap. The existing DMARC > specification lets us do this without making any changes to it. How would this help resolve third-party issues the WG should be attempting to address? While these efforts in your service are commendable, how does this help address the fact that the base draft is misleading and is using definitions that will be problematic when resolving third-party issues through use of hopefully open protocol extensions. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
