On Thu, Feb 4, 2016 at 2:26 AM, Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk>
wrote:
On 03/02/2016 22:05, Brandon Long wrote:
There was a long discussion about this on mailop not that long ago, you
can see it here when you join the list:
https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2014-June/005184.html
Thanks. I've had a look at that.
Right now, there is no great solution.
The 'best' solution could be for Google to allow a user to define a
'forwarder' IP address/range... (And possibly allow forwarders to say that
they are forwarders to help Google remind users to set their 'forwarder'
settings)
Sure, and we have that for Google Apps customers, but when it comes to
consumer Gmail accounts, it would have to be per account, and it just
hasn't been a high enough priority. Kind of a 1% of 1% problem...
And that assumes that an "IP" is good enough, and not having to say use a
domains SPF records to define their full IP list dynamically (that's what
we make other services use if they want the list of Gmail's IPs, they have
to monitor _spf.google.com).
And, assuming that people don't mess up and put the wrong thing in there
and then have spam issues (we routinely have Apps customers mess up the
differences between inbound gateway, spam ip whitelists, and other things).
If there was a good mechanism we could use without user intervention, that
would be best.
Brandon
One I recommended before was to block relayed spam, and then have the
user's set up pop fetching. So, the cleanest mail should arrive quickly,
and everything else will be fetched more slowly.
The problem with setting up POP3 fetching is that it requires a massive
leap in technical ability for the user. It takes 2 seconds to set up
'forward to bob(_at_)gmail(_dot_)com' in our software. To do POP3 fetching,
they
need to set up port forwarding in firewalls, tell Google the server details
etc. They may need to change from a dynamic IP address to a static one (or
set up noip.com or whatever), and so on. So, users will stick with
forwarding despite the problems it causes for their MSP.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp