[mailop] Legal notification email incoming

[Vytis Marciulionis via mailop]

Hello mailbox providers,

One of our clients will be sending a legal notification email campaign starting 
today (11th of March) and ending 13th of March. During this period they should 
send out approximately 1.5M emails. Apologies for a short notice, but if you 
can please adapt your acceptance rates accordingly.
This campaign will go out from our “special purpose” IPs that are reserved for 
similar notifications.

Context:
Client ao.com has acquired two new brands and needs to send  a legal 
notification about data processing/privacy policy changes.

From addresses to be used:
no-re...@t.affordablemobiles.co.uk;
no-re...@t.buymobiles.net
envelope.from domain:
bounces.t.affordablemobiles.co.uk

Subject lines:
“Important information from Affordable Mobiles”
“Important information from Buymobiles”

IP addresses:
83.68.134.153
83.68.134.154
83.68.134.155
83.68.134.156

Please reach out to me personally if any additional information is needed.

Best regards,

Vytis Marciulionis


Deliverability Manager



[emarsys is part of SAP]

Emarsys eMarketing Systems GmbH
Lassallestraße 7b
A-1021 Vienna


E:
vytis.marciulio...@emarsys.com
W:
www.emarsys.com


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

[mailop] Anyone from arcor.de/vodafone.de on the list?

[Vytis Marciulionis via mailop]

Hi all,

Lately we (and some other ESPs) have been noticing this one error for the 
single MX record of these domains:
554 mx5.vodafonemail.de ESMTP not accepting connections
These errors seem to appear at random throughout all of our infrastructure and 
in the last 7 days out of 5M+ email volume 8.46% emails have bounces with this 
error.

In addition to that, this week we have also noticed some deferral/transient 
errors like this:

smtp;452 4.3.1 Insufficient system storage
After few days it went away.

Is there something going on this network internally and the error should go 
away by itself or is there something that we can do to fix it on our end?
If there is a person here from this network, feel free to get back to me 
off-list.

Best regards,
Vytis Marciulionis
Emarsys
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Mandated emails from notifications.newbalance.com on 1st of December

[Vytis Marciulionis via mailop]

To Whom it May Concern,

In accordance with the M3AAWG "Sending Mandated Emails to Large Audiences" 
guidance: This message is to inform you of a high email volume send which is 
likely to contain invalid email addresses and contacts who have opted out of 
email communication.

This send will be performed by New Balance who are contractually required to 
inform their Loyalty members that the program will be turned off by the end of 
the year.

If you are one of the mailbox providers that could help us prepare to contact 
the affected userbase, please reach out with any questions you may have.

Campaign Details to to recognize the risky traffic and make appropriate 
filtering decisions:

From address: m...@notifications.newbalance.com
Subject line: An important update about myNB Rewards
Date of Send: December 1st, 2021
Time of Send: Deploying over the course of the day. They will likely start 
12:40 CST / 18:40 UTC - then every hour until last deployment at 23:40 CST / 
05:40 UTC.
Total Volume: 4.2 million (typical domain split)
Sending IPs:
83.68.134.153
83.68.134.154
83.68.134.155
83.68.134.156

We appreciate your attention to this matter.

Thanks,
Emarsys Deliverability Team













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

[mailop] Any mailbox providers that check geolocation of mail sending IP?

[Vytis Marciulionis via mailop]

Hello mailbox providers,

Recently we have introduced a new /24 IP range to our mail sending 
infrastructure:
45.86.119.0/24

This is not a new process and we did not encounter any issues before.  However, 
initially this particular range came with geolocation being registered to 
Turkey in RIPE. That has, obviously, caused some mailbox providers, that check 
IP address geolocation of incoming emails, to recognize it as IP sending emails 
that originate from Turkey and that has caused delivery issues.

The geolocation of this new range was changed around month ago before we 
started any warmups. However, this week we were informed by one Australian 
provider that they still had the old geolocation set for this IP range and thus 
our mails were strictly rate-limited. If you are a mailbox provider and you 
check geolocation as one of the filtering/rate limiting/sender reputation 
criteria, could you double check which geolocation you see for this /24 IP 
range? Do not hesitate to get back to me off-list.

Any tips on what to keep in mind when acquiring and setting up new ranges are 
also welcome. Would be nice to avoid the same thing in the future.

