Re: [mailop] Google Postmaster Tools data missing recently - anyone else?

[Maarten Oelering via mailop]

We noticed it as well. On the GPT website there’s data for 2nd. But the API 
does not return any data for the last couple of days.

Maarten

> On 4 Dec 2023, at 22:52, Omar Thameen via mailop  wrote:
> 
> Is anyone else seeing data missing from Google Postmaster Tools?
> For all our hosted domains, everything was consistent until Nov 28,
> then no data until Dec 2, and nothing yet for Dec 3.
> 
> Omar
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Maarten Oelering via mailop]

I would like to believe that the solution offered by Abusix is a drop-in 
replacement. Adding the CFBL-Address header is not too difficult for most 
senders. 
But most sender systems rely on ARF reports, with the rfc822 attachment. Not 
XARF, with the json attachment. So there’s two standards to push.

Maarten

> On 22 Sep 2023, at 00:01, Steve Freegard via mailop  wrote:
> 
> Hi Mike,
> 
> Aside from stating categorically that we're not interested in monetizing the 
> reports like Validity are doing, the only other thing I can suggest is that 
> you look at the history of what we've done in the past.   We've provided the 
> Abuse ContactDB as a free service for well over 10 years (used by many places 
> including Fail2Ban etc.), we've contributed XARF to the community and are 
> providing Global Reporting, which is a free Abuse Reporting Service (of which 
> we'll be using 99% of the code already written to implement this Feedback 
> Loop functionality).
> 
> The whole point about backing the Draft RFC is also to open it up as much as 
> possible.   The current state means that you either pay Validity or you don't 
> get anything, period.  They have the current monopoly and zero competition 
> which is why they can do this in the first place.   
> 
> I'd also like to point out that there is absolutely no guarantee that any 
> mailbox providers will come across to us either; that will take persuasion 
> from the industry, but we make it as easy as possible with this service, 
> they're effectively swapping one email address with another.  Why would a 
> mailbox provider, right now, bother to put the development time into 
> implementing a draft RFC that (at the time of writing) only two entities are 
> using? (CleverReach and Onmivary with ActiveCampaign to follow soon), they 
> would also have the on-going management and approval of new CFBL-Addresses to 
> deal with as well.
> 
> The point is; we can implement this pretty quickly with a few code changes on 
> our end to something we've already been working on for months and provide an 
> alternative to Validity and help get the draft RFC more widely implemented - 
> at which point with much wider adoption, it makes it far more easy (and 
> therefore likely) for mailbox providers to implement this themselves if they 
> wish to, or for other entities to offer a similar service should they choose.
> 
> That's surely better than the current status quo and sitting back and doing 
> nothing, right?
> 
> Kind regards,
> Steve.
> 
> 
> On Thu, 21 Sept 2023 at 20:43, Mike Hillyer  > wrote:
>> I think the first question anyone will ask is "How do we know that Abusix 
>> won't eventually become Validity 2: the Abusix Remix"? I do like the idea of 
>> pushing the RFC, but if you're in the middle many of those MBPs will likely 
>> defer to a new middle-man to handle the implementation, and we're back at a 
>> single vendor.
>> 
>> Mike
>> From: mailop mailto:mailop-boun...@mailop.org>> 
>> on behalf of Steve Freegard via mailop > >
>> Sent: Thursday, September 21, 2023 12:05 PM
>> To: Support 3Hound mailto:supp...@3hound.com>>
>> Cc: mailop@mailop.org  > >
>> Subject: Re: [mailop] New Validity policy for paid FBL (ARF)
>>  
>> Just saw this thread; I published this earlier today and we're likely going 
>> to discuss it at M3AAWG:  https://abusix.com/feedback-loops/
>> 
>> TLDR; Abusix is willing to take this on and provide it as a free service 
>> from any mailbox provider that wishes to participate, but we'll do it based 
>> on the Independent RFC Draft using CFBL-Address, so we don't just end up 
>> swapping out Validity for us, we help adopt a standard that any mailbox 
>> provider can use going forward if they wish.
>> Putting us in the middle just means that we take on the burden of 
>> processing, wrapping and delivering the reports and approving the 
>> CFBL-Addresses that can receive them and producing some high-level 
>> statistics that might be interesting at the same time.
>> 
>> Kind regards,
>> Steve.
>> 
>> 
>> On Mon, 11 Sept 2023 at 12:29, Support 3Hound via mailop > > wrote:
>> Dear list,
>> I would like to understand what the community think about the new Validity 
>> universal feedback loop service that is switching to a paid service starting 
>> 21 September 2023.
>> 
>> As Validity worked in the the last years to achieve the management of the 
>> FBL service from all the "main" country-level and international mailbox 
>> providers (as the "universal" word suggest), I think that this new policy is 
>> unfair and a very bad news for the mail operators community.
>> 
>> During years the FBL became a kind of "safe feature" for users that prefer 
>> to click "junk" or "spam" and be sure they will not receive anymore.
>> 
>> The "one click unsubscribe/ List-unsubscribe header" should be the right way 
>> to do that... 

Re: [mailop] verifier.port25.com

[Maarten Oelering via mailop]

You can try our free tool at emailaudit.com. It is especially strong in 
authentication checks.

Maarten

> On 23 May 2023, at 20:31, Blake Hudson via mailop  wrote:
> 
> Looks like the email verification application at verifier.port25.com 
> described in this 
> (https://postmarkapp.com/blog/port25s-authentication-and-spam-assassin-tool) 
> article may have been shut down.
> 
> Anyone have any insight into this or alternative tools for testing DKIM, SPF, 
> and similar in one go?
> 
> --Blake
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Email System Testing Methodologies?

[Maarten Oelering via mailop]

We developed emailaudit.com <http://emailaudit.com/> for this purpose. It 
checks compliancy, authentication, and technical best practices. It’s free with 
a limit of 3 audits per day.

Maarten Oelering
Postmastery

> On 10 Jun 2022, at 16:48, Jesse Hathaway via mailop  wrote:
> 
> I am working on some architectural changes to our email systems at the
> Wikimedia Foundation[1] and I am a bit befuddled as to the best way to
> test changes to the current system. As you all are all aware email is a
> distrubted system which encompases a wide variety of protocols. Ideally
> I would like to know that our system behaves as expected with regards
> to: mail routing, spam detection, and spam avoidance (SPF, DKIM, ARC).
> Do folks have any suggestions on methods or systems to do this type of
> whole system testing? Yours kindly, Jesse Hathaway
> 
> [1]: https://wikitech.wikimedia.org/wiki/Email_System_Revamp
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best mailbox provider for personal domain?

[Maarten Oelering via mailop]

If you have a dozen of personal mailboxes at G Suite Legacy then even a few $ 
per mailbox adds up. A free solution is Cloudflare Email Routing, now in public 
beta. 
If you use them as DNS provider for your domain (also free option) then you can 
setup email forwards. For example to gmail.com or icloud.com addresses. 
Sending and replying from your domain is not supported. But if you have an SMTP 
server available you can setup your domain as secondary address in gmail.com.

Maarten



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best mailbox provider for personal domain?

[Maarten Oelering via mailop]

What about iCloud+ with 50GB for $1/€1. I see it supports up to 5 custom 
domains.

Maarten

> On 9 Apr 2022, at 08:40, Byung-Hee HWANG via mailop  wrote:
> 
> Tara Natanson via mailop  writes:
> 
>> (...thanks...)
>> (assuming I have no desire to run my own server) 
>> 
>> Thanks in advance for any recommendations!
> 
> In this Earth, there is no free chagre for my own domain. Still Google
> Workspace will be good value for money.
> 
>> Tara Natanson
> 
> Sincerely, Byung-Hee
> 
> -- 
> ^고맙습니다 _白衣從軍_ 감사합니다_^))//
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best mailbox provider for personal domain?

[Maarten Oelering via mailop]

Hi Tara,

I have the same issue. I am using 3 legacy G Suite domains for different 
purposes.
One option I am considering is IONOS, because I know the anti-spam should be 
good after someone we both know well is responsible for that.

Maarten

> On 8 Apr 2022, at 16:55, Tara Natanson via mailop  wrote:
> 
> I'm happy to pay some amount of $$.  But I've got 5 users, so even if i 
> turned all my personal extra addresses into aliases, I'd still be paying 
> Google 25$/month for the rest of my family members.  so I'm looking for 
> something less than that.  
> 
> Tara 
> 
> On Fri, Apr 8, 2022 at 10:33 AM Charlie Jonas  > wrote:
> You haven't said whether you're looking for something that's free as in 
> beer, but if you are prepared to pay a small amount then based on what 
> you're looking for I'd recommend Fastmail.
> 
> HTH,
> 
> Charlie
> 
> On 08/04/2022 14:40, Tara Natanson via mailop wrote:
> > A while back there was a thread about the best place to host small biz 
> > domain email but I'm looking for something even smaller.
> > 
> > I've got my personal domain hosted on gmail.  It's been there for more 
> > than 10 years and was grandfathered into their free hosting tier.  In 
> > June GMAIL is doing away with this plan and going to charge 5$/address 
> > per domain per month.  I've got dozens of addresses setup so this really 
> > isn't a good/affordable option anymore.
> > 
> > Where would you recommend hosting your domain so that you can pop/imap, 
> > use "+" addressing, isn't spammer friendly, and basically works similar 
> > to gmail? I no longer have a website setup, so mail is the only thing I 
> > care about. I'm fine with a solution that has me setting up a new gmail 
> > account and just popping the mail to there, but what are folks using 
> > these days?  (assuming I have no desire to run my own server)
> > 
> > Thanks in advance for any recommendations!
> > 
> > Tara Natanson
> 
> -- 
> Charlie Jonas
>~chtjonas
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Who Do You Recommend for Small Business Regular (Non-Bulk) Email?

[Maarten Oelering via mailop]

> On 2 Mar 2022, at 18:52, Matthew V via mailop  wrote:
> 
> This is likely tied to Google's announcement that they are ending the legacy 
> (Free) Gsuite services so many small or hobby domain owners are looking at 
> other options.

