Re: [mailop] Gmail throttling our office mail server

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

Re: [mailop] Mailchimp / Mandrill App: European VS US Privacy Laws

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

Re: [mailop] Microsoft/Hotmail discards mails

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

Re: [mailop] Microsoft/Hotmail discards mails [slightly OT]

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

Re: [mailop] change at gmail???

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

Re: [mailop] change at gmail???

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

Re: [mailop] Any from Google

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. > >

Re: [mailop] DKIM + mailinglists (rehash)

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

Re: [mailop] Lack of TLS 1.1/1.2 support on Apple email products

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

Re: [mailop] Microsoft/GMail MX Priority Issues - mailop Digest, Vol 100, Issue 32

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

Re: [mailop] Google Rate Limiting

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 >

Re: [mailop] Gmail rate limit

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. >> >

Re: [mailop] Gmail rate limit

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 >

Re: [mailop] Gmail rate limit

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

Re: [mailop] Gmail rate limit

There are multiple domains involved, they may be forwarding messages, in which case spf won't be enough. And, there are multiple signals involved, so getting authed would get past those rules, but may hit other ones. Note, that if you are forwarding, you can still run a spam filter and then dkim

Re: [mailop] Gmail rate limit

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.

Re: [mailop] Google Groups pain

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

Re: [mailop] Yahoo deferred with a page not found

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

Re: [mailop] Still seeing throttling/delays from google apps after 3 weeks.

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

Re: [mailop] Still seeing throttling/delays from google apps after 3 weeks.

Also, this is where details would have helped with your last message, the error you're receiving isn't an anti-spam measure, it's a "sending too many messages to a specific user" error, which is falsely firing in your case due to... it's complicated, but your hosting provider has been allowing

Re: [mailop] Multiple DKIM signatures -- any benefit or detriment?

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

Re: [mailop] deprecating rc4 & ssl3

. 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

Re: [mailop] Contacting Google Spam Filtering Team?

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

Re: [mailop] deprecating rc4 & ssl3

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

Re: [mailop] Speaking of Banks, Pet Peeve SPF

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

Re: [mailop] Gmail Blacklisting

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

Re: [mailop] How long does an IP address take to "Warm up"?

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

Re: [mailop] How long does an IP address take to "Warm up"?

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

Re: [mailop] How long does an IP address take to "Warm up"?

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,

Re: [mailop] TLS verify=FAIL

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

Re: [mailop] Dealing with a DKIM replay attack

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

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

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 >>

Re: [mailop] GMail 421 is sometimes a permanent failure?

; 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

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

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

Re: [mailop] Facebook/Twitter, advice/anyone here?

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

Re: [mailop] Facebook/Twitter, advice/anyone here?

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

Re: [mailop] Gmail SRS Problem: low reputation of sending domain

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

Re: [mailop] Mails to microsoft

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

Re: [mailop] offtopic: bulk report abusive goo.gl links

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

Re: [mailop] Dealing with "454 TLS not available issues" (Aruba.it)

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

Re: [mailop] Dealing with "454 TLS not available issues" (Aruba.it)

On Fri, Jan 27, 2017 at 1:02 AM, Stefano Bagnara wrote: > On 23 January 2017 at 20:42, Brandon Long wrote: > >> Note that information about Google is about 3 years out of date, we no >> longer fall back to unencrypted. >> > > Thank you very much Brandon for

Re: [mailop] Curious: Strange NDRs from gmail.

RFC 3464 2.3.5? In this case, the message is being forwarded from Google to the domain's onsite server, so that's the server we attempted to forward to. Brandon On Thu, Feb 23, 2017 at 1:14 PM, Luke Martinez via mailop wrote: > Super helpful. Thanks. > > This may be a

Re: [mailop] Forwarding issues, was Mails to microsoft

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

Re: [mailop] Forwarding issues, was Mails to microsoft

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

Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?]

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

Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?]

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

Re: [mailop] (weird) Gmail deliverability issues

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

Re: [mailop] Gmail SPF bug?

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.

Re: [mailop] Blocking emails from domains without SPF records

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

Re: [mailop] Gmail - SMTP handshake errors

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

Re: [mailop] How many more RBL's do we really need?

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

Re: [mailop] Google: Increase in false positives?

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

Re: [mailop] (New) Mailman mailing lists marked as spam by Gmail

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.

Re: [mailop] Is anyone around from Gmail ?

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

Re: [mailop] large delays forwarding to gmail?

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

Re: [mailop] Confused by bounce

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,

Re: [mailop] Confused by bounce

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 ->

Re: [mailop] Recommendations for max limits on header, for a receiving server

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

Re: [mailop] Storing 821 envelope recipients in an 822.Header?

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

Re: [mailop] Multivariate Subject testing influences Gmail's filters?

Also, we've definitely seen spam with emoji, especially the ones that end up animated, ie: https://shkspr.mobi/blog/2015/05/how-gmail-lets-spammers-grab-your-attention-with-emoji/ I don't think we have explicit rules about that, but it's always possible the ML models have learned some.[1]

Re: [mailop] Multivariate Subject testing influences Gmail's filters?

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

Re: [mailop] Google SPF checking intermediate server

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

Re: [mailop] Google SPF checking intermediate server

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" wrote: > Are you a gsuite customer? If you are and designate an IP as your inbound > gateway, then we'll assume the mail

Re: [mailop] Google SPF checking intermediate server

On Tue, Jan 10, 2017 at 10:48 AM, Vick Khera wrote: > > On Tue, Jan 10, 2017 at 1:17 PM, Brandon Long wrote: > >> Also, if your mail flow MX to google goes through multiple IPS, you >> should list them all as internal gateways. >> > > Does it make sense to

Re: [mailop] Too funny Amazon Abuse Responses..

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,

Re: [mailop] Engine(s) used to detect suspicious attachments?

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.

Re: [mailop] Google blocked senders list

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

Re: [mailop] bulk-mailer amnesia (sendlabs, mailjet)

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

Re: [mailop] Google rejects a TLS connection saying it needs TLS...

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

Re: [mailop] Google rejects a TLS connection saying it needs TLS...

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

Re: [mailop] Gmail labeled as Spam based on content

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

Re: [mailop] Anyone Else notice a significant reduction in spam leakage from Gmail over last couple of weeks?

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

Re: [mailop] Anyone Else notice a significant reduction in spam leakage from Gmail over last couple of weeks?

So, yes, our records covert our entire IP space, which is way more than we have servers for, and that is unfortunate. I've had an open bug for a couple of years to fix this, but the _netblocks thing is used by things other than SPF, so it's complicated. -all is just plain silly. If you want to

Re: [mailop] Properly vetting an hosting provider before buying/moving

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: > >

Re: [mailop] btinternet.com blacklist

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

Re: [mailop] RFC question on smtp replies...

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

Re: [mailop] Urgent: Contact at Googles Safe Browsing

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

Re: [mailop] btinternet.com blacklist

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.

Re: [mailop] Restricted email address UIDs for public email domains

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

Re: [mailop] self-signed cert for inbound TLS

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. >> > >

Re: [mailop] self-signed cert for inbound TLS

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

Re: [mailop] self-signed cert for inbound TLS

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

Re: [mailop] self-signed cert for inbound TLS

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

Re: [mailop] self-signed cert for inbound TLS

That's a good point. The number is only for encrypted, not authenticated and it looks like we don't currently log verification. We do CA verification and a GSuite domain can choose to require it for a connection, but we don't use the information generally. Presumably when we finish our STS and

Re: [mailop] Concurrent Messages and Proper Time to Keep a Connection Open

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

Re: [mailop] self-signed cert for inbound TLS

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. >> >

Re: [mailop] self-signed cert for inbound TLS

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 ha scritto: > > Why can't smtp software being expected to maintain a list of trusted CAs? > Or at least run on an OS that is expected to

Re: [mailop] Alice.it contact

Pretty sure we accept mail to just postmaster: 220 mx.google.com ESMTP 1si76040pfp.214 - gsmtp ehlo foo 250-mx.google.com at your service, [172.31.148.80] 250-SIZE 157286400 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 mail

Re: [mailop] Google email hosting and abuse handling?

You can whitelist senders either by IP or by address/domain: https://support.google.com/a/answer/2368132 Yes, you can't currently whitelist by receiving address from the admin console. To whitelist abuse@domain, you would need to: 1) Go into the groups interface for the abuse group and disable

Re: [mailop] Many SPF failures lately

On Mon, May 15, 2017 at 11:02 AM, D'Arcy Cain wrote: > On 2017-05-15 01:20 PM, Ken O'Driscoll via mailop wrote: > >> >> On Mon, 2017-05-15 at 12:34 -0400, D'Arcy Cain wrote: >> [...snip...] >> >>> Are admins getting dumber or is the software (py-policyd in our case) >>> getting

Re: [mailop] Speaking of too many SPF, Many SPF failures lately

On Wed, May 17, 2017 at 4:16 PM, John Levine wrote: > In article mail.gmail.com> you write: > >_spf.google.com is 4 lookups in total). > > Do you know why? It'd be easy enough to glom them together into one > record. > I

Re: [mailop] dkim signature failures sendmail/opendkim

It's unfortunate that dkim canonicalization is based on the raw message, and now on what the message represents, though defining a shared understanding of the "decoded" message along various lines would be quite complicated (IMAP somewhat does that, I guess). In any case, obviously if you care

Re: [mailop] Endless spam blowback from Microsoft Office 365

I'm most annoyed that they re-interpret DMARC fails as SPF fails, with then completely bogus overly technical information on how to fix SPF that has no application whatsoever to what they're doing. Brandon On Thu, Jun 22, 2017 at 1:50 AM, Duncan Brannen wrote: > > Hi

Re: [mailop] New gmail warning about spoofing

Sorry, I was on vacation last week. This new warning was added because Gmail is something of a special case. Right now, the "Sent Mail" label is essentially just a special filter on from:me, which is very different from most mail clients. In most mail clients, the sent folder is only mail that

Re: [mailop] Many SPF failures lately

Is forwarding mail something your users never do? Or do you think the sender should be able to specify that the mail can't be forwarded? With the exception of a pure -all record, policy enforcement based purely on spf is a poor choice. Maybe, depending on your users, it won't raise the fp rate

Re: [mailop] Speaking of too many SPF, Many SPF failures lately

On May 18, 2017 9:02 AM, "Luis E. Muñoz" wrote: On 17 May 2017, at 16:49, Michael Peddemors wrote: It looks not bad, successive lookups to 3 parts.. and they all look good. Don't like this part of course.. include:sharepointonline.com ip4:52.104.0.0/14 Right there!

Re: [mailop] SPF record

Well, the obvious usage of ARC where DKIM is not a solution is for any modifying hop, such as a mailing list. The mailing list can DKIM sign the modified message, but it then lacks alignment and also takes on "ownership" of the message (see discussion about forwarding in general taking the

Re: [mailop] ARC lesson please

On Mon, May 22, 2017 at 10:26 PM, Steve Atkins wrote: > > > On May 22, 2017, at 10:01 PM, Hal Murray > wrote: > > > >> ARC is the very-near-future solution to much of this. Get your vendors > on it. > >> http://arc-spec.org > > > > I'm missing

Re: [mailop] dkim signature failures sendmail/opendkim

>From our records, most of the errors are "Verify failed", which implies a header mismatch (there are also a few body hash mismatch, which would be a body issue instead). On Fri, May 26, 2017 at 9:55 AM, John Levine wrote: > In article

Re: [mailop] Speaking of too many SPF, Many SPF failures lately

We've seen "v=spf1 +all" for example. On the other hand, what are you supposed to do with this from a prominent tech company: "v=spf1 ip4:17.0.0.0/8 -all" So, "it's complicated" Brandon On Thu, May 18, 2017 at 6:47 PM, Ángel wrote: > The question is, when does a large

  1   2   3   4   5   6   >