On Thu, Sep 10, 2015 at 1:42 PM, Gil Bahat <g...@magisto.com> wrote: > > > On Thu, Sep 10, 2015 at 11:29 PM, Brandon Long <bl...@google.com> wrote: > >> >> >> On Thu, Sep 10, 2015 at 6:50 AM, John Levine <jo...@taugh.com> wrote: >> >>> >Does anyone understand SRS? I thought it was pretty much a dead end. >>> >>> It dates from the magic bullet phase of SPF, so yeah. >>> >>> >The reason we rewrite is so that bounces come back to us so we can >>> >automatically disable forwarding if the account we're forwarding to goes >>> >away. >>> >>> Well, actually, you're doing SRS with different syntax. Local bounce >>> management is one of the few things it does successfully. The >>> original plan was that you'd forward the bounces back which >>> unsurprisingly turned out not to be a great idea. >>> >> >> Sure, I guess I view all of these as descendents from VERPS, but I guess >> that comes from spending so much time in the mailing list space. >> >> >>> >Which reminds me, I need to ping the spam folks again, that page is >>> still >>> >recommending putting SPAM in the subject, which breaks dkim, which is >>> the >>> >last thing you should do. I think we're going to support an X-Spam >>> header >>> >instead... except of course that's a violation of RFC 6648. Anyone >>> want to >>> >recommend a generic header name? >>> >>> Please use X-Spam-Status: which is what Spamassassin adds, and I think >>> several other filter packages. If you parse RFC 6648 carefully, >>> you'll see that while it tells you not to invent any new X- headers, >>> it says it's OK to keep using the ones that already exist. >>> >> >> Sure, that may make the most sense. We do usually expose the phishing >> status of the message as well, but I guess that can just be a different >> header for forwarding. >> > > It would be most appreciated if you'd populate it on ingress to begin with > and not just when forwarding. it's easier to ask a user which reported an > incident when a mail landed in spam to forward it, rather than ask them to > try to locate the spam reasoning bar in their UI (if it's present at all, > assuming they don't use an MUA, etc...). > many providers and anti-spam packages do that (cloudmark, cyren to name > two off the top of my head), I haven't seen any ill effects to it and the > support benefit is extremely handy. It would also allow third party MUAs to > parse and display this data. > > Are there any good reasons not do so? I am trying to think of the cons and > I can't come up with anything really good. >
hmm. It might confuse some folks who don't normally look at the headers and are surprised because they marked it as not-spam, but that's probably not enough reason not to. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
