[mailop] S/MIME Signature alignment

I'm currently trying to wrap my head around this S/MIME signature thing, is there any best practices document besides the couple of RFCs that says something about the alignment between the used cert and the 5321From or 5322From? Like for SPF that must align to 5321From and DKIM that must align to

Re: [mailop] Spike in "554 Transaction failed" from Microsoft properties

Hello, We started seeing "554 Transaction failed" rise on the 3rd, the peak occurred on the 5th like Frank announces. Now there appears to be very low amount of "554 Transaction failed" today and appears to be normalizing. Ryan On Wed, Feb 10, 2016 at 12:50 AM, David Hofstee

Re: [mailop] Failure reporting false positives to ClamAV

That rule has triggered more and more false positives of late BTW.. If you would like to disable this check in the future, you can do so by editing /etc/clamav/clamd.conf and setting the following value to false: PhishingScanURLs Once done, you will need to restart clamav:

Re: [mailop] Anyone from ComCast on here.. not really MailOp Related

On 16-02-09 11:14 PM, Aaron L. Meehan wrote: On Tue, Feb 09, 2016 at 08:56:28AM -0800, Spam Auditor wrote: Just noticed a very large increase of activity from comcast, it could be that they have changed naming conventions (PTR) records on their dynamic space, or that they are not doing egress

Re: [mailop] DKIM signing domain selection (RFC 5863 section 2.3) question

Without DMARC, DKIM is anti-modification, not anti-spoofing. DKIM is there to say that a message has not been modified from the time that the DKIM header was added until it was authenticated by the recipient. It doesn't need to match the from address (think yahoo, gmail, Hotmail, etc that

Re: [mailop] S/MIME Signature alignment

In article <20160210172557.038d629e@A-1212-7.optivo.intern> you write: >I'm currently trying to wrap my head around this S/MIME signature >thing, is there any best practices document besides the couple of RFCs >that says something about the alignment between the used cert and the >5321From or

Re: [mailop] DKIM signing domain selection (RFC 5863 section 2.3) question

It is a lot simpler to simply use a different originating IP Address, based on whether it is marketing vs transactional, I don't believe anyone should mix those two... On 16-02-10 09:45 AM, Doug Brenner wrote: RFC 5863 section 2.3, "Choosing the Signing Domain Name", discusses using multiple

Re: [mailop] regalcinemas.com delivery issue

The error message here is Ironport boilerplate. You’ll need to contact Cisco. —srs > On 10-Feb-2016, at 11:07 PM, Staudinger, Malcolm wrote: > > Long shot, but if there’s any mail admins for regalcinemas.com > on here, can you drop me a note

Re: [mailop] Spike in "554 Transaction failed" from Microsoft properties

Hi Michael, To put a number on small: From my side, 0.2% is not arriving. Yours sincerely, David Hofstee Deliverability Management MailPlus B.V. Netherlands -Oorspronkelijk bericht- Van: mailop [mailto:mailop-boun...@mailop.org] Namens Michael Wise Verzonden: woensdag 10 februari 2016

[mailop] Failure reporting false positives to ClamAV

I recently attempted to report a false positive via their web interface. I think it's safe to say, they didn't get my report so I thought I'd include it here and hope they might be reading, along what appears to have gone wrong. Regrettably, there doesn't seem to be a channel to report a false

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] Google Rate Limiting

>If “everyone” is deferring your mail it’s probably not because the entire >Internet >made policy changes a couple of weeks ago. There’s a more logical explanation >for what >you’re seeing. Sour grapes about the patent, I'd say. R's, John ___ mailop