Re: [dmarc-ietf] Cataloging MLM manipulations of messages
On 9/23/2014 10:09 AM, Stephen J. Turnbull wrote: I suspect such a thing will quickly become obsolete. I'm sure it will. The point is that I think it can have utility to get folks thinking in terms of a potentially wide /range/ of choice, with the document giving a snapshot in time of choices that have been made. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] yet more From rewriting,
Steven M Jones writes: On 09/22/2014 03:17 PM, Josh Aberant wrote: Who uses X-Original-From ? This is a real question, I'm not aware of anyone who does. At Twitter we use the X-Original-From to route our security tickets with users within our ticketing system Salesforce. Users can open and reply to tickets by emailing what is a Google Groups alias. Google Groups (takes ownership of the From per our #RejectPolicy) and then I don't understand our #RejectPolicy. What are you talking about? Surely not DMARC? That reject policy would be related to the From Domain of the user, not anything about Twitter. Or do users use an @twitter address for email they send? forwards those emails to Salesforce where they are automatically turned into support tix where we key off of the user's email address in the X-Original-From header. Interesting use case. Presumably the messages are flowing from Google Groups to Salesforce over the Internet. So what we have is SMTP SMTP Customer (Author) --- Google Group (Mediator) --- Twitter (Destination) right? However I would consider everything that happens after Salesforce receives the messages as an application workflow. Indeed. But as long as these message don't leave the Twitter workflow, I'd consider all of this a private protocol that isn't really any of the IETF's business. Messages the customer sees would be in-scope; Not if they don't go back through the Google Group. Nothing so far suggests that they do, and the word security suggests that they do not, to me anyway. I'm not so sure about things happening between Google Groups and Salesforce, In scope. or within Salesforce. Not. If we consider all the ways email messages are spindled, folded and mutilated when they become part of an application workflow, I expect we'd see an absolute explosion of additional weirdness... Not our business, though. Some of the specific mutilations may be, but the whole collection surely is not. We would consider specific instances case-by-case. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] yet more From rewriting,
On 09/23/2014 10:26 AM, Stephen J. Turnbull wrote: On 09/22/2014 03:17 PM, Josh Aberant wrote: alias. Google Groups (takes ownership of the From per our #RejectPolicy) and then I don't understand our #RejectPolicy. What are you talking about? Surely not DMARC? That reject policy would be related to the From Domain of the user, not anything about Twitter. My reading was that this was some kind of configuration item within Google Groups. Therefore it's interesting if it is a normally available feature that any Google Group might use to alter the RFC5322.From or add an X-Original-From: header. Josh, anybody, feel free to correct/amplify... --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] yet more From rewriting,
Brandon Long writes: In any case, support folks, especially when dealing with paying customers, tend to want to get all of the email, they don't want their nicely paying customers to not get support just because of spam false positives or the mail routing breaking dkim. Sure, but this isn't a problem if the support site ignores p=reject or treats it as p=quarantine. I think this is a twitter-side problem, not a Google-side problem or IETF problem. The recipient MUST reject aspect of DMARC is broken as far as I'm concerned. I personally consider p=reject to be informational, with preferred recipient semantics of as far as we're concerned you can black-hole this message, and for your own good you probably should if you don't have *very* good reason to do otherwise *and* your own strong defenses against inauthentic mail. Support staff also can be trained not to get phished (is that really even necessary?) Presumably the remaining problem here would be the amount of inauthentic mail that gets through. Yahoo! admins speak of millions of messages per minute, which I find entirely plausible, and it certainly would knock down not just my tiny host, but probably my employer's whole network. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage
On September 23, 2014 8:22:41 PM EDT, Stephen J. Turnbull step...@xemacs.org wrote: Brandon Long writes: Sorry, they often term the messages as notifications instead of posts, when they actually contain the full post and author information/etc. I guess I'd need to see one to decide how I would classify them and how they fit into this WG as use cases. Examples? The only thing I can think of that fits that description is a bug tracker, and there the message is usually only one component of the information conveyed, and often is missing. In that case I would consider the actual message to be encapsulated in the outer message as delivered by the service, similar to the way I quoted you above -- this message is *from* me, *quoting* you. (Note that some authors/MUAs using a quoting style that looks much like RFC 822 headers, increasing the similarity.) I would consider that mode of operation to be deficient in a discussion list. I don't recall commercial service Groups using that mode, though -- they always have the author in From IIRC. Except at the very least Google Groups. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage
Scott Kitterman writes: On September 23, 2014 8:22:41 PM EDT, Stephen J. Turnbull step...@xemacs.org wrote: I don't recall commercial service Groups using that mode, though -- they always have the author in From IIRC. Except at the very least Google Groups. If you are talking about their workaround for DMARC p=reject From Domains, that's irrelevant to my point. This subthread was discussing how modern lists/bbses/forums have evolved over time. What I am saying is that in the absence of DMARC p=reject at public mailbox providers, as far as I know Google Groups and Yahoo Groups normally put the poster's name and address in the From field. This is 100% confirmed by a sample of nearly 100 of my personal archives of GG and YG mailing lists.[1] If you have a counterexample, I'd love to hear about it, in enough detail to determine whether the From-munging was done with at least implicit authorization by the posters. Eg, subscribing to an anonymous mailing list described as such on its information page constitutes implicit authorization. Posting to a list which changed to from-munging as a DMARC mitigation, without an explicit announcement of this ToS change, is not. Footnotes: [1] As it turns out, my GG lists have *zero* Yahoo and AOL posters, and my YG lists most recent post was 2008/8/12, so mostly irrelevant to recent policy. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
