On 5/22/2017 1:31 PM, valdis.kletni...@vt.edu wrote:
On Mon, 22 May 2017 13:21:08 -0700, W Kern said:
Then it's your fault for *accepting* the spam/virus that ended up getting
forwarded.
We quarantine inbound SPF failures. Customers complain but we point that
out. So those are not the issue.
I am talking about the scenario where a third party sender WITH an -all
SPF record sends to my customer and then MY customer forwards it
elsewhere (gmail, hotmail).
From our server's perspective it is a legitimate acceptance and no SPF
failure occurred. Of course we are going to accept it.
But unless we REWRITE it then when we forward back out its an SPF
failure at the forwarding destination, and where we have tried rewriting
we have seen pushback and technical issues.
I suppose we could write something unique and refuse to forward such
emails, but the standard software doesn't accommodate that as of yet.
As far as us forwarding spam/virus, if you know a perfect anti-virus
and spam filter that exactly matches the 'customers' expectation of
what spam is versus their email provider, I am all ears.
I have seen situations where customers have loosened up their quarantine
rules and then they expect gmail,hotmail to catch the spam (and blame
us). We are trying to crack down on that but again the systems aren't
yet in place.
Our solution has been to try to force them to pop/imap off their email
accounts rather than forward in general. As Michael pointed out that is
much more reliable anyway and helps keep our systems off somebodies
spammer list.
The rest of your commentary isn't related to the specific point being
discussed - SPF in the context of forwarding, such as this:
or when their customers Website is delivering transactional
email but the customer didn't alter their SPF record to include the
webserver.
Its similar to forwarding and the problem of people not understanding
correct SPF records, so therefore some have an assertion on this thread
that we should all ignore them, so that things like 'old school'
forwarding still work.
-bill
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
