I think both Y!Groups and Google Groups have separate handling of mail
moderated for spam reasons, not sure how easy that would be to set up with
mailman. That way, you can say only digest the spam ones, while forwarding
the regular ones.
Agreed, the best bet is to do more smtp time blocking, so
:54 PM, Michelle Sullivan miche...@sorbs.net wrote:
Brandon Long wrote:
On Fri, Jun 26, 2015 at 11:53 AM, Carl Byington c...@five-ten-sg.com
mailto:c...@five-ten-sg.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 2015-06-25 at 13:25 -0700, Brandon Long
On Fri, Jun 26, 2015 at 11:53 AM, Carl Byington c...@five-ten-sg.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 2015-06-25 at 13:25 -0700, Brandon Long wrote:
We haven't implemented it yet, though we expect to in the near future.
Does this mean that google
On Wed, Jun 17, 2015 at 10:29 AM, John Levine jo...@taugh.com wrote:
I think I remember a rule that says that delivery to a domain's
A record SHOULD NOT happen, if an MX exists.
Does that kind of rule really exists ? Or do I mis-remember ?
You misremember. It's MUST NOT. Unfortunately,
I would imagine that list-id or list-unsubscribe would allow for
discrimination by the type of mail sent by a sender. Ie, a host like
Google Groups or Yahoo Groups has millions of different silos, and it would
make sense to treat those differently.
And we definitely combine signals in multiple
On Mon, Jun 29, 2015 at 1:48 PM, Michelle Sullivan miche...@sorbs.net
wrote:
Brandon Long wrote:
On Fri, Jun 26, 2015 at 7:03 PM, Michelle Sullivan miche...@sorbs.net
mailto:miche...@sorbs.net wrote:
Sure SMTP can have the lowest common denominator, but I thought
You are using two different names there, ie: mail-wm0-f46.google.com and
mail-wg0-f46.google.com. It looks like the wg address used to map to the
same IP.
It looks like we turned down one cluster and turned up another, and moved
the IPs across. It's possible there was some overlap between the
There's magic sauce to try and split hairs, and it's not perfect.
Brandon
On Thu, Sep 3, 2015 at 3:21 PM, Jim Popovitch wrote:
> On Thu, Sep 3, 2015 at 5:57 PM, Franck Martin
> wrote:
> > or Google...
> >
>
> Guess what, Google allows their DMARC'ed
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:
>>
>>
On Mon, Dec 14, 2015 at 6:01 AM, Ian Eiloart wrote:
>
> > On 14 Dec 2015, at 08:06, David Hofstee wrote:
> >
> > I am not confusing them. That would be weird.
> >
> > I am saying, to Brandon FWIW, that their users may be a little bit like
> our customers
On Thu, Feb 4, 2016 at 9:13 AM, Andreas Schamanek wrote:
>
> On Thu, 4 Feb 2016, at 08:19, Franck Martin wrote:
>
> > Have you considered that may be it is not postfix sending these
> > emails from your IP?
>
> Yes, of course. This particular server is not even
On Thu, Feb 4, 2016 at 12:17 PM, Franck Martin wrote:
> Neil,
>
> it is even surprising it gets delivered at all...
>
*whistling*
Yeah, I added a personal filter for my account, if list:mailop never spam.
I'm sure ARC will solve all our troubles.
Brandon
It is rather
On Wed, Feb 3, 2016 at 8:47 AM, John Levine wrote:
> >This is more of a mailop question than an ietf-smtp question.
> >
> >https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> Agreed, see reply to.
>
> >Read this: https://support.google.com/a/answer/175365?hl=en
>
>
This throttle seems excessive, even though it's only temporary. I've filed
a bug against our spam team to take a look.
Brandon
On Fri, Jun 3, 2016 at 4:30 AM, wrote:
> Hi,
>
> I'm currently seeing only this error
>
> 421-4.7.0 Our system has detected an unusual rate
Why rotate keys that often?
And why pull the public one if you do?
Brandon
On Jun 10, 2016 3:59 PM, "Ted Cooper" wrote:
> On 11/06/16 05:02, Michael Wise via mailop wrote:
> > Well, the From: domain would be a good start.
> >
> > It would certainly cut down on the
On Fri, Jun 10, 2016 at 12:05 PM, Hugo Slabbert
wrote:
> On Fri 2016-Jun-10 12:32:20 -0600, Tim Starr wrote:
>
>>
>> I am not saying this is a good idea, but it sounds to me like what would
>> fit the bill here would be a new folder for each user
I would argue something differently: many email users (and postal mail, for
that matter), have an expectation that email is mostly but not 100%
reliable, due to spam false positives or just the lack of delivery
notification.
People can then choose to not respond to a message and later claim they
er in strange ways.
>
> Geoff
>
>
>
> On 06/15/2016 06:16 AM, Brandon Long via mailop wrote:
>
> So, we've been doing dmarc rejects for many years, for Yahoo.com since
> they went p=reject two years ago.
>
> We may sometimes override the rejection, but no on
So, we've been doing dmarc rejects for many years, for Yahoo.com since they
went p=reject two years ago.
We may sometimes override the rejection, but no one should rely on that.
I don't know of anything that has changed recently about this.
Forwarding doesn't break with this unless you modify
Yes, there is.
Brandon
On Mon, Jun 20, 2016 at 2:12 PM, Brett Schenker
wrote:
> Having some delivery issues with Google for a new sister company of
> ours that focuses on nonprofits and was wondering if there was anyone
> here from Google that might help me out.
>
>
In the simplest cases, potentially yes. I think there was one suggestion
on one of the dmarc lists of having an encoded diff result in a header,
allowing you to reverse it.
It doesn't help as much for removals, especially lists that remove entire
attachments or parts. I mean, you could still
SSL3 was a small fraction of our traffic, tls1.0 is not a small fraction.
Could be because of this Apple issue, but it's also true for server to
server traffic.
I haven't investigated what doesn't support better yet, perhaps our tls
team has.
Note our post says supporting tls1.2 is necessary to
I should point out that "typical" greylisting doesn't work well with Gmail,
since there is no guarantee that the retries will be performed from the
same IP address... in fact, the chances are really high that it's from a
different one.
By typical, I mean based on any tuple which includes IP.
We
On Wed, Feb 10, 2016 at 10:40 AM, Marc Perkel
wrote:
> Been having a lot of email delayed going into Google servers.
>
> Our system has detected an unusual rate of\n421-4.7.0 unsolicited mail
> originating from your IP address. To protect our\n421-4.7.0 users from
>
On Wed, Apr 6, 2016 at 12:52 PM, G. Miliotis
wrote:
> On 6/4/2016 20:27, Vick Khera wrote:
>
>> I use google groups for those things. You can have as many of those as
>> you like, and they can be configured as shared mailboxes or even a simple
>> ticketing system.
>>
>
of these features.
Brandon
On Apr 5, 2016 1:38 AM, "Dave Holland" <d...@biff.org.uk> wrote:
> On 2 April 2016 at 00:59, Brandon Long via mailop <mailop@mailop.org>
> wrote:
> > Google Apps admins can specify incoming gateways, and we will treat the
> mail
>
counts for other purposes and I
> just can't justify paying for each of them.
>
> Instead, I just keep Gmail disabled and only use the features that aren't
> hobbled.
>
> On 2016-04-05 11:44, Brandon Long via mailop wrote:
>
>> I know I'm paying for full Google apps for m
g an SPF record fix the issue?
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
> <http://www.microsoft.com/en-us/download/
Hmm, I thought the new server went out with the updated error messages.
Ah, the change missed the release cut-off, so it'll be fixed next week.
That error message is not correct, it means the mail we're seeing isn't
authenticated and something else about the connection or message is
suspicious.
Google groups mostly does verps style addressing for the reasons that Steve
mentions. We added support for not doing it for apps domains going to
internal addresses, but mostly that doesn't work any more since we split
deliveries since each recipient may have different policies applied to it,
and
Big companies are big, never underestimate the challenges involved. We
recently went through ours to find out that the editors had drifted the
content of several of the links we pointed to in smtp responses to the
point where they were not relevant at all. At least they all still
existed, or
ugh, you're hitting a different known issue, I'll file a bug. it's
complicated.
Brandon
On Wed, Apr 27, 2016 at 4:04 PM, Robert Guthrie wrote:
> Hi List,
>
> Just wanted to check in and see if there is anything else I can do to get
> emails to arrive immediately rather
n allowing
some shady things and there can be leaks between anti-abuse systems at
Google.
Brandon
On Wed, Apr 27, 2016 at 5:26 PM, Brandon Long <bl...@google.com> wrote:
> ugh, you're hitting a different known issue, I'll file a bug. it's
> complicated.
>
> Brandon
>
> On We
Well, the first 5, for now. We can always raise that, but haven't seen a
need yet.
Brandon
On May 20, 2016 1:54 PM, "Michael Rathbun" wrote:
> On Fri, 20 May 2016 16:36:48 -0400, Jim Popovitch
> wrote:
>
> >> Anyone flagging multiple signatures as problematic
.
Brandon
On May 17, 2016 7:37 AM, "Al Iverson" <aiver...@spamresource.com> wrote:
> On Tue, May 17, 2016 at 9:27 AM, Al Iverson <aiver...@spamresource.com>
> wrote:
> > On Mon, May 16, 2016 at 6:07 PM, Brandon Long via mailop
> > <mailop@mailop.org> wrote:
&g
I can be a go between.
Brandon
On May 17, 2016 9:48 AM, "Marc Perkel" wrote:
> Does anyone have a contact email for Google's spam filtering team?
>
> --
> Marc Perkel - Sales/Support
> supp...@junkemailfilter.com
> http://www.junkemailfilter.com
> Junk Email Filter
All of our mx hostnames are in the SAN for the cert, so any mx hostname
should be fine. There is no change to that with this change.
Brandon
On May 17, 2016 8:53 AM, "Jeremy Harris" <j...@wizmail.org> wrote:
> On 17/05/16 00:07, Brandon Long via mailop wrote:
> > As an
What, you don't want to trust all of Apple's /8?
Anyways, adding spf for an entire cloud provider of generic tools seems
like a really bad idea. We have to make sure with ours that we don't let
people cross domain forge, since they may then spf pass... If you don't
control the software, it is
We don't just run reputation on IP addresses, the spammer killed the
reputation of any associated domains and such. Your domain is recovering,
but it can take up to 30 days to fully recover sometimes longer if
people don't mark your mail as not spam.
Though, that's only for the domain you're
Yes, I need details to be able to investigate.
Yes, some throttles apply to netblocks, but I should point out that
throttles are not "just" a netblock or "just" an IP or domain, we have
hundreds of different throttles depending on many features, and good enough
reputation will exempt you from
On Wed, Apr 13, 2016 at 12:45 PM, G. Miliotis <corf...@elementality.org>
wrote:
> On 13/4/2016 22:28, Brandon Long via mailop wrote:
>
>> if you have sufficient volume and your mail authenticates and you keep
>> the same authentication when switching IPs, then your reput
mething like that.
>
> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of G. Miliotis
> Sent: Wednesday, April 13, 2016 2:45 PM
> To: mailop@mailop.org
> Subject: Re: [mailop] How long does an IP address take to "Warm up"?
>
> On 13/4/2016 22:28,
If the server is saying your client connection is verify=FAIL/NO, I would
imagine that means either you have a client certificate that doesn't
verify, or you don't have a client certificate the remote server is being
pedantic about it.
Brandon
On Wed, Apr 13, 2016 at 2:56 PM, Robert Guthrie
We're definitely seeing dkim replay attacks and of course doing our best to
catch them.
I'm sure they have some knock on affects to the service being abused, and
of course we'll watch for it and adjust as we need to.
Most likely, the most negative consequences will be on forwarding email yet
Doesn't it also make it harder to do spam detected unless you follow the
links?
Brandon
On Aug 13, 2016 9:18 AM, "Bill Cole"
wrote:
> On 12 Aug 2016, at 19:12, Tim Starr wrote:
>
> The only benefit I can see from sending the exact same message from
>>
; 553 56 0.1
> > 500 6 0.0
> > 551 4 0.0
> > 421 3 0.0
> >
> >
> > About 93% are 5xy. Funny how email cannot effectively standardize on
> > return codes in such simple cases. Yours,
> >
> >
> > David Hofstee
People assume click tracking, at the least.
It's not clear that it would help, anyways, the point of these attacks is
use them against another service, you might get some feedback but probably
not fast enough to matter, just like the per user dkim selector.
Brandon
On Aug 15, 2016 9:22 AM, "Tim
I'm not sure what they're supposed to do.
If they give you the information, they're giving you information that's not
yours, which is clearly a violation of privacy.
If you have access to the email address, and you use that to get access to
data that's not yours, then you're the one doing the
hout
>
> Sent from my iPhone
>
> On Aug 16, 2016, at 6:26 PM, Brandon Long via mailop <mailop@mailop.org>
> wrote:
>
> I'm not sure what they're supposed to do.
>
> If they give you the information, they're giving you information that's
> not yours, which
On Mon, Aug 15, 2016 at 7:10 PM, John Levine 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
On Sun, Feb 5, 2017 at 2:44 AM, Klaus Ethgen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Sa den 4. Feb 2017 um 18:55 schrieb Andreas Schamanek:
> [One who witlessly blocks all hetzner IPs]
> > > I host lua-l, a large mailing list both in terms of
If you send them to me, I can forward them on
On Jan 24, 2017 9:07 AM, "Stefan Haunß" wrote:
> Hey there,
>
> anyone knows a way to bulk report abusive goo.gl links?
> the form on https://goo.gl/#reportspam only accepts 1 link per submit.
>
> I have like 100 links that redirect
Note that information about Google is about 3 years out of date, we no
longer fall back to unencrypted.
Your best bet for important domains you care about it to try and contact
their admins to fix it.
Other than that, it's basically up to your policies what to do... well, and
what your software
On Fri, Jan 27, 2017 at 1:02 AM, Stefano Bagnara <mai...@bago.org> wrote:
> On 23 January 2017 at 20:42, Brandon Long <bl...@google.com> wrote:
>
>> Note that information about Google is about 3 years out of date, we no
>> longer fall back to unencrypted.
>
;
> This may be a stupid question, but can you help me understand what
> "Remote-MTA" means in this context? I'm a little confused as to how that
> works.
>
> On Thu, Feb 23, 2017 at 2:04 PM, Brandon Long <bl...@google.com> wrote:
>
>>
>>
>> On Thu, F
having IMAP IDLE to everywhere... ugh, I guess. What's another million
persistent connections. I'd rather make forwarding more reliable. I've
wanted to add an inbound gateway setting to consumer accounts, similar to
what we have for GSuite customers, which would allow us to be smarter about
There is no way for an end user to retrieve the password stored for access
to remote pop/msa servers.
Yes, giving us the password does increase the overall attack surface for
the password. Given the general issues with password hijacking, the
addition is fairly minor. If your service is small
About 1.5y ok, we tried to start enforcing strict correctness for the
HELO/EHLO argument. For whatever reason, we'd been very lenient before, to
the point where I think we would accept an "empty" argument (ie, just a
space after HELO), iirc. The main reason we did this was we were getting
The test was for the rbl DSN rfc clueless, they were attempting to test
whether we accepted mail with an empty mail from, ie bounces, which of
course we do... but their test is clueless.
Brandon
On Wed, Feb 15, 2017 at 10:11 AM, wrote:
> On Wed, 15 Feb 2017 05:59:36
Without specifics (domains, IPs, the sessionid you 'd out), I'm not
able to help.
Brandon
On Wed, Feb 15, 2017 at 2:30 PM, Aleksandr Miroslav
wrote:
> So I have a bunch of domains (about 20) that I use for mail. I run my own
> mail server, and keep the OS and the
Our code should handle that correctly, and testing it seems fine. It will
only do an A query if it's looking at an ip4 address.
I think the problem is dns errors, there are several things in our logs
which imply that we were unable to get a txt record in the last couple
days, though not today.
If your mail server doesn't expect to get forwarded mail, I can see using
SPF like that.
If you do expect to get forwarded mail, then it seems likely to cause more
false positives than it's worth.
Brandon
On Wed, Aug 17, 2016 at 6:41 AM, Al Iverson
wrote:
> It's
If you can't reproduce, are you sure these aren't cases where there is some
proxy or other server breaking the connection?
I'm not aware of any issues.
Brandon
On Mon, Feb 27, 2017 at 12:27 PM, Kostya Vasilyev
wrote:
> Hi,
>
> We've got an email app for Android, and lately
I did a survey of iconography and words for different mail ui's several
years back, and i think hotmail and yahoo used the same iconography, one
for spam the other for trash. The desire to use "junk" in place of spam is
probably partially to blame, as well.
ahh, from 2011, here, it was Apple
The spam team would love to send all unauthed mail to the spam label or
even reject it (they call it no auth no entry).
We're not there yet, though. Though, we mostly do that for ipv6 at this
point, and we're cranking on all of the big pieces that are remaining.
But that's probably not the
Sorry, vacation and all that. If you send me the details, I can take a
look.
Brandon
On Mon, Sep 26, 2016 at 8:31 AM, Al Iverson
wrote:
> I agree with Todd. DKIM first, get it working, then consider DMARC. Or
> even do DMARC put put a policy type of "none" for now.
I can take a look if you send me details.
In general, Gmail and gsuite domains are handled by the same system, with
minor differences and some settings for gsuite domains to do their own spam
filtering or turn our systems up (many companies want to stop most bulk
mail)
Brandon
On Oct 18, 2016
Are the messages queueing on your side? Or are you complaining about
delays after we get the mail?
Or are you saying the transaction just takes a while?
Do you have an example? Or ip?
Brandon
On Oct 21, 2016 7:03 AM, "Mark Jeftovic" wrote:
>
> I replied to another
It's odd, Gmail forwarding rewrites the envelope sender to be Gmail, so
forwarding bounces should go back to Gmail, not you. They could be
fetching the mail with pop and then forwarding it. I didn't know they had
that feature, but given that we do, it wouldn't surprise me.
Unfortunately,
So, I looked up the actual message. It is being forwarded to a hotmail.com
account normally, and then forwarded back.
It looks like Hotmail/Outlook is rewriting the envelope sender back to your
account.
Ie, it's te...@dop.com -> u...@gmail.com
user+caf_=user2=hotmail@gmail.com ->
We run with a 1MB limit as well, chosen mostly as a "nothing legit would
ever be that big" limit.
Everything gets bigger. I'm sure that limit will last us at least another
couple years ;)
Brandon
On Nov 1, 2016 3:47 AM, "Andrew C Aitchison" wrote:
> On Tue, 1 Nov
On Dec 7, 2016 9:27 AM, "Jim Popovitch" wrote:
On Wed, Dec 7, 2016 at 12:17 PM, John Levine wrote:
>>5. Does not override existing specifications that legislate the use
>>of "X-" for particular application protocols (e.g., the "x-name"
>>token
]
Brandon
[1] assuming the information is available as a signal, of course, but I
haven't looked to see if any of the signals would have it
On Wed, Dec 14, 2016 at 10:57 AM, Brandon Long <bl...@google.com> wrote:
> I really don't think we have explicit rules to catch A/B testing type
> camp
I really don't think we have explicit rules to catch A/B testing type
campaigns. OTOH, if our system thinks either of them is spam, that will
taint the other one as well if the rate of manual marking is high enough
and there are enough features in common.
Brandon
On Wed, Dec 14, 2016 at 10:32
Are you a gsuite customer? If you are and designate an IP as your inbound
gateway, then we'll assume the mail coming from there is inbound to us, and
skip that IP and any internal IPS to try and find the real external IP.
It's possible that we should check both.
If you're inbound gateway is on
Also, if your mail flow MX to google goes through multiple IPS, you should
list them all as internal gateways.
On Jan 10, 2017 10:03 AM, "Brandon Long" <bl...@google.com> wrote:
> Are you a gsuite customer? If you are and designate an IP as your inbound
> gateway, then
On Tue, Jan 10, 2017 at 10:48 AM, Vick Khera <vi...@khera.org> wrote:
>
> On Tue, Jan 10, 2017 at 1:17 PM, Brandon Long <bl...@google.com> wrote:
>
>> Also, if your mail flow MX to google goes through multiple IPS, you
>> should list them all as internal ga
Sounds like an automated system, if you had a single report for every
message with the full message, the system would automatically attach
everything the abuse desk needs.
Given the volume to our addresses, I could see the utility of just
responding that way to those.
On Dec 2, 2016 5:55 PM,
Gmail uses multiple engines and has not typically admitted to which engines
it uses, though there is some informed speculation our there.
Additionally, Gmail uses our own internal engines and heuristics for more
complete coverage.
Virus detection does not typically affect regular deliverability.
This seems like an odd place to raise this, but ok.
Yes, the blocked sender could be applied to both, I'm not sure if/why it
wasn't done that way.
That said, I actually think if you're going to check one, then it's the
RFC5322.From address which is the more logical choice. It's also the more
Unfortunately, automated bounce handling to know what means "no more mails
will ever go to this address" vs "some other mail might work" is not an
exact science.
Ie, mailman gets confused at DMARC rejects. The bounce handling when I
worked on Y!Groups was very complicated, and involved sending
ll still be visible by unspecified eyes
> after arrival).
>
>
>
> -K
>
> On Thu, Mar 16, 2017 at 1:50 AM, Brandon Long via mailop <
> mailop@mailop.org> wrote:
>
>> That's a custom rejection message set by that GSuite customer, no clue
>> what poli
That's a custom rejection message set by that GSuite customer, no clue what
policy they set.
Brandon
On Mar 15, 2017 9:35 PM, "Seth Mattinen" wrote:
> Here's one I'm hoping someone can tell me I'm missing something obvious:
> Google is rejecting a TLS connection with an
On Wed, Aug 2, 2017 at 9:36 AM, Laura Atkins wrote:
>
> On Aug 2, 2017, at 3:15 AM, Benjamin BILLON via mailop
> wrote:
>
> In the case of Gmail, you can have _some_ hint about your domain's
> reputation with the Gmail Postmaster Tools
Tighter how?
spf_checker_util: output header: softfail (google.com: domain of
transitioning ptp...@gmail.com does not designate 58.64.196.210 as
permitted sender) client-ip=58.64.196.210;
You want it to just fail? That would be silly, we expect people to
forward email.
I'll pass on your
e PTR
> records, so I am sure they are not used for sending email..
>
> But yes, the -all would be nicer... ;)
>
> By being able to reject during the SMTP handshake, it would also help alert
> the sending servers admin's to a problem with compromised accounts..
>
> But yea
On Mon, Jul 17, 2017 at 10:51 AM, Simon Forster
wrote:
> On 17 Jul 2017, at 16:59, Stefano Bagnara wrote:
>
> On 17 July 2017 at 16:57, Simon Forster wrote:
>
>
> On 17 Jul 2017, at 13:28, Stefano Bagnara wrote:
>
>
They may not even be renting directly to spammers, but their users are
getting compromised and sending spam and other crap from their servers. We
see clickbot and other fraud farming from those IP ranges as well.
It is an unfortunate situation, and challenging, no doubt.
Brandon
On Mon, Jul
Humans also don't universally understand English, much less technical
responses. And the smtp reply codes and extended status codes don't do a
great job of mapping to what an end user can actually do about the bounce.
We currently classify the bounce into about 10 different categories based
There is no email address or contact number for the safe browsing list.
The information you need should be on stopbadware.org or Google's webmaster
tools, and you should be able to request a delisting there when you've
fixed the issue.
Brandon
On Tue, Jul 11, 2017 at 9:29 AM, Robert L Mathews
I don't know how much of this is fictional or the order of exact
operations...
but you've admitted your server got hacked and then we blocked your mail.
A good percentage of the spam we receive is from hacked boxes, and these
boxes can send millions of messages in the minutes after being hacked.
Other things to consider are support/sales/ads or anything that contains
your brand. Guess this depends on whether this is a set of domains that
anyone can sign up for an address on, or whether they own the domain.
Gmail also restricted all usernames that it's employees used and all
popular
On Tue, Jul 25, 2017 at 4:13 PM, Ted Cabeen
wrote:
> On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:
>
>> STARTTLS is opportunistic and doesn't protect against active
>> Man-in-the-Middle. In case of TLS problems it falls back to plain text.
>>
>
>
On Wed, Jul 26, 2017 at 1:23 AM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:
>
> Il 25 luglio 2017 alle 22.25 Grant Taylor via mailop ha scritto:
>
>
> On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
>
> To protect against passive Man-in-the-Middle, there is no actual
If it becomes important, I'm sure it can be done.
I mean, you all update your av signatures at least daily, or your spam
rules.
And whether they would need to follow the browser list or whatever isn't
clear, sure.
It's early in this stuff for email, maybe DANE will be the solution that
catches
On Fri, Jul 28, 2017 at 5:58 AM, Michael Orlitzky
wrote:
> On 07/27/2017 01:44 PM, Dave Warren wrote:
> >>
> >> "Even if it were generally possible to determine a secure server name,
> >> the SMTP client would still need to verify that the server's
> >> certificate chain is
and DANE work, it
will come into play more.
Brandon
On Fri, Jul 28, 2017 at 2:32 PM, Michael Orlitzky <mich...@orlitzky.com>
wrote:
> On 07/28/2017 05:19 PM, Brandon Long wrote:
> >
> > We're hovering at 88% encrypted, inbound & outbound, if those in charge
> > decided
On Mon, Jul 31, 2017 at 2:50 PM, Luis E. Muñoz wrote:
> On 31 Jul 2017, at 13:21, Ryan Harris via mailop wrote:
>
> Not that we're the best neighbors in this regard, but we don't reuse
> connections for the vast majority of endpoints, just the highest by volume,
> and we
On Thu, Jul 27, 2017 at 11:32 AM, Grant Taylor via mailop wrote:
> On 07/27/2017 11:44 AM, Dave Warren wrote:
>
>> I've never understood why this is a special challenge in the SMTP world,
>> it's generally a solved problem for HTTPS, XMPP, and various other
>> protocols.
>>
>
On Thu, Jul 27, 2017 at 9:05 AM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:
>
> Il 26 luglio 2017 alle 19.10 Brandon Long <bl...@google.com> ha scritto:
>
> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least ru
1 - 100 of 553 matches
Mail list logo