That is exactly the reason why I am looking for a solution (in EU) for my 
family mailboxes with a custom domain. 
Some hosters offer cheap e-mail hosting (e.g. TransIP in NL/BE). But I am 
afraid that spam filtering will be rough. 
Protonmail looks solid (and secure), but will cost the same as Google 
Workspace. Other good options in the EU?…

Thanks,
Maarten


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Sending to google/gmail - timeouts mainly with larger (~400k+) emails

[Maarten Oelering via mailop]

Hi Andrew,

Sorry for misreading the 400k, my bad.

Thank you for sharing more details and the solution.

Maarten

> On 2 Dec 2021, at 22:52, Andrew Hearn via mailop  wrote:
> 
> After trying a few things, disabling TCP Fast Open seems to have worked...
> 
> My mail queue is being delivered successfully to Google MXs!
> 
> A bit more about our system:
>  Stock Exim from Debian 11, using GnuTLS.
>  Exim version 4.94.2 #2 built 13-Jul-2021 16:04:57
> 
> And I added:
>  hosts_try_fastopen =
> to the outbound smtp transport.
> 
> Andrew.
> 
> 
> 
> On 02/12/2021 12:50, Andrew Hearn via mailop wrote:
>> Hello,
>> We're a UK ISP, and relay email for our customers as well as send our 
>> customers emails such as invoices.
>> We currently have about 1,000 emails queued for google accounts and these 
>> are failing with a timeout, eg from exim:
>> 2021-12-02 11:48:05 1msize-005feQ-DI H=gmail-smtp-in.l.google.com 
>> [142.250.13.26] TLS error on connection (send): The TLS connection was 
>> non-properly terminated.
>> 2021-12-02 11:48:05 1msize-005feQ-DI H=gmail-smtp-in.l.google.com 
>> [142.250.13.26]: SMTP timeout after sending data block (525043 bytes 
>> written): Connection timed out
>> Based on past experience, eventually, the emails may will through.
>> This is also intermittent, as sending to my own gmail address tends to get 
>> through eventually, though they do still time out once or twice before 
>> eventually getting through.
>> Generally these emails do show as SPF/DKIM/DMARC PASS in gmail.
>> This report is rather vague, but we do have further examples, logs, pcaps.
>> Is someone from google on this list able to help investigate this problem 
>> with us please? I can pass examples and pcaps privately.
>> Thanks!
>> Andrew, AS20712 aa.net.uk
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Sending to google/gmail - timeouts mainly with larger (~400k+) emails

[Maarten Oelering via mailop]

Hi,

Sending 400K mailings with Exim, hats off! 
With large mailings you will always see some messages failing due to various 
reasons. Even with more powerful MTAs. 
I would expect that the 1000 mails are left in the queue due to the to 454 … 
over quota replies from Gmail. 
Are they all connection errors? Then I would suspect a problem on your side. An 
SMTP trace could help to diagnose the issue.

Maarten,
Postmastery

> On 2 Dec 2021, at 13:50, Andrew Hearn via mailop  wrote:
> 
> Hello,
> 
> We're a UK ISP, and relay email for our customers as well as send our 
> customers emails such as invoices.
> 
> We currently have about 1,000 emails queued for google accounts and these are 
> failing with a timeout, eg from exim:
> 
> 2021-12-02 11:48:05 1msize-005feQ-DI H=gmail-smtp-in.l.google.com 
> [142.250.13.26] TLS error on connection (send): The TLS connection was 
> non-properly terminated.
> 
> 2021-12-02 11:48:05 1msize-005feQ-DI H=gmail-smtp-in.l.google.com 
> [142.250.13.26]: SMTP timeout after sending data block (525043 bytes 
> written): Connection timed out
> 
> Based on past experience, eventually, the emails may will through.
> 
> This is also intermittent, as sending to my own gmail address tends to get 
> through eventually, though they do still time out once or twice before 
> eventually getting through.
> 
> Generally these emails do show as SPF/DKIM/DMARC PASS in gmail.
> 
> This report is rather vague, but we do have further examples, logs, pcaps.
> 
> Is someone from google on this list able to help investigate this problem 
> with us please? I can pass examples and pcaps privately.
> 
> Thanks!
> 
> Andrew, AS20712 aa.net.uk
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google Postmaster Tools - No data since October 4th

[Maarten Oelering via mailop]

We are monitoring hundreds of domains in GPT. Some of these domains never 
showed any data.
But since October 8 all domains are returning 404 errors on the GPT API. So 
something is wrong at Google.

Maarten

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM validation behaviour when multiple _domainkey TXT records are present

[Maarten Oelering via mailop]

Our free tester at emailaudit.com  checks SPF, DKIM, 
alignment, and DMARC.

Maarten
Postmastery

> On 2 Jun 2021, at 14:14, Simon Arlott via mailop  wrote:
> 
> I've yet to find a comprehensive DMARC tester that will handle all of the 
> nuances like RFC5322.From and RFC5321.MailFrom needing to be aligned before 
> SPF can be considered...

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reliability of DMARC reports?

[Maarten Oelering via mailop]

The reports can be very helpful. But they are not that intuitive.

Make sure you understand the the following. The results of SPF and DKIM sec 
(without considering alignment) are given in 
/. The results of SPF and DKIM in DMARC 
context (with alignment considered) are in /. 

SPF breaks with forwarding. So make sure both SPF and DKIM validate, and are 
aligned. Even though DMARC will validate when either one passes.

Maarten

> On 14 Mar 2021, at 08:43, Hans-Martin Mosner via mailop  
> wrote:
> 
> Hello,
> 
> due to the recent GMX mail rejection incident (for which I still don't have a 
> satisfactory explanation from GMX) I've
> enabled DMARC on our mail server in the hopes of getting better 
> deliverability.
> 
> But some of our outgoing mails were rejected, and the aggregate DMARC reports 
> we were getting weren't too helpful (again
> :-( )
> 
> Since this is a completely new area for me, I'm trying to make sense of the 
> report content, and of course I'm trying to
> adjust our DNS records to limit damage.
> 
> As far as I understand, the report contains a copy of our published policy as 
> well as records per sending IP. In the
> report I'm just looking at, it's stated that our domain and subdomain policy 
> is "reject" although I changed it to
> "quarantine" within the same DNS update in which I changed the rua address 
> from a generic one to a special receiver
> address, so I know the reporter must have read the new version of the DMARC 
> DNS record because they sent to that special
> address.
> 
> The report also claims that SPF failed, although our SPF record included the 
> outgoing mailserver from the beginning, of
> course.
> 
> So this report looks like a red herring to me - not enough information to 
> debug what may have been wrong (ok for an
> aggregate report) but also containing highly questionable data.
> 
> I'm about to switch off DMARC off again or at least change the policy to 
> "none" as it seems to hurt more than help.
> 
> What's your experience with reliability of DMARC reports? Mostly helpful? Too 
> much nonsense?
> 
> Cheers,
> Hans-Martin
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] JSON mail server logs ?

[Maarten Oelering via mailop]

We have built integrations with many MTA’s and SMTP services. I would rather 
see all information available in the logs of the Exim, than a common scheme 
provided by all MTAs.
It would also be helpful is the logs report on “transaction” level (deferral, 
bounce, delivery) and not on process level like Postfix where you need to 
stitch log lines together to get the full context.
An example of an MTA with JSON logs (in NDJSON format) is PowerMTA: 
https://www.sparkpost.com/docs/tech-resources/pmta-50-features/ 


Maarten

> On 20 Nov 2020, at 09:01, Andrew C Aitchison via mailop  
> wrote:
> 
> 
> The has been a request for Exim to have the ability to save the
> server mainlog in json format 'to make it easier to "consume" it'
>https://bugs.exim.org/show_bug.cgi?id=2610
> 
> The developers would like to use a "standard" schema;
> does anyone use or know of a JSON schema for mail servers logs ?
> 
> Thanks,
> 
> -- 
> Andrew C. Aitchison   Kendal, UK
>   and...@aitchison.me.uk
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone contact to DigiByte Media B.V. Utrecht (maybe linked to megafon.ru) or knows how to get them disconnected by Google?

[Maarten Oelering via mailop]

Hi Benoit,

I suggest to report the spam mails to the Dutch authorities here:
https://www.acm.nl/nl/onderwerpen/telecommunicatie/meld-spam-bij-de-acm

Regards,
Maarten

> On 12 Nov 2020, at 14:26, Benoît Panizzon via mailop  
> wrote:
> 
> Hi Gang
> 
> We see a constant stream of spam mails advertising erotica websites
> run by DigiByte Media B.V. Utrecht, NL and hosted @ Goole Could.
> 
> Despite DigiByte Media B.V. stating, they react to every complaint
> within a couple of work days I have NEVER EVER got a reply from them o
> an incident.
> 
> Now we have a case were DigiByte Media B.V. (or whoever benefits
> of those emails) used a phished account at a car dealer to send those
> emails. The car dealer of course has nothing to do with them.
> 
> The IP from which the account was abused belongs to megafon.ru
> 
> BTW, we run a spamtrap/honeypot and megafon.ru is one of the TOP ISP
> constantly hitting our spamtrap, attempting to relay emails with
> obviously phished credentials.
> 
> Of course the megafon.ru abuse desk also does not react.
> 
> I guess the last resort would be to get Google to disconnects its
> clearly abusive cloud customer. But Google has no ears for this probably
> because the emails were not sent via their infrastructure.
> 
> Anyone maybe has a contact @ Google to notify them of this long lasting
> nuisance? Or maybe even someone know who is behind DigiByte Media BV?
> 
> -- 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon- @ HomeOffice und normal erreichbar
> -- 
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
> 
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Issues at Orange

[Maarten Oelering via mailop]

Mailbox provider Orange in France currently has issues with their 
infrastructure. They reject incoming mail with:

421 # ID # ME Service refused. Please try again later. Service refused, please 
try later. OFR_108; [108]

We were told that they are asking the senders to pause mailing to their domains 
(orange.fr , wanadoo.fr ).

Maarten 
Postmastery

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Reg. Bounces at Yahoo / AOL

[Maarten Oelering via mailop]

Hi Vaibhav,

We saw this reply appear 1-2 months ago. I think you should treat it as invalid 
address, so hard bounce.

Maarten

> On 11 May 2020, at 04:34, Vaibhav via mailop  wrote:
> 
> Hi Everyone,
> 
> Recently we observed below error while delivering emails to Yahoo / AOL 
> recipients. 
> 
> Is it expected or some error ?
> 
> SMTP Error : 554 delivery error: dd Not a valid recipient - 
> 
> Does anyone noticed the same ?
> 
> --Vaibhav
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail Postmaster Tools Issue?

[Maarten Oelering via mailop]

Hi John,

Yes we see the same issue across many senders.

Maarten Oelering
Postmastery

> On 12 Dec 2019, at 17:12, John Rowan via mailop  wrote:
> 
> Hi all,
> 
> When I checked our domains/subdomains today, I noticed that beginning today 
> *all* of our IP reputations were bad. Previously they had been a mix of high 
> or medium. This is across dozens of sites/IP's. The domain reputations remain 
> at high or medium. We haven't seen a drop in 1 day opens, or any other 
> apparent problems.  So, I'm thinking this may just be a reporting problem 
> within the tool.
> 
> Anyone seeing something similar?
> 
> Thanks!
> 
> --
> John Rowan
> Operations Architect -- Email/Messaging
> Match
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Reasons to add plain text alternative to email?

[Maarten Oelering via mailop]

I want to thank all contributors to this discussion for their feedback.

What I learned from this:
- There are still people that prefer plain text.
- Text alternative may be used by accessibility tools.
- Text alternative should be complete and readable.
- For bulk mail html only should work just fine.

Thanks,
Maarten Oelering
Postmastery


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Reasons to add plain text alternative to email?

[Maarten Oelering via mailop]

Multipart messages with html and text alternatives are generally considered 
best practice. Senders with html templates should add a text version is the 
common believe.

But it's almost 2020, and we were wondering if there's still a good reason for 
adding plain text to a html message. Is there a significant audience reading in 
plain text? Is plain text important for accessibility? Because SpamAssassin 
says so?

Would be great to get feedback from this diverse and knowledgable community.

Thanks,
Maarten Oelering
Postmastery


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Suggestions for VPS providers in Europe?

[Maarten Oelering via mailop]

I have good experience using TransIP VPS. 
Port 25 block can be cleared with a button and reverse DNS is easy to setup.
But I would not use any VPS for larger volumes or ESP services.

Maarten

> On 3 Dec 2019, at 00:59, John Levine via mailop  wrote:
> 
> I warned a guy away from Hetzner and OVH if he wants to send mail so he
> reasonably asked what VPS provider in Europe is better for sending mail.
> 
> Any suggestions?
> 
> Also, how different is it if at OVH and Hetzner if you use their outbound
> mail servers rather than trying to send directly?
> 
> R's,

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Microsoft delivery failures - 5.4.4 (unable to route: no mail hosts for domain)

[Maarten Oelering via mailop]

Hi all,

On the 5th of October we noticed a spike in delivery failures at domains 
hotmail.com, outlook.com, msn.com, and live.com. 
The failures were caused by DNS lookup errors reported by the MTA as "5.4.4 
(unable to route: no mail hosts for domain)”. This is problematic as the error 
is reported as hard bounce causing many addresses to be suppressed.

Delivery to other Microsoft domains was fine. The issue also occurred between 
20-24 September and now again on the 5th of October. Since then, delivery has 
been normal.

We noticed that Microsoft is using DNS entries for MX hosts with a very short 
TTL (30 sec) and rotating IP addresses. We think the short TTL may be related 
to the issue. Aggressive caching of the MX-es seemed to help.

Did anyone else experience this issue, or knows about recent DNS changes at 
Microsoft?

Thanks,
Maarten


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail Postmaster IP reputation shift on July 2nd

[Maarten Oelering via mailop]

We see many unrelated senders going red on July 3 (CET). Definitely looks 
like something happened on the side of Google.

Maarten Oelering
Postmastery

> On 5 Jul 2019, at 18:29, Laura Atkins via mailop  wrote:
> 
> I’m seeing jumps on a couple of my clients, but no change on others. 
> 
> laura 
> 
> 
>> On 5 Jul 2019, at 16:37, Scott Southard via mailop > <mailto:mailop@mailop.org>> wrote:
>> 
>> Seeing a jump in red IPs on our end as well over the past 2 days. 
>> Previously, everything had been trending in a very positive manner. We're 
>> all kind of perplexed over here.
>> 
>> On Fri, Jul 5, 2019 at 9:55 AM Brett Schenker via mailop > <mailto:mailop@mailop.org>> wrote:
>> I've noticed a shift since mid-June but our IPs improved overall and have 
>> done so even more during that time frame. More are green now than before.
>> 
>> On Fri, Jul 5, 2019 at 9:38 AM Michael Ellis via mailop > <mailto:mailop@mailop.org>> wrote:
>> One of my clients is also seeing this for some of his custoers (ESP)
>> 
>> 
>> >  Seeing the same symptom, but as of 7/3.  Quick spot check so far isn't
>> > showing performance problems... hopefully an isolated reporting issue.
>> > Allen K
>> >
>> >
>> > On Friday, July 5, 2019, 07:58:53 AM CDT, Tracey Crawford via mailop
>> > mailto:mailop@mailop.org>> wrote:
>> >
>> >  I am also seeing a drop from green to red for some of my customers on
>> > July 2nd.
>> > Tracey CrawfordLead Deliverability Analyst, SparkPost
>> >
>> > On Fri, Jul 5, 2019 at 7:02 AM > > <mailto:mailop-requ...@mailop.org>> wrote:
>> >
>> > Send mailop mailing list submissions to
>> > Â  Â  Â  Â  mailop@mailop.org <mailto:mailop@mailop.org>
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> > Â  Â  Â  Â  https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
>> > <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop>
>> > or, via email, send a message with subject or body 'help' to
>> > Â  Â  Â  Â  mailop-requ...@mailop.org <mailto:mailop-requ...@mailop.org>
>> >
>> > You can reach the person managing the list at
>> > Â  Â  Â  Â  mailop-ow...@mailop.org <mailto:mailop-ow...@mailop.org>
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of mailop digest..."
>> >
>> >
>> > Today's Topics:
>> >
>> > Â  Â 1. Re: Can't sign up for MSFT SNDS? (Hetzner Blacklist)
>> > Â  Â 2. Gmail Postmaster IP reputation shift on July 2nd (Mathieu Bourdin)
>> > Â  Â 3. Re: Gmail Postmaster IP reputation shift on July 2nd
>> > Â  Â  Â  (Richelo Killian)
>> >
>> >
>> > --
>> >
>> > Message: 1
>> > Date: Thu, 4 Jul 2019 14:25:03 +0200
>> > From: Hetzner Blacklist > > <mailto:blackl...@hetzner.com>>
>> > To: mailop@mailop.org <mailto:mailop@mailop.org>
>> > Subject: Re: [mailop] Can't sign up for MSFT SNDS?
>> > Message-ID: > > <mailto:c641df7b-0165-e1f1-ef58-1e4ca449d...@hetzner.com>>
>> > Content-Type: text/plain; charset=utf-8
>> >
>> > Hi Al,
>> >
>> > I just tried adding a /16 that we bought a while ago but aren't using
>> > yet. There were no issues adding it to the SNDS.
>> >
>> > Having said that, I've often had issues in the past adding ranges. Most
>> > of the time simply waiting and trying again a few hours or days later
>> > worked.
>> >
>> > Make sure the WHOIS data is correct, since Microsoft relies heavily on
>> > that.
>> >
>> > Also, if you're able to, maybe you can signup using the AS number, I've
>> > never had issues with that.
>> >
>> > Kind regards
>> >
>> > Bastiaan van den Berg
>> >
>> >
>> > Am 04.07.2019 um 13:00 schrieb Al Iverson > > <mailto:aiver...@wombatmail.com>>:
>> >> Anybody else having trouble signing new ranges up for Microsoft SNDS?
>> >> When submitting the access request, I get a generic "We're sorry! An
>> >> error has occurred.
>> >
>> >
>> >
>> > --
>> >
>> > Message: 2
>> > Date: Fri, 5 Jul 2019 08:12:17 +
>> > From: Mathieu Bourdin mail

Re: [mailop] deactivation of hard bounces

[Maarten Oelering]

Hi Marco,

I am curious what false positives you encountered.

We suggest to classify bounces using multiple features, the text, the
enhanced status code, and the status code. If the bounce is clearly an
invalid address, then remove it after the first bounce. For example when
the text contains “mailbox” or a synonym, and “unknown” or a synonym.
Bounces which are ambiguous, or with inconsistent features should be
treated as soft bounce.

Maarten
Postmastery

On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop <
mailop@mailop.org> wrote:

> Hello,
>
> We at contactlab are considering a change in the deactivation of hard
> bounces.
> Currently, we suppress not existing mailboxes at the first hit.
>
> We are aware of a small percentage of false positives.
>
> Recent admissions criteria for Certified Senders states:
> "The CSA sender must take email addresses from mailing lists, if, after
> sending to this address,
> the mailbox is identified as non-existent; at the latest, however, this
> must occur after three hard
> bounces".
>
> We are evaluating to remove not existing mailboxes from the lists of our
> clients after the second hit instead of the first one.
>
> Do you have any considerations, suggestions about this?
>
> Marco
>
>
> Marco Franceschetti
> Head of Deliverability | ContactLab
> marco.francesche...@contactlab.com
> Via Natale Battaglia, 12 | Milano
> 
> contactlab.com/it
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is SenderID deprecated? (Udeme Ukutt)

[Maarten Oelering]

I was just hoping I would never have to answer questions “… and what about 
Sender ID?” anymore.

And then this SMTP error popped up in the logs of a certain sender:

550 5.7.1 Sender ID (PRA) Not Permitted

Sigh...

