Non prime number store certificates are acceptd for SMTP (25) both to and from
google.
Perhaps this is CYA to prevent compromised gmail accounts from giving
credentials from hijacked accounts to unknown servers.
I have no idea how credentials for gmails pop pickup work but perhaps having
hijac
On 1 January 2013 19:04, Keith Medcalf wrote:
> Perhaps Googles other "harvesters" and the government agents they sell or
> give user credentials to, don't work against privately (not under the
> goverment thumb) encryption keys without the surveillance state expending
> significantly more reso
On Tue, Jan 01, 2013 at 12:04:16PM -0700, Keith Medcalf wrote:
> Perhaps the cheapest way to solve this is to apply thumbscrews and have
> google require the use of co-option freindly keying material by their
> victims errr customers errr users.
ITYM "product".
- Matt
On Mon, Dec 31, 2012 at 6:07 AM, John R. Levine wrote:
> Really, this isn't hard to understand. Current SSL signers do no more
> than tie the identity of the cert to the identity of a domain name. Anyone
> who's been following the endless crisis at ICANN about bogus WHOIS knows
> that domain nam
On Tue, Jan 1, 2013 at 2:04 PM, Keith Medcalf wrote:
> Perhaps Googles other "harvesters" and the government agents they sell or
> give user credentials to, don't work against privately (not under the
> goverment thumb) encryption keys without the surveillance state expending
> significantly more
Perhaps Googles other "harvesters" and the government agents they sell or give
user credentials to, don't work against privately (not under the goverment
thumb) encryption keys without the surveillance state expending significantly
more resources.
Perhaps the cheapest way to solve this is to ap
On Mon, Dec 31, 2012 at 9:07 AM, John R. Levine wrote:
> Also keep in mind that this particular argument is about the certs used to
> submit mail to Gmail, which requires a separate SMTP AUTH within the SSL
> session before you can send any mail. This isn't belt and suspenders, this
> is belt and
* Job Snijders:
> In the meantime you could consider setting up an irrd[1], redirect
> queries to that instance instead of whois.ripe.net, and keep it kind
> of fresh by feeding it ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz on a
> daily basis.
RIPE NCC strips all contact information from the bulk e
8 matches
Mail list logo