Best regards,
Vytis
Email Deliverability
Emarsys
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] High-Risk Sendout notification to providers that could assist

[Vytis Marciulionis via mailop]

Hi there.

This is a courtesy note to pre-warn you that a client of mine will be sending a 
regulatory breach notification email today which may be flagged as suspicious 
or abusive.

Details:
Sender: Easyjet.com
Here is the link to the website: https://www.easyjet.com/en/infoalert
Date/time: 29th May 2020 (time currently unknown)
Sending domain/address: incid...@notifications.easyjet.com
Sending IP addresses: 83.68.134.153, 83.68.134.154, 83.68.134.155, 83.68.134.156
The expected total volume: 400K

Can you please inform me if we should take any specific action to support 
Easyjet in this sending.
And is there any information that you need?

Feel free to contact me off-list.

Kind regards,

Vytis Marciulionis


Deliverability Manager



[emarsys]

Emarsys eMarketing Systems AG
Märzstrasse 1
A-1150 Vienna
T:
+431 478 2080 - 118
M:
+37064734475
E:
vytis.marciulio...@emarsys.com
W:
www.emarsys.com










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

Re: [mailop] Anyone from TPG (in Australia) here?

[Vytis Marciulionis via mailop]

lol
Well, if that makes you feel better, I also saw the same temporary
rejections appearing for tpg.com.au in the last week or so.

On Fri, Apr 17, 2020 at 4:09 PM Noel Butler via mailop 
wrote:

> Wouldn't worry too much about it, they've had problems with their mail
> system for months.
>
> And good luck getting anyone to talk to who can understand your problem,
> you're palmed out to their non Australian call centre monkeys who are less
> then useless in philipines, with COVID-19 its even worse with only a
> handful working from their homes due to philipines govt lockdown, they
> employ SFA people in Australia where tech support is regarded as essential
> service and are exempt personnel  (major telco Telstra is same, except they
> have urgently hired 2500 local people over past few weeks because they have
> learned their lesson about cheap offshore call center labor)
>
>
> Anyway, you might as well stick toothpicks under your fingernails -  it's
> that torturous dealing with TPG.
>
>
>
> On 17/04/2020 18:30, Mark Dale via mailop wrote:
>
> Hi,
>
> Is there anyone from TPG here?
>
> Since Monday we've been seeing messages sent to tpg.com.au addresses
> intermittently get rejected with "451 4.3.2 Please try again later".
>
> Grateful if you could contact me.
>
> Thanks,
> Mark
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
>
> Kind Regards,
>
> Noel Butler
> This Email, including attachments, may contain legally privileged
> information, therefore remains confidential and subject to copyright
> protected under international law. You may not disseminate any part of this
> message without the authors express written authority to do so. If you are
> not the intended recipient, please notify the sender then delete all copies
> of this message including attachments immediately. Confidentiality,
> copyright, and legal privilege are not waived or lost by reason of the
> mistaken delivery of this message.
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 
Pagarbiai,
Vytis Marčiulionis
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to be dynamic - please use the smarthost of your ISP

[Vytis Marciulionis via mailop]

Hi Stefan,

This could also happen because your PTR record of sending IP address
resolves with 3 IPs e:
IP  116.203.31.6 - PTR securetransport.cubewerk.de - IPs 178.254.23.77;
116.203.31.6; 188.68.39.254

I know that technically it is nothing bad but, I can imagine why some
sensors could return errors, especially since the 3 IP addresses are from
different ASNs:
[image: image.png]

I guess those 3 IPs are set as fallback in this situation?


On Mon, Mar 9, 2020 at 11:03 AM Stefan Bauer via mailop 
wrote:

> Never had delivery issues from hetzner-blocks so far (crossing fingers)
> but I'm aware of the past.
>
>
> Looks like there is at least one RBL around, that list our IP as dynamic.
>
> https://www.rbl-dns.com/bl?ip=116.203.31.6
>
> One just have to pay to get de-listed. What a wonderful world.
>
>
> Stefan
>
>
> -Ursprüngliche Nachricht-
> *Von:* Andrew C Aitchison 
> *Gesendet:* Montag 9 März 2020 10:47
> *An:* Stefan Bauer 
> *CC:* mailop 
> *Betreff:* Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6
> seems to be dynamic - please use the smarthost of your ISP
>
> On Mon, 9 Mar 2020, Stefan Bauer via mailop wrote:
>
> > Any ewetel postmaster around? One of our IPs (subject) get flagged
> > as dynamic during delivery to ewetel. However this IP is static.
>
> I am not surprised that Ewetel has guessed wrong:
>   whois 116.203.31.6 -h whois.ripe.net
> gives a /16 belonging to our old friends Hetzner.
>
> --
> Andrew C. Aitchison   Kendal, UK
>   and...@aitchison.me.uk
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 
Pagarbiai,
Vytis Marčiulionis
+37064734475
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Vytis Marciulionis via mailop]

Hi,

- Have proper FCrDNS records. Just having MX and PTR records doesn't cut
> it. Add an A record that matches your PTR.


Could someone please confirm whether this is a best common practice for
RFC.5321 header domains as well? From what I have been asking around and
inspecting returnpath domains of a number of ESPs it is not a widespread
standard to have the FCrDNS on them but, I would like to someone to
confirm. As far as the discussion here goes, usually I get an answer that
mail sending domains do not need an A record if they have MX record, is
that correct?

On Fri, Feb 21, 2020 at 2:57 PM M. Omer GOLGELI via mailop <
mailop@mailop.org> wrote:

>
> - Have proper FCrDNS records. Just having MX and PTR records doesn't cut
> it. Add an A record that matches your PTR.
>
>
>
>
>
>
> M. Omer GOLGELI
> ---
>
>
> February 16, 2020 5:21 PM, "Hans-Martin Mosner via mailop" <
> mailop@mailop.org
> >
> wrote:
>
> Some ideas from running small to medium mail servers for a long time. Many
> of you will probably have more extensive experience and advice, but this is
> just a minimal list off the top of my head to get something for a start:
>
>1. Don't hide behind anonymity. Mail server domain whois should have
>an identifiable registrant organization, there should be a point of contact
>for any technical and abuse problems related to the mail server. If your
>registry hides registrant data, it might be a good idea to have a web site
>with the same name that's not just showing a welcome message from an
>uninitialized CMS or hosting package. Mails sent to the abuse address must
>be read and acted upon, except for blatant spam of course.
>2. Naturally, don't send spam, and have all your users understand that
>sending unsolicited bulk/commercial mail is not acceptable and will lead to
>termination.
>3. Have proper DNS setup:
>
>
>- MX record for the domain pointing to the mail server.
>- PTR record for the mail server' IP address pointing to the mail
>server's name.
>- Stable IP address (not 5-minute TTL for dynamic DNS updates, no
>long-lasting outages)
>
>
>- Use TLS for both incoming and outgoing traffic whenever offered by
>the other side.
>- Use a separate submission port for authenticated and encrypted mail
>submissions from your users. Add authentication information in mail headers
>to make identifying hacked mail accounts possible.
>- If possible, restrict the use of foreign From: addresses to trusted
>users and automatic software. Don't let just anybody send mails from
> ...
>- Avoid creating backscatter, i.e. either reject mails in the SMTP
>dialog or accept them. If you use spam detection software after SMTP
>acceptance, it should flag messages but still deliver them. There are cases
>such as autoresponders for vacations and mailing list software which will
>need to automatically send responses to sender addresses, but these should
>be monitored closely to detect abuse early.
>- (opinionated) Don' use SPF, it's broken by design.
>- Cheers,
>Hans-Martin
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 
Pagarbiai,
Vytis Marčiulionis
+37064734475
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI

[Vytis Marciulionis via mailop]

Hi,
I am not a part of the BIMI working group but, I think it is cool in it's
own way. So I will try to add my 2 cents.


> - It is said to increase security for mailbox owners because seeing the
>   companies logo they now they can see the message really is from "
> brand.com".
>   I still doubt this will work, because I could easily create a logo that
>   looks similar to brand.com, but use "brånd.com
> " including valid
>   SPF/DKIM/DMARC which AFAIK are conditions that have to be meet in order
> to
>   display a BIMI logo.
>

For the time being the requirement is to have p=quarantine or p=reject on
DMARC and a pass, also significant volume, engagement and reputation is
necessary for BIMI to appear.
Whereas it is indeed easy to authenticate your domains, spammers still
don't do that due to them constantly switching domains and it being
time-consuming.
Needless to say, building a reputation with certain providers is also not
something that spammers think of doing or, in most cases, are able to do.


> - It brings more advertising to your inbox.
>

I don't think it brings more advertising than it used to. It just makes it
better to distinguish emails instead of subject line and from name that you
usually first see.


> - It establishes a payment mechanism for receivers, which they can exert on
>   email marketing companies and their customers. "We will not display your
>   company logo in the (web)mail client unless you pay us money."


Payment is not yet needed and, to be fair, I do hope that it will stay
unnecessary, as this does bring some thought that "oh, I need to pay to
make the Internet experience better for this specific mailbox provider?".
However, I also understand that it would bring another level of security
and in this case such certification could completely eliminate the first
doubt you had about the ease of authenticating domains. Just another layer
of credibility.

So it is not yet so clear how this will go further but, I personally am
looking forward to how things will develop.

Regards,
Vytis

On Fri, Dec 6, 2019 at 11:13 AM Patrick Ben Koetter via mailop <
mailop@mailop.org> wrote:

> * Thomas Walter via mailop :
> >
> >
> > On 05.12.19 02:20, Matt Vernhout via mailop wrote:
> > > Stay tuned for more info on the bimigroup.org website, we are
> planning to add more info very soon.
> >
> > But why?
>
> Here's what I have heard, but haven't had time yet to verify or read deeper
> into. Not so nice things, though:
>
> - It is said to increase security for mailbox owners because seeing the
>   companies logo they now they can see the message really is from "
> brand.com".
>
>   I still doubt this will work, because I could easily create a logo that
>   looks similar to brand.com, but use "brånd.com "
> including valid
>   SPF/DKIM/DMARC which AFAIK are conditions that have to be meet in order
> to
>   display a BIMI logo.
>
> - It brings more advertising to your inbox.
>
> - It establishes a payment mechanism for receivers, which they can exert on
>   email marketing companies and their customers. "We will not display your
>   company logo in the (web)mail client unless you pay us money."
>
>
> p@rick
>
> --
> [*] sys4 AG
>
> https://sys4.de, +49 (89) 30 90 46 64
> Schleißheimer Straße 26/MG,80333 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
> Aufsichtsratsvorsitzender: Florian Kirstein
>
>
> ___
> 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] list bombing

[Vytis Marciulionis via mailop]

Hi everyone,

Are there any mailbox providers out there that actually check this
Form-Sub: header?
I remember it being discussed few years ago and I do know that this draft
is available but, is it used by mailbox providers? It being just a draft
and all?

On Tue, Nov 26, 2019 at 5:51 PM Matt Gilbert via mailop 
wrote:

> Hey Carl,
>
> Thanks for noticing that. We’re going to get that header included in the
> signature shortly.
>
>
> Thanks,
> Matt Gilbert
> --
> Deliverability Engineer | Mailchimp
> delivery.mailchimp.com
>
>
> On Nov 25, 2019, at 9:50 PM, Carl Byington via mailop 
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Mon, 2019-11-25 at 10:32 -0800, Kurt Andersen (b) via mailop wrote:
>
> Are you seeing any significant portion of these messages bearing the
> Form-Sub header? (documented in https://tools.ietf.org/html/draft-
> levine-mailbomb-header-01)
>
>
> On a low volume mail server, the only messages I see with that header
> are also dkim signed by mail*.mcsignup.com. MailChimp are using
>
> h=From:Reply-To:To:Date:Message-ID:Sender:Subject:MIME-Version: Content-
> Type;
>
> So their signature does not include the Form-Sub: header, contrary to
> the recommendation in that draft.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAl3cksAACgkQL6j7milTFsG9zQCdE6YkaHRj+a4I+79b/quTXZrc
> CsoAn1kB22Ss/Q34UIsR4zg7SIlheRC8
> =LF9o
> -END PGP SIGNATURE-
>
>
>
> ___
> 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
>


-- 
Pagarbiai,
Vytis Marčiulionis
+37064734475
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] reputation with DKIM when d= differs from sender domain?

[Vytis Marciulionis via mailop]

Hi Stefan,

You want to dkim sign with the exact domain/subdomain that you are sending.
Majority of senders also add a second DKIM for their envelope.from (a.k.a.
returnpath) domain as well, if it is different from the "From address".
You can get more information in a very orderly document about the best
practices for sending domains here:
https://www.m3aawg.org/sites/default/files/m3aawg-sendingdomains10102019nk-2.pdf


On Thu, Nov 14, 2019 at 5:47 PM Stefan Bauer via mailop 
wrote:

> Hi,
>
>
> this list is of great help for me to be a good mailop. thank you.
>
>
> Now the question:
>
>
> Is it bad - in terms of reputation - when domain in dkim-header (d=...)
> differs from senders address?
>
> signing is done correctly and pub-key is present at domain of corse -
> specified with d=...
>
>
> like d=mydomain.com
>
> Sender is Stefan 
>
>
> And how is it with subdomains?
>
>
> d=mydomain.com
>
> Sender is Stefan 
>
>
> I could not find anything in the RFC.
>
>
> Thank you.
>
>
> Stefan
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 
Pagarbiai,
Vytis Marčiulionis
+37064734475
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Reg. false positive bounces at Yahoo ISP

[Vytis Marciulionis via mailop]

Hi Vaibhav,

Are you able to confirm that those mailbox really exist? Occasionally Yahoo
cleans up their mailboxes, so some times bounces may increase. On our end I
do not see any increases in bounces in the last 24 hours.

Regards,
Vytis

On Wed, Nov 13, 2019 at 7:25 AM Vaibhav via mailop 
wrote:

> Hi Everyone,
>
> Recently we observed we are getting false bounce reason within month time.
> As per our analysis Yahoo is throwing bounce reason as " *554 delivery
> error: dd This user doesn't have a yahoo.com  account*
> ([EMAIL]) "
>
> We identify the same issue across our customers. Few customer we noticed
> around ~25% false positive bounces.
>
> Here is sample for one user,
>
> *Email bounced :*
>
> 2019-09-30 16:37:24
> mta5.am0.yahoodns.net (98.136.96.77)
> 554 delivery error: dd This user doesn't have a yahoo.com account
> ([EMAIL]) [-9] - mta4274.mail.ne1.yahoo.com
>
>
> *Email successfully delivery : *
>
> 2019-10-31 11:54:11
> mta5.am0.yahoodns.net (98.136.96.76)
>
> --Vaibhav
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 
Pagarbiai,
Vytis Marčiulionis
+37064734475
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] A contact from Cox needed

[Vytis Marciulionis via mailop]

Hello everyone,

In hope to get assistance from a person at Cox I am reviving this thread. As 
Andy was experiencing that before, we also see repetitive CXCNCT errors. 
https://www.cox.com/residential/support/email-error-codes.html says that they 
support up to 10 concurrent connections and we have max-connect-limit 8 set as 
default on our PMTA configuration. We also lowered max connection limit to 4 
just for cox.net mailboxes, yet that does not seem to change anything at all.

Out of 470k attempts in last 24 hours to send mails 455k were rejected as tq 
errors with CXCNCT as the reason and 6.4k were transient/deferred with CXMXRT 
as the reason. Out of 470k attempts 8.5k mails were delivered and 221 bounced.

We could really use some help off-list as none of our attempts to contact in 
the last week got us a reply or fix. Thanks in advance!



Best regards,

Vytis

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

[mailop] No MX record on domain is a bounce by Gmail

[Vytis Marciulionis via mailop]

Hello, everyone,

It is quite common that senders want to make sure they encounter fewer
bounces. I was told, by multiple people I discussed with, that if you
looked up MX record on a domain and there is none, you still should try
sending emails to that domain because there is a possible configuration to
deliver that mail message via A record. Fair enough, I thought.

Now, yesterday I tried contacting one of the spammers I found in my mailbox
(the well known "I see you watching porn" blackmail scheme) and to my
surprise, Gmail has bounced that message with this error:

The response was:
>
> DNS Error: 6443565 DNS type 'mx' lookup of example.com responded with
> code NXDOMAIN Domain name not found: example.com
>
Has anything changed and now we can consider "no MX record" a valid reason
to not deliver messages to that domain?
Or maybe it was always a good idea to discard receiving domains without any
MX records?

Thank you for your time!

Regards,
Vytis Marčiulionis

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