Maarten Oelering
Postmastery

> On 5 Oct 2018, at 10:31, Benjamin BILLON  wrote:
> 
> Thanks for the reply! 
>  
> Although this apparently isn't new, I'll consider this a milestone as we just 
> removed spf2.0 records from our settings guidelines.
>  
> Smartscreen for email is deprecated on Exchange onPrem ... but isn't it also 
> in O365 and Outlook.com <http://outlook.com/>, since those rely on EOP? The 
> copy/pasted answers from the Outlook.com <http://outlook.com/> Support still 
> mentions Smartscreen heavily.
> That being said, the said Support is also named " Hotmail Sender Support ", 
> maybe they didn't get the memo about Outlook.com <http://outlook.com/> =)
>  
> Cheers, 
> --
> Benjamin
>  
> From: mailop mailto:mailop-boun...@mailop.org>> 
> On Behalf Of Mihai Costea
> Sent: jeudi 4 octobre 2018 19:21
> To: mailop@mailop.org <mailto:mailop@mailop.org>
> Subject: Re: [mailop] Is SenderID deprecated? (Udeme Ukutt)
>  
> Hi
> 
>  
> 
> There are no reasons to worry about old Exchange onPrem servers spam filters 
> as nobody relies on them anymore.  
> 
> We stopped issuing filter updates two years ago and the filter itself stopped 
> receiving new features well before that.  
> 
> https://blogs.technet.microsoft.com/exchange/2016/09/01/deprecating-support-for-smartscreen-in-outlook-and-exchange/
>  
> <https://blogs.technet.microsoft.com/exchange/2016/09/01/deprecating-support-for-smartscreen-in-outlook-and-exchange/>
>  
> 
> "no record" never had any impact in the SenderID agent.  
> 
> "Auth fail -> hard fail" was not wise policy to enable due to complex routing 
> false positives.  
> 
> Auth pass was fed into the smartscreen (content filter) in Exchange as a 
> positive email feature, assuming legit senders will auth more than spammers.  
> Which was a bad assumptions as spammers were in fact the earliest adopters.
> 
> No record never had any impact.
> 
>  
> 
> Everything is SPF these days in both O365 and Outlook.com 
> <http://outlook.com/>.  Some headers might mention PRA/PRD as the entity 
> among all the sender related headers that was selected to do the check 
> against, but this selection is done the SPF way.
> 
>  
> 
> From any practical pov SenderID is deprecated.  
> 
> For the email historians, Terry had at least a hundred blogs on auth over the 
> years.  
> 
> e.g. 
> https://blogs.msdn.microsoft.com/tzink/2007/07/29/sender-authentication-part-17-hazards-of-senderid-and-spf/
>  
> <https://blogs.msdn.microsoft.com/tzink/2007/07/29/sender-authentication-part-17-hazards-of-senderid-and-spf/>
>  
> 
> Sender authentication part 17: Hazards of SenderID and SPF ... 
> <https://blogs.msdn.microsoft.com/tzink/2007/07/29/sender-authentication-part-17-hazards-of-senderid-and-spf/>
> blogs.msdn.microsoft.com <http://blogs.msdn.microsoft.com/>
> Both SenderID and SPF have their critics. I’d like to touch on two potential 
> problems with them: the first is the issue of email forwarding. There’s no 
> official standard on how email is to be forwarded (in terms of rewriting the 
> headers). Suppose that Mail Server A sends the message and everything 
> complies with SenderID...
>  
>  
> 
>  
> 
> > Message: 3
> > Date: Thu, 4 Oct 2018 08:45:58 +
> > From: Benjamin BILLON mailto:bbil...@splio.com> 
> > <mailto:bbil...@splio.com <mailto:bbil...@splio.com>>>
> > To: "mailop@mailop.org <mailto:mailop@mailop.org> <mailto:mailop@mailop.org 
> > <mailto:mailop@mailop.org>>" mailto:mailop@mailop.org> 
> > <mailto:mailop@mailop.org <mailto:mailop@mailop.org>>>
> > Subject: [mailop] Is SenderID deprecated?
> > Message-ID:
> > 
> >  >  
> > <mailto:he1pr0602mb3435cb10e9fb9da2ebdcbdcbb4...@he1pr0602mb3435.eurprd06.prod.outlook.com>
> >  
> > <mailto:he1pr0602mb3435cb10e9fb9da2ebdcbdcbb4...@he1pr0602mb3435.eurprd06.prod.outlook.com
> >  
> > <mailto:he1pr0602mb3435cb10e9fb9da2ebdcbdcbb4...@he1pr0602mb3435.eurprd06.prod.outlook.com>>>
> > 
> > Content-Type: text/plain; charset="utf-8"
> > 
> > The RFC 4406 is not obsolete, only experimental.
> > 
> > In the past, Hotmail/Live heavily relied on it, but it's not even visible 
> > in Outlook's headers anymore (advantageously replaced by DKIM, and DMARC).

Re: [mailop] Mailbox full impact on delvierability

[Maarten Oelering]

Hi Andy,

We typically configure the MTA to bounce emails when the provider reports 
“mailbox full” with a 4XX status code. Some systems even report “user unknown” 
with a 4XX status code.
Not so much to protect reputation, but to save resources, as I have never seen 
such a message deliver after x retries.

In PowerMTA this can be done by using “bounce-rcpt” action in the 
smtp-pattern-list. For example:
reply /452 4.2.2 The email account that you tried to reach is over quota./ 
bounce-rcpt

Best,
Maarten

> On 18 May 2018, at 11:15, Andy Onofrei via mailop  wrote:
> 
> HI, 
>  
> I wanted for a long to hear some opinions about the impact which “mailbox 
> full” soft bounces are having on the reputation.
> If that should be treated as a hard bounce ( especially at big 4 Gmail, 
> Yahoo, Hotmail ,Aol).
>  
> I have seen it retried 30-40 times until transformed into a hard bounce by 
> the sending smtp server.
>  
> I know that this error is a red flag for a bad list hygiene , however from 
> the point of view of the ESP .. its better just not to be retried?
>  
> Any thoughts are welcome.
>  
> Andrei Onofrei
> Dynamics 365 Email Deliverability Engineer
> andrei.onof...@microsoft.com  | +420 720 
> 359 205
> BBC Delta Building, Vyskočilova 1561/4a, 140 00 Prague, The Czech Republic
> 
>  
>  
> ___
> mailop mailing list
> mailop@mailop.org 
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
> 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mail Transfer Agent Alternatives

[Maarten Oelering]

Let’s stick to the facts.

The PowerMTA license fee is not (only) for support. It will also provide you 
with new releases every couple of months. These new releases provide new 
functionality such as double DKIM, TLS optimizations, automatic MX rollup, and 
more. If this is worth the money is a personal judgement. 
The license fee is a flat fee, there is no “pay by email”. For Message Systems 
PowerMTA is an important product and the preferred on-premise software. 
Momentum is for complex setups which also need strong inbound functionality. 
Sparkpost is for everyone who prefers not to invest into their own system and 
having to manage it.
There was one important security update, after the discovery of Heartbleed. 
It’s not Port25 that forced senders to get updates. It was just sensible to 
upgrade all software using openssl.

Maarten Oelering
Postmastery

> On 5 Feb 2018, at 09:53, David Hofstee <opentext.dhofs...@gmail.com> wrote:
> 
> So yes, Message Systems have a model that they want you to pay per email. 
> Maybe not yet, but in the future. If it is on premise or in the cloud, they 
> don't care. To do that they took over Port25. You are forced to get updates 
> due to the fact that you need security updates.
> 
> Some ESPs have started to implement their own mta (Sendgrid, haven't kept 
> tabs on others). There is no open source mta that is fast enough. And all 
> ESPs don't seem to want to cooperate to create one (it doesn't hurt enough, 
> price wise). You don't want to create a spamming tool either.
> 
> Yours,
> 
> 
> 
> David
> 
> 
> 
> On 5 February 2018 at 08:57, Benjamin BILLON <bbil...@splio.com 
> <mailto:bbil...@splio.com>> wrote:
> Hello,
> 
>  
> 
> Everything is always too expensive! However I can't say which of the software 
> you mentioned is more expensive.
> 
>  
> 
> It doesn't seem GreenArrow and PowerMTA are providing the same thing. 
> PowerMTA is an enhanced MTA, GreenArrow seems to have that, somewhere, but 
> sells services too?
> 
> What features are you comparing exactly?
> 
> Are you looking for SparkPost instead of on-promise PMTA?
> 
>  
> 
> Anyway I believe another competitor would be MailerQ https://www.mailerq.com/ 
> <https://www.mailerq.com/>
>  
> 
> --
> 
> Benjamin
> 
>  
> 
>  
> 
> De : mailop [mailto:mailop-boun...@mailop.org 
> <mailto:mailop-boun...@mailop.org>] De la part de Emre Üst |euro.message|
> Envoyé : lundi 5 février 2018 15:23
> À : mailop@mailop.org <mailto:mailop@mailop.org>
> Objet : [mailop] Mail Transfer Agent Alternatives
> 
>  
> 
> Hello everyone ,
> 
> We are using Powermta(Port25) but their support service fee is rediciously 
> high . We are looking for new mta . Could anyone recommend to Port25 
> altenatives ?
> 
> What are you thinking about GreenArrow - drh.net <http://drh.net/>  ?
> 
> Thank you 
> 
> 
> --
> 
> 
> 
> 
> 
> EMRE ÜST
> 
> Deliverability Specialist
> 
>  
> 
> t.   +902123430739 <tel:+90%20212%20343%2007%2039>
> f.   +902123430742 <tel:+90%20212%20343%2007%2042>
> 
> email: emre@euromsg.com <mailto:%23>
> skype: user_name
> web: euromsg.com 
> <http://www.euromsg.com/?utm_source=email-signature_medium=email>
> Yeşilce Mh. Yunus Emre Cd. Ada İş Mrk. No: 4 Zemin Kat 4. Levent / İstanbul
> 
>  
> 
> 
> 
>  <http://www.linkedin.com/company/euro-message>   
>  <https://www.facebook.com/euromessage>   
>  <https://twitter.com/euromessage>
>  <http://blog.euromsg.com/>   
> 
> 
>  <http://www.relateddigital.com/>
>  <http://www.euromsg.com/?utm_source=email-signature_medium=email>
>  <http://visilabs.com/?utm_source=email-signature_medium=email>   
>  <http://www.semanticum.com/?utm_source=email-signature_medium=email> 
>  <http://madebycat.com/?utm_source=email-signature_medium=email>  
>   
>   
>  <http://www.relateddigital.com/?utm_source=email-signature_medium=email>
>   
>  
> 
> This e-mail message may contain confidential or legally privileged 
> information and is intended only for the use of the intended recipient(s). 
> Any unauthorized disclosure, dissemination, distribution, copying or the 
> taking of any action in reliance on the information herein is prohibited. 
> E-mails are not secure and cannot be guaranteed to be error free as they can 
> be intercepted, amended, or contain viruses. Anyone who communicates with us 
> by e-mail is deemed to have accepted these risks. Related Digital is not 
> responsible for errors or omissions in this message and denies any

