X-Spam headers are generally a good thing (other than there is about 20
different headers that mean the same thing, please people standardize
[SAYS the kettle calling the pot black, we use X-MagicMail-Quarantine:
Yes] ), and if our mail servers see that the remote server has already
flagged it as spam, we treat it as spam as well..
(Would be nice to reject it during SMTP, but not really practical,
specifically for the forwarding issue, but people, if you think it is
spam, don't send it on)
On our email servers, it is recommended NOT to do that, eg only deliver
spam locally, never forward.. (they can log into the local account,
which they should be doing anyways, if they want to see the spam)
However, still occasionally, end users turn off spam protection and then
forward it to their gmail/hotmail/secondary account.. which is generally
a no-no, and we are making it more difficult for them to do that.
(In fact, we are in the camp moving towards disallowing remote forwards
altogether by end users, slowly but surely)
(Is there an email client that doesn't allow checking multiple accounts?)
And while DKIM et al, isn't our favourite philosophy, as you pointed out
hard enough (except for spammers) for organizations to get DNS or SPF
right.. In truth, SRS isn't a bad thing, makes it clear during SMTP
where the email is coming from, but remember, when you are doing SRS you
are effectively saying, this email is NOT from the sender, it is from me
(you) forwarding for the sender, and this MIGHT mean a different level
of trust... but we keep piling layer on layer, when the simplest things
deliver the biggest clout..
host -t SPF hp.com
hp.com has no SPF record
(and don't get me started on banks)
host -t SPF cibc.com
cibc.com has no SPF record
host -t TXT cibc.com
cibc.com descriptive text "MS=ms41336736"
cibc.com descriptive text "v=spf1 include:_spf.cibc.ca -all"
cibc.com descriptive text
"google-site-verification=t_PS4jE6SxxpA-lynbn-UzNWdMBaMAcM-Bw0o1ot8lM"
cibc.com descriptive text
"37xjtLcrkIXz19dsxGe6k8OzQkelOBriqt4h6oQye6pIHtY2ylONJSZ6ST2HQdFk2557dEqJ/ogjVgoZEPrDvw=="
cibc.com descriptive text
"UZG16jRyRkpLA8Q74WBafitsR47w8yax4RJEqBdgHvXMOWsHEaKWSQZIgAxCiLnK27Rp3uMSl7momkPnuSFcRg=="
host -t TXT _spf.cibc.ca
_spf.cibc.ca descriptive text "v=spf1 ip4:199.198.251.32/29
ip4:199.198.223.32/29 include:spf-00146707.pphosted.com
include:spf-00146703.pphosted.com include:spf-00146702.pphosted.com
include:performind.com -all"
host -t TXT performind.com
performind.com descriptive text "MS=ms44978057"
performind.com descriptive text "v=spf1 mx ip4:198.27.119.9
ip4:198.27.119.10 include:spf.protection.outlook.com -all"
Ummm.. yeah, that will be helpful.. (Hopefully Outlook can tell which is
real CIBC email before sending it out <sic>)
Sorry, I guess this turned into a rant..
And a little off-topic..
But, I guess the point is, why put the burden on Gmail to sort out the
forwarding issues.. Simply stop forwarding :) And for sure, stop
forwarding spam ;) If you can't do the later 100%, (and I don't think
anyone can really) then you go back to 'Stop Forwarding' :)
(oh, yeah, did I mention I live in a perfect world, where there is no
violence, people still say good morning, and spam is a breakfast meat)
Back on topic though, what I suggest is that any one who is 'forwarding'
email, might have to consider.. either forwarding with credentials
intact (original MAIL FROM:, no SRS ) which makes SMTP layer checks more
easy, and NOT forwarding DKIM signed email IF you have to rewrite the
message. Kind of defeats the purpose anyways.
Okay, done for another day.. battles resume tomorrow friends..
-- Michael --
On 16-08-16 05:15 PM, Brandon Long via mailop wrote:
On Mon, Aug 15, 2016 at 7:10 PM, John Levine <[email protected]
<mailto:[email protected]>> wrote:
>And they WANT to be able to choose whether to get spam mails tagged and
>have them delivered to their account where they can process them with
>their own filter rules and maybe report them.
Then you should deliver them to local mailboxes from which they pull
the messages using POP or IMAP. Any sort of SMTP "this is spam but
deliver it anyway" won't work since spammers can set it, too. Or do a
hybrid where you forward the stuff that has very low spam scores, so
they get it fast, and deliver everything else locally where they can
poll eventually. I have users who do that and it works pretty well.
We were debating an X-Spam header which would deliver directly to the
spam label without
using the message in our "is spam" learning. This would match what our
support pages say about
putting SPAM in the subject, which I don't think we've actually listened
to maybe ever, and without the
authentication breaking properties of touching the subject.
There is the class of spammers who seem fine with getting as much mail
as possible in the spam label,
with the assumption that enough folks will check their spam label and
click on the links anyways. We'd
probably need to have more complicated rules of when to listen to the
X-Spam header, of course.
Is there some other issues with a "deliver to spam"?
My prefered solution is to bring an "inbound gateway" setting to
consumer Gmail, but that's a lot
more complicated.
It's also possible that with ARC, you wouldn't need the SRS and we could
better learn forwarding
on a per-user basis, and so we'd just know it's a gateway.
>So how do I solve that customer need in the best possible way?
>Forwarding without some kind of SRS just does not work with all the SPF
>protected domains out there (our own domains are also SPF protected
>which cut of a lot of spam and phishing emails to our customers).
Maybe things are different in the US, but around here, I don't know
anyone who rejects on SPF failure other than a plain -all for we send
no mail at all. If you want to do phish detection, sign your mail and
use DMARC and hope your users don't subscribe to many discussion
lists.
Agreed. I have seen a couple non-US banks with a DMARC p=REJECT policy
and no DKIM signatures,
relying only on SPF. SRS won't solve that problem, though since it
won't align.
In general, Gmail won't reject based on an SPF failure (except -all),
though it can cause spam rejections
on the margins. And for Gmail, it's probably better to keep the
envelope sender the same and not use SRS.
Brandon
_______________________________________________
mailop mailing list
[email protected]
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
[email protected]
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
