Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

https://dmarcian.com/dmarc-inspector/chinalovecupid.com says all is fine Also note you need some traffic, before an aggregate report is sent to you. Some receivers will not send a daily report if they have not seen X emails from your domain. at https://dmarc.org/resources/deployment-tools/ you

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

On 14/04/16 23:58, Michael Wise wrote: Checked the Microsoft.com record, and the \; is there as well, so it may be an artifact of my software. Just FI https://dmarc.org/wiki/FAQ#Why_are_the_semicolons_escaped_in_DMARC_records.3F_Should_I_do_the_same_when_I_publish_a_DMARC_record.3F

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

Checked the Microsoft.com record, and the \; is there as well, so it may be an artifact of my software. You can specify multiple addresses in the rua… maybe put in a gmail.com or similar address to see if anything arrives there? I presuppose you’ve reviewed the mail server logfiles to see if

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

What part of it … isn’t? Oh, waitaminute … the record we’re talking about doesn’t specify pct= … would it default to 0? [cid:image001.png@01D1965C.198D3FE0] Aloha, Michael. -- Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been Processed." | Got the Junk Mail Reporting

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

We've put in tag "pct=100", waited a few days. Nothing, then took it out to try and again nothing. Thanks, [image: Dyn logo, Dyn.com] [image: Dyn facebook account]

Re: [mailop] Any Proofpoint contacts here?

Excerpts from Jim Cheetham's message of 2016-04-15 09:12:37 +1200: > Yes, we had had a compromised account, and we had addressed it before the > block became obvious. May as well let you all know ... a newbie mistake by me. We don't have a totally automated way to close down all the various

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

On 14 Apr 2016, at 14:04, Franck Martin via mailop wrote: I prefer example.com TXT "v=spf1 ip:0.0.0.0/0 -all" or more sneaky example.com TXT "v=spf1 ip:0.0.0.0/1 ip:128.0.0.0/1 -all" Which large mail provides either ignore or penalize. (Or will at some point in the future). -lem

Re: [mailop] Any Proofpoint contacts here?

Excerpts from Jaren Angerbauer's message of 2016-04-15 04:33:42 +1200: > Jim -- I'll reply offline with details (looks like you have a compromised > user sending phish) Thanks Jaren, just ack-ing to the list that our problem is sorted. Thanks everyone for their comments, too. Yes, we had had a

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

I prefer example.com TXT "v=spf1 ip:0.0.0.0/0 -all" or more sneaky example.com TXT "v=spf1 ip:0.0.0.0/1 ip:128.0.0.0/1 -all" On Thu, Apr 14, 2016 at 1:22 PM, Brandon Long via mailop wrote: > What, you don't want to trust all of Apple's /8? > > Anyways, adding spf for an

Re: [mailop] TLS verify=FAIL

Client certificates in emails are not rare, even to the contrary, they are predominant. The proportion of verifiable client certificates is about the same proportion of verifiable server certificates. I think there are a few MTAs that have different config for certificate presented as a client vs

Re: [mailop] Gmail Blacklisting

You can't force your customers, but you have to tell them what will happen to their emails. You can point them to this document: https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf and also

Re: [mailop] Should I be disappointed with Reflexion?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2016-04-12 at 13:48 -0700, Steve Atkins wrote: > It's also possible that Reflexion is just sending terribly structured > mail that "looks like" spam - not unusual amongst companies who build > their own mail software - but I'd need to see

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] Should I be disappointed with Reflexion?

The bank emails I receive usually include a piece of information they know about me (last 4 of account number or similar) to prove it's really from the bank. -Original Message- From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Carl Byington Sent: Thursday, April 14, 2016

Re: [mailop] mailop Digest, Vol 102, Issue 35

3A8A 9CC3 8966 9374 82CD C982 0605 >-- next part -- >A non-text attachment was scrubbed... >Name: signature.asc >Type: application/pgp-signature >Size: 198 bytes >Desc: not available >URL: ><https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/at

Re: [mailop] Should I be disappointed with Reflexion?

On the other hand Trusting a user to go to a website is a risk also. Many users just type something like "chase" into their starting webpage (yahoo, bing, google, etc..) and go to the first link listed. Matthew Huff | 1 Manhattanville Rd Director of Operations   |

Re: [mailop] Should I be disappointed with Reflexion?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2016-04-14 at 12:56 -0400, Henry Yen wrote: > > 6. If the information is of particularly high value, look at what > the more competent end of banks and other financial institutions do to > add trust > Both Chase bank (jpmchase) and

Re: [mailop] Should I be disappointed with Reflexion?

On Thu, Apr 14, 2016 at 08:33:16AM -0700, Steve Atkins wrote: > Best practices for that email would be: > 2. Not including a direct link to the portal, rely on the customers having > bookmarked it or being able to find it easily from your main site > 3. Sending the mail From: your main

Re: [mailop] Should I be disappointed with Reflexion?

If I ran the gateway I'd never allow password-protected ZIP files through as attachments. -- Al Iverson www.aliverson.com (312)725-0130 On Thu, Apr 14, 2016 at 11:22 AM, Howard F. Cunningham wrote: > HI > > This is a great conversation... > > In regards to sending

Re: [mailop] Any Proofpoint contacts here?

Word from the persons who deal with PDR systems is: The "most recently seen" dates are not accurate. I really wish they didn't include that data as it's next to worthless. Most likely they get delisted 1x, more 'bad' stuff comes in and the IP gets re-shot. Delisting is not permanent. So

Re: [mailop] Any Proofpoint contacts here?

On Thu, Apr 14, 2016 at 8:46 AM, Laura Atkins wrote: > > On Apr 14, 2016, at 5:50 AM, John Possidente > wrote: > > I've been seeing this, too, for more than one client/mailer over the last > few weeks. The listing disappears shortly after the

Re: [mailop] Should I be disappointed with Reflexion?

HI This is a great conversation... In regards to sending password protected zip files, I am aware of several spam filters that inspect the contents of zip files and if the file is password protected it is blocked.. hc Howard Cunningham, MCP howa...@macrollc.com - personal For technical

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

DMARC is not something I'm well-versed in, but was trying to do what tests I could. Would be interesting to see what would happen if someone deliberately tried to send from a non-SPF valid IP. Normally, it just sorta works, but I've never actually seen the traffic it generates, or seen the

Re: [mailop] DMARC record in p=none not receiving aggregate reports to RUA

My bad, I should have included this issue has spanned well over multiple days so the 24 hours rule wasn't a cause. I queued a few different customers I know with valid DMARC records and I'm seeing the “\” in front of the “;”’s. I will however dig into the greylisting. As always, thank you all

Re: [mailop] Any Proofpoint contacts here?

Jim Cheetham wrote: I'm suffering from a strange recurrent blocking ... https://support.proofpoint.com/rbl-lookup.cgi?ip=139.80.64.247 /me waves hand... however also takes note of the other reply, and this: Your IP address is not currently being blocked: 139.80.64.247 Regards, -- Michelle

Re: [mailop] TLS verify=FAIL

On 14/04/16 00:58, Al Iverson via mailop.org wrote: Boo @ designing something so that "FAIL is really nothing is to be concerned with." It's the kind of thing deliverability people will now be spending the rest of their lives explaining to clients that this big ole FAIL is to be ignored.