Re: [mailop] Message recipients column in SNDS

[Maarten Oelering]

Hi David,

Thanks for sharing. So first they tell you to "try again later”, and then they 
accuse you of namespace mining…

Perhaps a workaround is to reduce the RCPT attempts by putting the outlook.com 
queue into backoff after “Server busy. Please try again later from”?

Maarten
Postmastery

> On 13 Dec 2017, at 11:23, David Hofstee  wrote:
> 
> It is even so bad that Microsoft support misinterprets the statistics... From 
> a Microsoft ticket (regarding a dedicated IP):
> 
> We have investigated your deliverability issue (case ticket: SR#1407666085). 
> At the current time, your IP address (149.235.15.xx) is blocked for namespace 
> mining behavior and is not eligible for mitigation.
>  
> Please understand, namespace mining behavior is not the same as sending spam. 
> It is not caused by sending large volumes of email. Namespace mining behavior 
> is identified when Outlook.com sees requests to validate large numbers of 
> possible email addresses without sending (or attempting to send) equal 
> numbers of emails. Namespace mining is usually the result of a compromise (of 
> the server, the network, or some user accounts), or a misconfiguration in the 
> email system setup.
>  
> This is the most recent incidents of namespace mining behavior.
>  
>  IP address: <149.235.15.124>
> Day
> # Mails
> # RCPTs
> #Diff
> 11/14/2017
> 12,098
> 28,021
> 15923
>  
>  
> As you can see in the table above the number of RCPT requests is 
> significantly higher than the number of actual emails sent. In normal 
> situations, these numbers of RCPT requests would be very close to the number 
> of emails sent. It is important that you take steps to investigate the 
> namespace mining behavior. The root causes must be addressed as soon as 
> possible.
> 
> 
> Obviously my logs showed that only '4xx' deferrals accounted for the 
> difference. The 5xx bounce rate was well under 1%.
> 
> David
> 
> On 2 November 2017 at 21:33, Emre Üst |euro.message|  > wrote:
> Hello Maarten , 
> 
> Errors you have received,  returned to normal?
> 
> We too ,detected large difference between these numbers,
> 
> RCPT
> commands  111829
> 
> DATA
> commands 106093
> 
> Message
> recipients 1215
> 
>  and we only see 
> 
> 451 4.7.500 Server busy. Please try again later from []. (AS3114) 
> [AM5EUR02FT027.eop-EUR02.prod.protection.outlook.com 
> ]" while 
> connected from () to hotmail-com.olc.protection.outlook.com 
>  (104.47.4.33)
> 
> Thank you 
> 
> -- 
> 
> 
> EMRE ÜST
> 
> 
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org 
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
> 
> 
> 
> 
> 
> -- 
> --
> My opinion is mine.
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] 5.7.1 bounce codes

[Maarten Oelering]

I would not say exclusively. Code 5.7.1 is also used for “Relay access denied” 
for example. This bounce is often caused by typo domains that end up at a 
default MX. From my experience, it is better to match a bounce category first 
on the text, and then on the status code.

For the actions, I agree that bounces due to “blocks” etc should not be counted 
against the recipient (which is typically implied by “soft”). There should be 3 
different actions related to bounces: remove recipient immediately (“hard”), 
remove recipient after N consecutive bounces (“soft”), and count on campaign 
level but ignore on recipient level.

Maarten Oelering
Postmastery

> On 11 Dec 2017, at 16:41, Alexander Burch <abu...@activecampaign.com> wrote:
> 
> 5.7.1 codes are used exclusively for policy blocks (IP blacklisted, content 
> deemed spammy etc).
> 
> Gmail uses it for DMARC rejections.
> 
> Hotmail also uses 5.7.1 when an IP is outright blocked.
> 
> This type of bounce confuses me a little. It certainly shouldn't be used to 
> mark the recipient as invalid, and it shouldn't be treated as a soft bounce 
> either (using the traditional 3 strike rule). But most ESPs have 5.7.1. 
> listed as a "hard bounce" in their documentation. That seems wrong.
> 
> Of course you will need to address the actual block/policy issue, so these 
> bounces are important to monitor. But the bounce code shouldn't affect the 
> recipients "status" in any email system, which is what a "hard bounce" would 
> do.
> 
> My conclusion is that these types of bounces should have no bearing on the 
> recipient's "status", and they shouldn't be classified as "hard" or "soft", 
> but rather ignored.  Has anyone else come to a different conclusion?
> 
> Thanks,
> Alex
> 
> 
>   
> Alex Burch
> ActiveCampaign / Deliverability Lead
> (800) 357-0402
> abu...@activecampaign.com <mailto:abu...@activecampaign.com>
> 1 N. Dearborn St., Chicago , Il 60602, United States
>  <https://www.facebook.com/activecampaign>  
> <http://www.twitter.com/activecampaign>  
> <https://www.linkedin.com/company/activecampaign-inc->___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] A proposal for automated management of mail sending limits

[Maarten Oelering]

I agree with Ken that the need for guidelines is well intended. Many legitimate 
senders want to avoid pushing too hard and wasting resources on both ends. But 
I think exchanging specific limits between receiver and sender via a new 
mechanism is infeasible, and may not even be needed.

Why not start with bringing some clarity to SMTP replies and sender guidelines? 
Enhanced status codes or clear messages can tell the sender to (temporarily) 
stop sending from an IP or domain. Professional MTAs can already handle this 
using adaptive delivery settings.

I know that some are seeking the exact message rate that they are allowed to 
send, but reputation and throttling is not exact science. I don't see what's 
wrong with sending a burst of messages, stopping at the first reputation error, 
and resuming after some predefined delay. 

Maarten Oelering
Postmastery

> On 14 Nov 2017, at 10:05, David Hofstee <opentext.dhofs...@gmail.com> wrote:
> 
> Hi Ken,
> 
> I agree that it is a problem. I do think this could be done at connection 
> time only. Of of the tricky parts is that all mail servers I know have 
> trouble with throttling. They can throttle on a (set of) recipient domain(s), 
> but not on a cluster of MXs from e.g. Microsoft. E.g. they put hotmail, 
> outlook, msn in one queue but forget to put email from businesses that use 
> Office365 in the same queue. In order to fix that more easily, the mail 
> server should disclose an identifyer where the volume should be counted 
> under. In that way a server could know when a new connection/domain is part 
> of that throttling (and shut that connection down if necessary).
> 
> e.g.
> 250-THROTTLING-IDENTIFIER hotmail-scoijwesoifjwhps [QUIT here if you 
> realize it would violate the throttling quota]
> 250-THROTTLING-CONNECTIONS 10
> 250-THROTTLING-EMAILS-CONNECTION 20
> 250-THROTTLING-RATE-MINUTE 20
> 250-THROTTLING-RATE-HOUR 200
> 250-THROTTLING-RATE-DAY 500
> 250-THROTTLING-DATASIZE-CONNECTION 100MB 
> 
> or
> 250-THROTTLING-IDENTIFIER hotmail-scoijwesoifjwhps
> 250-THROTTLING-GRAYLISTING-MINUTE 120
> 
> It would then be up to the MTA to group all these domains under that 
> identifier and abide to the throttling requirements. One thing is that these 
> throttling parameters must be adjustable in the same connection (so they can 
> react to emails you send).
> 
> Yours,
> 
> 
> David
> 
> 
> 
> On 13 November 2017 at 20:41, Ken O'Driscoll <k...@wemonitoremail.com 
> <mailto:k...@wemonitoremail.com>> wrote:
> On Mon, 2017-11-13 at 09:58 -0800, Steve Atkins wrote:
> > (If this proposal were coming out of a group of major ISPs or a few of
> > the larger inbound mail appliance or service providers as "this is
> > something we want to do" I'd consider it differently than it coming from
> > the high volume email deployer side of things. There's a long history of
> > bulk mail senders going "just tell us exactly what we need to do so
> > you'll deliver our email, and we'll do it!" and it's not something that
> > ever really leads anywhere.)
> 
> I understand this sentiment but I believe these days the only reason that
> most of them want to know "what the rules are" is because they want to
> comply but it's often not evident how. 
> 
> The quality (and existence) of postmaster portals and knowledge bases
> varies greatly. The informative value of SMTP error messages varies
> greatly. The ability to communicate with a postmaster varies greatly. 
> 
> You can't really blame them (particularly the smaller ones) for sometimes
> being confused about what's needed to get their transactional or opt-in
> email into inboxes.
> 
> Ken.
> 
> -- 
> Ken O'Driscoll / We Monitor Email
> t: +353 1 254 9400 <tel:%2B353%201%20254%209400> | w: www.wemonitoremail.com 
> <http://www.wemonitoremail.com/>
> 
> Need to understand deliverability? Now there's a book:
> www.wemonitoremail.com/book <http://www.wemonitoremail.com/book>
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org <mailto:mailop@mailop.org>
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
> <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop>
> 
> 
> 
> -- 
> --
> My opinion is mine.
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Message recipients column in SNDS

[Maarten Oelering]

Hi,

We have been tracking the numbers on SNDS for a few years. One of the metrics 
we monitor is the difference between “RCPT commands” and “Message recipients”. 
See also the section “Message Recipients” on the SNDS FAQ page:

"This is the number of recipients on messages actually transmitted by the IP. 
With well-behaved mailers, there is often a small difference (a few percent) 
between the number of RCPT commands and this number, due to accounts becoming 
inactive and other such anomalies."

Previously we rarely detected a large difference between these numbers, and the 
difference was accounted for with 5XX errors. But since a few weeks we noticed 
that on multiple IPs from different senders the number of “Message recipients” 
has suddenly dropped to unexplainable low values. This would suggest a high 
rejection rate, but the number of bounces does not match up with the 
difference. And I don’t assume that Microsoft is now dropping messages on the 
floor in larger quantities. It looks like something has changed in SNDS.

Did anyone else notice a recent change in the “Message recipients” column? Or 
better yet, can someone explain how we should interpret this number now?

Thanks,
Maarten Oelering
Postmastery

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] unique/shared public DKIM keys per domain?

[Maarten Oelering]

To my knowledge reputation is tied to the “d=“ domain. The value of the key
is irrelevant with regards to reputation.
Using shared or unique key pairs is a balance between managebility and
security.

Maarten

On Mon, 9 Oct 2017 at 19:06, Alexander Burch 
wrote:

> Do major ISP check the public DKIM key for reputation metrics?
>
> For example, an ESP might use domain1.com, domain2.com and domain3.com to
> sign messages for different reputation pools.
>
> If these domains all have the same public DKIM key will this "blend" their
> reputations in any way, namely at Gmail? Will Gmail see the 3 domains use
> the same public key and link their reputations?
>
> Is there any advantage of using a unique public DKIM key for each domain
> to keep the reputations compartmentalized?
>
> Thanks,
> Alex
>
>
> Alex Burch
> ActiveCampaign / Deliverability Lead
> (800) 357-0402
> abu...@activecampaign.com
> 1 N. Dearborn St., Chicago , Il 60602, United States
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Reg. Gmail Postmaster IP issue

[Maarten Oelering]

We can confirm that we see the same on other accounts. Everything is red on the 
9th.

Maarten Oelering
Postmastery

> On 11 Sep 2017, at 09:39, Vaibhav <v.kulawade...@gmail.com> wrote:
> 
> Hey,
> 
> I have observed that Gmail Postmaster showing all IP in BAD state for 9th 
> Sept report. Does anyone observed the same ?
> 
> Seems like issue from Gmail Postmaster end. 
> 
> --Vaibhav
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Maarten Oelering]

Hi David,

Given this example from an SMTP trace:

550-5.7.1 [X.X.X.X  18] Our system has detected that this message is
550-5.7.1 likely suspicious due to the very low reputation of the sending IP
550-5.7.1 address. To best protect our users from spam, the message has been
550-5.7.1 blocked. Please visit
550 5.7.1  https://support.google.com/mail/answer/188131 for more information. 
w198si19789289wmd.1 - gsmtp

I would log is as a single line, removing the folding and removing repeated 
enhanced status codes:

550 5.7.1 [X.X.X.X 18] Our system has detected that this message is likely 
suspicious due to the very low reputation of the sending IP address. To best 
protect our users from spam, the message has been blocked. Please visit 
https://support.google.com/mail/answer/188131 for more information. 
w198si19789289wmd.1 - gsmtp

Maarten Oelering
Postmastery

> On 7 Jul 2017, at 13:36, David Hofstee <opentext.dhofs...@gmail.com> wrote:
> 
> And actually, this reply has to possibly be transferred to a DSN as well (see 
> https://tools.ietf.org/html/rfc3464#section-2.3.6 
> <https://tools.ietf.org/html/rfc3464#section-2.3.6> ). Those diagnostic-code 
> field values may be multiline as well, but I presume one would leave the 
> numeric codes out.
> 
> @Stefano: Not sure if I have the time, but good tip on checking if it is a 
> bug or not.
> 
> Yours,
> 
> 
> David
> 
> On 7 July 2017 at 12:28, David Hofstee <opentext.dhofs...@gmail.com 
> <mailto:opentext.dhofs...@gmail.com>> wrote:
> Yes, I know. The subsequent RFCs 2821 and 5321 are equally unclear on this, I 
> think.
> 
> But it is a bit weird to say the human-readable text is for humans only. 
> Since it is transferred via SMTP, the RFC should define how to handle it. And 
> it is ambiguous. I would like option 1 best.
> 
> David
> 
> On 7 July 2017 at 12:03, Vladimir Dubrovin <dubro...@corp.mail.ru 
> <mailto:dubro...@corp.mail.ru>> wrote:
> 
> Hello David.
> 
> RFC 821 is outdated, use RFC 2821 as proposed or RFC 5321 as a draft for 
> SMTP. Also, there is an RFC 3463, it adds extended status codes and you 
> should probably read it.
> 
> According to RFC, only code (and potentially extended status code) are 
> intended for machine interpretation. The rest of response is a human-readable 
> text, which should not be automatically interpreted. So, as a human, you are 
> absolutely free to use it in any reasonable way. You can either leave it as 
> is, or remove status codes, or concatenate it  in the single line (since it's 
> a human readable form, you should probably replace CRLF + status code + 
> delimiter characters with a whitespace, because in human-readable form you do 
> not expect the words to be wrapped or the lines to contain extra spaces).
> 
> 07.07.2017 12:27, David Hofstee пишет:
>> Hi,
>> 
>> I've an interesting RFC question. In an SMTP reply, one can have single line 
>> or multiline replies. E.g.
>> 
>> 521 single line reply
>> 
>> or
>> 
>> 521-Line one
>> 521-Line two
>> 521 Line three
>> 
>> See also https://tools.ietf.org/html/rfc821#page-50 
>> <https://tools.ietf.org/html/rfc821#page-50> .
>> 
>> My question is: The reply is an answer that is, necessarily, formatted for 
>> SMTP. But how should the multiline answer be interpreted? What is its 
>> 'value'.
>> 
>> option 1: Remove superfluous return codes and s. E.g.:
>> 521 Line oneLine twoLine three
>> 
>> or option 2: Remove superfluous return codes but keep . E.g.
>> 521 Line one
>> Line two
>> Line three
>> 
>> or option 3: Remove superfluous s. E.g.
>> 521-Line one521-Line two521 Line three
>> 
>> or option 4: Convert s into '\r\n' to make it a one line answer. E.g.
>> 521-Line one\r\n521-Line two\r\n521 Line three
>> 
>> or option 5: Keep everything. Eg. 
>> 521-Line one
>> 521-Line two
>> 521 Line three
>> 
>> The RFC does not really state that. So I am not quite sure how that should 
>> be logged correctly. Where the formatting starts and what 'value' it is 
>> supposed to represent. When I look at other standards (e.g. http://json.org 
>> <http://json.org/>), the formatting and what it is to represent, is more 
>> clear.
>> 
>> This came up when I saw 3 different outputs in different MTA's (1,4 and 5). 
>> Not sure if I have to file a bugreport to my favorite MTA supplier.
>> 
>> Can anyone say something smart about how the reply should be seen?
>> 
>> Yours,
>> 
>> 
>> 
>> David
>> 
>> 
>> ___

Re: [mailop] DKIM for Exchange - experiences?

[Maarten Oelering]

Some suggestions have been made already, using various MTA’s. We implemented 
DMARC at a company that used Exchange together with Trustwave Secure Email 
Gateway (SEG). Adding a DKIM signature in SEG was a simple task.

Best,
Maarten Oelering
Postmastery

> On 27 Jun 2017, at 21:32, Autumn Tyr-Salvia <tyrsal...@gmail.com> wrote:
> 
> Hello,
> 
> I work in Customer Success at Agari helping big companies set up email 
> authentication. One of my coworkers asked our team about experience with DKIM 
> on Exchange, and I thought this group might be a good resource for 
> information. Here's my colleague's message:
> 
> I am working with a customer using a gateway that doesn't offer DKIM-Signing 
> currently, so I was researching options to add DKIM-Signing to Exchange.
> 
> I was able to find three:
> • EA DKIM for Exchange Server and IIS SMTP Service – product sold by 
> AdminSystem -https://www.emailarchitect.net/domainkeys 
> <https://www.emailarchitect.net/domainkeys>
> • DkimX – product sold by Netal - http://www.netal.com/dkimx.htm 
> <http://www.netal.com/dkimx.htm>
> • Exchange DKIM Signer – Open Source software - 
> https://github.com/Pro/dkim-exchange <https://github.com/Pro/dkim-exchange>
> 
> Does anyone have experience with any of them?
> 
> I'm looking at testing them in a virtual environment to get a feel for them 
> to be able to provide some informed insight, but I was wondering if anyone 
> already had worked with a customer using any of them.
> 
> MailOp friends, might you have any advice to help my colleague and his 
> customer?
> 
> 
> Thanks,
> 
> Autumn Tyr-Salvia
> tyrsalvia@gmail
> atyrsalvia@agari
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[Maarten Oelering]

Most “bulk mailers” will unsubscribe or suppress addresses if they get a SMTP 
reply or DSN which indicates that the domain or mailbox is invalid.

If the SMTP reply is a reject on a wider scope, such as IP, then they should 
look into the spam issue, but probably won’t unsubscribe the address.

Maarten Oelering

> On 22 Mar 2017, at 20:29, Petar Bogdanovic <pe...@smokva.net> wrote:
> 
> Do commercial bulk-mailers count delivery failures?
> 
> Because this:
> 
>Mar 15 17:34:53 connect: host=mtaout-202-ewr.sendlabs.com 
> addr=216.146.33.202
>Mar 15 17:34:54 helo: name=mtaout-202-ewr.sendlabs.com
>Mar 15 17:34:54 envfrom: from=bounces+petar=smokva@dynect-mailer.net
>Mar 15 17:34:54 envrcpt: rcpt=pe...@smokva.net
>Mar 15 17:34:54 envrcpt: dnsbl_query: addr=216.146.33.202 dnsbl=bl.local 
> result=127.0.0.5
>Mar 15 17:34:54 envrcpt: match: stage=envrcpt rule=1 line=21 reply=REJECT
>Mar 15 17:34:54 close
> 
>Mar 16 10:02:50 connect: host=o135.p9.mailjet.com addr=87.253.234.135
>Mar 16 10:02:50 helo: name=o135.p9.mailjet.com
>Mar 16 10:02:50 envfrom: from=x...@bnc3.mailjet.com
>Mar 16 10:02:50 envrcpt: rcpt=x...@xxx.xxx
>Mar 16 10:02:50 envrcpt: dnsbl_query: addr=87.253.234.135 dnsbl=bl.local 
> result=127.0.0.5
>Mar 16 10:02:50 envrcpt: match: stage=envrcpt rule=1 line=21 reply=REJECT
>Mar 16 10:02:50 close
> 
> has been going on for months (maybe years).
> 
> I remember mailing-lists unsubscribing addresses after N bounces, why is
> that different with bulk-mailers?
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Postmaster contact at orange.fr/wanadoo.fr?

[Maarten Oelering]

From what we have learned, the connection limits are really important. Their 
policies are:

- Maximum 3 concurrent connections per IP.
- 1000 connections per hour
- 100 messages per connection

Note that the limit of 3 concurrent connections is from IP to MX, so 
connections for wanadoo.fr <http://wanadoo.fr/> and for orange.fr 
<http://orange.fr/> add up. 
In PowerMTA this setting would do the trick: mx-connection-limit 
smtp-in.orange.fr 3

Orange is a member of Signal Spam, and reports complaints back to senders via 
Signal Spam. You can get insight into complaints per IP per day by becoming a 
Signal Spam member.

Hope this helps.

Maarten Oelering
Postmastery

> On 20 Dec 2016, at 20:52, Karen Balle <kba...@rcn.com> wrote:
> 
> Nic,
> 
> Orange has a concurrent connection limit of 3, but some of their MTAs sit 
> behind a NAT and have multiple external IPs.  We've had to set our concurrent 
> connections to 1, which has helped immensely.  If that doesn't work out, drop 
> me a line and I'll see if I can get a better contact for you.
> 
> Karen
> 
> On Mon, Dec 19, 2016 at 8:22 AM, Webb, Nic via mailop <mailop@mailop.org 
> <mailto:mailop@mailop.org>> wrote:
> Hello:
> 
>  
> 
> I’m trying to reach someone at Orange. Over the last 4 days, we’re seeing a 
> significant number of throttling messages (around 300,000 over the last 24 
> hours) like the following:
> 
>  
> 
> 421 mwinf5c07 ME Service refuse. Veuillez essayer plus tard. Service refused, 
> please try later. OFR_999 [999]
> 
> 421 mwinf5c86 ME Trop de connexions, veuillez verifier votre configuration. 
> Too many connections, slow down. OFR004_104 [104]
> 
>  
> 
> We’re doing our throttle back our connections, but it’s at the point where I 
> have hundreds of recipients at Orange / Wanadoo domains reaching out to us 
> wondering where their transactional mails are – they’re seeing delays of over 
> 12 hours.
> 
>  
> 
> Emails to postmaster@ are returning “552 5.2.2 Over quota” which leads me to 
> believe my attempts to contact over the weekend are not going through.
> 
>  
> 
> I’ll happily take this conversation off-list. Thanks!
> 
>  
> 
> ---
> 
> Nicolas Webb
> 
> Email Postmaster
> 
> Amazon Simple Email Service (SES)
> 
>  
> 
>  
> 
>  
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org <mailto:mailop@mailop.org>
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
> <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop>
> 
> 
> 
> 
> -- 
> Love is strong yet delicate.
> It can be broken.
> To truly love is to understand this.
> To be in love is to respect this.
> ~ Stephen Packer ~
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mysterious DKIM failure.

[Maarten Oelering]

Good point. Due to DMARC these issues will be more apparent. We will revisit 
our encoding and canocalization guidelines.

Thanks,

Maarten

> On 12 Dec 2016, at 21:23, Steve Atkins <st...@blighty.com> wrote:
> 
>> 
>> On Dec 12, 2016, at 12:15 PM, Maarten Oelering <maar...@postmastery.net 
>> <mailto:maar...@postmastery.net>> wrote:
>> 
>> DKIMCore promotes the use of simple body canocalization: 
>> http://dkimcore.org/deployment/dkim.html 
>> <http://dkimcore.org/deployment/dkim.html>.
> 
> Something that might not be the most robust configuration, given Microsoft's 
> whitespace issues, though at the time it was written the failure modes in the 
> body of the message tended to be more spectacular than relaxed 
> canonicalization would help with.
> 
> (And the author contradicts himself in todays blog post: 
> https://wordtothewise.com/2016/12/dkim-canonicalization-or-why-microsoft-breaks-your-mail/
>  
> <https://wordtothewise.com/2016/12/dkim-canonicalization-or-why-microsoft-breaks-your-mail/>
>  )
> 
>> 
>> Should ESPs use relaxed body canocalization instead to avoid these (rare) 
>> validation issues?
> 
> Yes. They should also probably:
> 
>   o Not use tabs for whitespace.
> 
>   o Use email addresses of the form "friendly address" <local@domain>
> 
>   o Avoid lines longer than 80 characters
> 
>   o Use quoted-printable for all body text
> 
>   o ...
> 
> None of this is particularly important when the only fallout of a DKIM 
> validation failure is "meh, it's email". DKIM is fragile in transit, we know 
> that.
> 
> It goes wrong when people also deploy DMARC with p=reject, which repurposes 
> DKIM and SPF to make negative rather than positive assertions, so actually 
> fails when both DKIM and SPF fail to validate. So we have to care more now.
> 
> Cheers,
>  Steve

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mysterious DKIM failure.

[Maarten Oelering]

DKIMCore promotes the use of simple body canocalization:
http://dkimcore.org/deployment/dkim.html.

Should ESPs use relaxed body canocalization instead to avoid these (rare)
validation issues?

Thanks,

Maarten Oelering
Postmastery

On Sun, 11 Dec 2016 at 20:29, Steve Atkins <st...@blighty.com> wrote:

> >
>
> > On Dec 11, 2016, at 8:53 AM, Dave Crocker <d...@dcrocker.net> wrote:
>
> >
>
> > On 12/10/2016 8:08 AM, Al Iverson wrote:
>
> >> Suggestion...modify the template to remove all the tabs or replace
>
> >> them with spaces, and try again. If it passes on both, then you've
>
> >> found that something in the delivery path is replacing tabs with
>
> >> spaces, invalidating the DKIM signature.
>
> >
>
> >
>
> > The original DKIM header field seems to show use of 'relaxed' which
> ought to make sp/tab transformations transparent.
>
> >
>
> >"Convert all sequences of one or more WSP characters to a single SP
>
> > character."
>
> >
>
> > hmmm...
>
>
>
> c=relaxed is identical to c=relaxed/simple, so these messages sent with
> c=relaxed are sensitive to whitespace changes in the body.
>
>
>
> (Not the first time I've seen this, and it's arguably a usability bug in
> the DKIM spec.)
>
>
>
> Cheers,
>
>  Steve
>
> ___
>
> mailop mailing list
>
> mailop@mailop.org
>
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abuse Contacts hosted @ gmail and Google's Spam filter

[Maarten Oelering]

Google has a great API to access mailboxes on Gmail and Google Apps and we use 
it successfully to search and retrieve DMARC reports.


However, we think this is not a scalable solution for role accounts. And 
totally unsuited for collecting bounces, something we also see in the wild.

Maarten
Postmastery

> On 28 jun. 2016, at 19:13, Steve Atkins  wrote:
> 
> 
>> On Jun 28, 2016, at 8:10 AM, Benoit Panizzon  wrote:
>> 
>> Hello
>> 
>> Operating the experimental future SWINOG Spamtrap development and Spam
>> Reporting infrastructure I often come across the problem, that many
>> abuse desks have their abuse contact address hosted by Google.
> 
>> Unfortunately Google does not know about ARF Reports and very quickly
> 
> Someone hosting on Google Apps probably has no way to read ARF reports,
> let alone handle them with the automation needed to make sense of bulk
> ARF feeds.
> 
>> considers an email spam, if it contains parts (headers) of an actual
>> spam mail.
>> 
>> I have been trying to contact ab...@google.com on several times about
>> this exact issue, but never got any reaction.
> 
> Anyone hosting their email on google apps isn't particularly interested in
> abuse reports at all, let alone unsolicited bulk reports of the type I presume
> you're sending.
> 
> Stop sending reports to anyone hosted by google. Possibly offer a way for
> those users to register an alternate reporting address. Move on.
> 
> Spending effort to send abuse reports to recipients who aren't going to
> do anything with them is effort you could more usefully spend elsewhere.
> 
> Cheers,
>  Steve
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Still seeing Microsoft 5.4.0 issues?

[Maarten Oelering]

Below are the sources with counts of “5.4.0" remote bounces for today.

COL004-OMC4S16.hotmail.com (65.55.34.218),101
COL004-OMC4S9.hotmail.com (65.55.34.211),98
COL004-OMC4S7.hotmail.com (65.55.34.209),92
COL004-OMC4S11.hotmail.com (65.55.34.213),82
COL004-OMC4S17.hotmail.com (65.55.34.219),79
COL004-OMC4S13.hotmail.com (65.55.34.215),72
COL004-OMC4S18.hotmail.com (65.55.34.220),68
COL004-OMC4S3.hotmail.com (65.55.34.205),64
COL004-OMC4S5.hotmail.com (65.55.34.207),63
COL004-OMC4S1.hotmail.com (65.55.34.203),61
COL004-OMC4S8.hotmail.com (65.55.34.210),59
COL004-OMC4S12.hotmail.com (65.55.34.214),58
COL004-OMC4S10.hotmail.com (65.55.34.212),57
COL004-OMC4S14.hotmail.com (65.55.34.216),55
COL004-OMC4S4.hotmail.com (65.55.34.206),50
COL004-OMC4S6.hotmail.com (65.55.34.208),48
COL004-OMC4S2.hotmail.com (65.55.34.204),45
COL004-OMC4S15.hotmail.com (65.55.34.217),41

Thanks,

Maarten Oelering
Postmastery

> On 31 mrt. 2016, at 22:04, Michael Wise <michael.w...@microsoft.com> wrote:
> 
> If you could enumerate the XXs for us, just for today, that would help a lot, 
> we suspect it's some sort of internal DNS timeout.
> 
> Aloha,
> Michael.
> -- 
> Sent from my Windows Phone
> From: Maarten Oelering <mailto:maar...@postmastery.net>
> Sent: ‎3/‎31/‎2016 1:01 PM
> To: Michael Wise <mailto:michael.w...@microsoft.com>
> Cc: Josh Nason <mailto:jna...@dyn.com>; mailop <mailto:mailop@mailop.org>
> Subject: Re: [mailop] Still seeing Microsoft 5.4.0 issues?
> 
> I just queried some data at google scale and found bounces with “5.4.0” 
> (nothing more). These are all remote (asynchronous) bounces. 
> The source of the bounce is COL004-OMC4SXX.hotmail.com 
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fCOL004-OMC4SXX.hotmail.com=01%7c01%7cMichael.Wise%40microsoft.com%7c82b93d7cfdc84f167b3f08d3599f3dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=T0YpfS%2bLslBRadpq8WP%2bp6UvtlWjX2DHK5c5ui1CdwQ%3d>
>  where XX varies. The recipient domain is mostly hotmail.com 
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhotmail.com=01%7c01%7cMichael.Wise%40microsoft.com%7c82b93d7cfdc84f167b3f08d3599f3dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2bBAN0Ch%2b%2fiXipBcMihCKD%2fyduAXU%2fNa2M4ZVnoT6sNs%3d>,
>  but also other Microsoft domains.
> The number varies per day but is a tiny fraction of the volume. Highest 
> numbers of these bounces on 03/11, 03/14, 03/23, and today. But they have 
> been there at least since 01/01 (and probably before).
> 
> Maybe this can help to clear it up.
> 
> Maarten Oelering
> Postmastery
> 
>> On 30 mrt. 2016, at 23:04, Michael Wise <michael.w...@microsoft.com 
>> <mailto:michael.w...@microsoft.com>> wrote:
>> 
>> Is the, “5.4.0 “ the entire bounce code / response? <>
>> If there’s more, we need to know to build a case.
>> If that’s it, that should be enough, but we need to know which it is.
>>  
>> Aloha,
>> Michael.
>> --
>> Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
>> Processed." | Got the Junk Mail Reporting Tool 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.microsoft.com%2fen-us%2fdownload%2fdetails.aspx%3fid%3d18275=01%7c01%7cMichael.Wise%40microsoft.com%7c82b93d7cfdc84f167b3f08d3599f3dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=znpQEBekjmu5mm94Q4uV%2fOmm7MexGB6lA52Cokq8GKw%3d>
>>  ?
>>  
>> From: mailop [mailto:mailop-boun...@mailop.org 
>> <mailto:mailop-boun...@mailop.org>] On Behalf Of Joel Beckham
>> Sent: Wednesday, March 30, 2016 1:53 PM
>> To: Josh Nason <jna...@dyn.com <mailto:jna...@dyn.com>>
>> Cc: mailop <mailop@mailop.org <mailto:mailop@mailop.org>>
>> Subject: Re: [mailop] Still seeing Microsoft 5.4.0 issues?
>>  
>> Not seeing any here. 
>>  
>> On Wed, Mar 30, 2016 at 7:01 AM, Josh Nason <jna...@dyn.com 
>> <mailto:jna...@dyn.com>> wrote:
>> Hi all -- we continue to see Action: failed/Status: 5.4.0 bounces for emails 
>> sent to Hotmail, Outlook, and Microsoft domains. I assume others are seeing 
>> the same?
>>  
>> Microsoft friends, any idea on a resolution time? This feels like it's 
>> taking a while to be resolved.
>>  
>> -- 
>> <~WRD000.jpg> 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdyn.com%2f=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=kOH1GObS%2f%2f%2bKupADC6jjq7awTjZsWI2XtEFn35jTEC8%3d>
>> <~WRD000.jpg> 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2fdyn=01%7c01%7cmichael.wise%40microsoft.com%7

Re: [mailop] Still seeing Microsoft 5.4.0 issues?

[Maarten Oelering]

I just queried some data at google scale and found bounces with “5.4.0” 
(nothing more). These are all remote (asynchronous) bounces. 
The source of the bounce is COL004-OMC4SXX.hotmail.com 
<http://col004-omc4sxx.hotmail.com/> where XX varies. The recipient domain is 
mostly hotmail.com <http://hotmail.com/>, but also other Microsoft domains.
The number varies per day but is a tiny fraction of the volume. Highest numbers 
of these bounces on 03/11, 03/14, 03/23, and today. But they have been there at 
least since 01/01 (and probably before).

Maybe this can help to clear it up.

Maarten Oelering
Postmastery

> On 30 mrt. 2016, at 23:04, Michael Wise <michael.w...@microsoft.com> wrote:
> 
> Is the, “5.4.0 “ the entire bounce code / response? <>
> If there’s more, we need to know to build a case.
> If that’s it, that should be enough, but we need to know which it is.
>  
> 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/details.aspx?id=18275> ?
>  
> From: mailop [mailto:mailop-boun...@mailop.org 
> <mailto:mailop-boun...@mailop.org>] On Behalf Of Joel Beckham
> Sent: Wednesday, March 30, 2016 1:53 PM
> To: Josh Nason <jna...@dyn.com <mailto:jna...@dyn.com>>
> Cc: mailop <mailop@mailop.org <mailto:mailop@mailop.org>>
> Subject: Re: [mailop] Still seeing Microsoft 5.4.0 issues?
>  
> Not seeing any here. 
>  
> On Wed, Mar 30, 2016 at 7:01 AM, Josh Nason <jna...@dyn.com 
> <mailto:jna...@dyn.com>> wrote:
> Hi all -- we continue to see Action: failed/Status: 5.4.0 bounces for emails 
> sent to Hotmail, Outlook, and Microsoft domains. I assume others are seeing 
> the same?
>  
> Microsoft friends, any idea on a resolution time? This feels like it's taking 
> a while to be resolved.
>  
> -- 
> <~WRD000.jpg> 
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdyn.com%2f=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=kOH1GObS%2f%2f%2bKupADC6jjq7awTjZsWI2XtEFn35jTEC8%3d>
> <~WRD000.jpg> 
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2fdyn=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=DhW5pUq6%2bWITpsJKs%2bZWE%2bjzECqQW6y8Mm59Ph9yuNE%3d>
>     
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2fdyninc=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=gDi9eHoI51qNg1It73YJ0Cz3gmIElv9S9UrRbLQEWmg%3d><~WRD000.jpg>
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffacebook.com%2fdyn=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=CaToMOiBJCLiT5nFeRbY%2fQno3ONdBCNkgoIm%2fJ5ZkzE%3d>
>     
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2fdyninc=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=gDi9eHoI51qNg1It73YJ0Cz3gmIElv9S9UrRbLQEWmg%3d><~WRD000.jpg>
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flinkedin.com%2fcompany%2fdyn=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=Vh5TJiH10ssKqxkX3PI2VWEuPZ5F%2fB3ATuctipGpK5M%3d>
> Josh Nason / Email Reputation Manager  
> <~WRD000.jpg> +1 603-289-1244 <tel:%2B1%20603-289-1244> | @JoshNason 
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.twitter.com%2fjoshnason=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2bEX2RF0nebwRI1mw%2bOzVVnDXkj%2bz5NtdFl3VnvrMCng%3d>
> Email is hot! This is why 
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.linkedin.com%2fpulse%2fwhy-email-marketing-original-form-social-media-josh-nason%3ftrk%3dprof-post=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91ab2d7cd011db47%7c1=KewzDx2BI1QJgWkPm0ME0YtBT1BPB7uNUYVWuxx7HkA%3d>
>  it's the original form of social media.
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org <mailto:mailop@mailop.org>
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop=01%7c01%7cmichael.wise%40microsoft.com%7c4a77ba1abb974c28324808d358de426b%7c72f988bf86f141af91a

Re: [mailop] Looking for someone to set up DKIM on a Windows server

[Maarten Oelering]

Hi Anne,

I was also waiting for details, but since your request has a wider scope I can 
no longer resist to stand up.
We help senders to implement best practices, including DKIM. We are biased 
towards Linux and PowerMTA, but Windows should be fine too.
Please contact me off list if you want to discuss it further.

Thanks,

Maarten Oelering
Postmastery

> On 30 mrt. 2016, at 18:18, Anne Mitchell <amitch...@isipp.com> wrote:
> 
> 
>> My question as well.  There are several well-done server packages.  And also
>> Exchange.
> 
> To elaborate, we are looking for someone to whom we can refer those clients 
> who are asking for assistance to set up authentication on their Windows 
> servers.  We're trying to *give someone some consulting business*! :-)
> 
> Anne
> 
> Anne P. Mitchell,
> Attorney at Law
> CEO/President, 
> SuretyMail Email Senders Reputation Inbox Certification Program 
> http://www.SuretyMail.com/
> http://www.SuretyMail.eu/
> 
> "Email marketing is the one place where it's better to ask permission than 
> forgiveness." - Me
> 
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Member, California Bar Cyberspace Law Committee
> Member, Colorado Cybersecurity Consortium
> Member, Asilomar Microcomputer Workshop Committee
> Ret. Professor of Law, Lincoln Law School of San Jose
> Ret. Chair, Asilomar Microcomputer Workshop
> amitch...@isipp.com | @AnnePMitchell
> Facebook/AnnePMitchell  | LinkedIn/in/annemitchell
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop