Re: [mailop] Issues warming a server for Yahoo

[Tim Starr via mailop]

Tell Yahoo it's not fixed yet.

-Tim

On Tue, May 14, 2024 at 4:47 AM Gavin Montague via mailop 
wrote:

> Hi all,
>
> I was wondering if anyone had any experience/suggestions regarding
> warming an IP address that delivers to  Yahoo managed domains (yahoo,
> aol, sky.com, etc)?
>
> We're bringing up a new Postfix instance handling outbound transactional
> and marketing emails for our e-commerce site.  The IP doesn't appear on
> any spam-lists that I can find, we're signing all our emails and
> deliverability from the sibling Postfix instances to Yahoo addresses is
> entirely fine. List-unsubs & service-feedback on spam are all acted upon
> automatically. As best I know: we're a good citizen.
>
> The new server has been delivering low-volume transaction messages
> (receipts, purchased vouchers, etc) for 6 weeks or so and we've been
> gradually delivering lower value, higher volume content to our
> subscriber list through it for about the past 2 weeks. Hotmail, Gmail,
> other big providers are all entirely fine with the volume and we're
> seeing accepted messages and expected levels of click-thought
> afterwards.
>
> Except for Yahoo.
>
> As soon as we send more than a couple of messages to yahoo within a few
> minutes we see...
>
> Messages from 151.236.220.98 temporarily deferred due to unexpected
> volume or user complaints - 4.16.55.1; see
> https://postmaster.yahooinc.com/error-codes (in reply to MAIL FROM
> command)
>
> Messages get deferred for 6-8 hours before being accepted.
>
> Yahoo support have said a problem with the IP was "fixed", but the
> problem persists.
>
> Has anyone had particular trouble convincing Yahoo to accept messages?
>
> Thanks,
>
> Gavin
> ___
> 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] bigpond.com IB302 sender domain rejected

[Tim Starr via mailop]

I believe Bigpond maintains their own internal domain blacklists. It's been
a while, but postmas...@bigpond.com has been responsive for me in the past
in similar cases.

Tim Starr

On Tue, Apr 23, 2024 at 4:59 AM John Gao via mailop 
wrote:

> Hi Team,
>
>
>
> Does anyone have experience with subdomains being rejected by
> extmail.bigpond.com?  We have having problem with emails from subdomains
> hosted at O365 being rejected by bigpond.com.
>
>
>
> e.g.
>
> - mail from @somedomain.org.au is OK
>
> - mail from @sub1.somedomain.org.au during mail from results in 550 5.7.1
> em...@sub1.somedomain.org.au Sender domain rejected. IB302
>
> - mail from @sub2.somedomain.org.au is accepted during mail from
>
>
>
> It seems to me that sub1.somedomain.org.au is specifically blacklisted.
> It is not listed any known RBL though accordingly to mxtoolbox.com or
> senderbase.  I see no way to getting a domain delisted in Bigpond.
>
>
>
> Any help is much appreciated.
>
>
>
> Thanks and Regards
>
>
>
> John
> ___
> 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] Debt Collection Client Email Servers

[Tim Starr via mailop]

Some AWS IPs may have Good GPT rep, but I just found some for a client that
were either Low or Bad.

-Tim

On Tue, Mar 26, 2024 at 4:34 AM Laura Atkins via mailop 
wrote:

> AWS has good IP reputation - I’ve got one client sending <500K a month and
> one sending >20M a day off AWS and their IP rep at google is all in the
> green. Mailgun/Sinch are one a lot of my clients are moving to, as well.
> There’s also whatever-they’re-called-now-but-used-to-be-Sparkpost.
>
> I’m really unsure that email is a good way to do this kind of contact,
> though. It’s too easy for the actual recipients (whether they’re the actual
> debtor or not) to affect your reputation.
>
> laura
>
> On 25 Mar 2024, at 21:52, Michael Irvine via mailop 
> wrote:
>
> Thank you everyone. Is there any recommendation on other 3rd party senders
> that can be trusted instead of SendGrid. My last resort will be to setup
> some MTA's with the few free IP they have from the Datacenter.
>
> I also understand that the client is in the middle of a catch-22 in terms
> of sending email. I have already informed them that email will always be a
> best effort and not a guarantee.
>
> As for contacts other than email. Email is the last resort after all other
> avenues are attempted in the order of Snail Mail, Phone, SMS, and Social
> Media.
>
> Thanks,
>
> Michael Irvine
>
> -Original Message-
> From: mailop  On Behalf Of Jay Hennigan via
> mailop
> Sent: Monday, March 25, 2024 1:37 PM
> To: mailop@mailop.org
> Subject: Re: [mailop] Debt Collection Client Email Servers
>
> CAUTION: This email originated from outside of the organization. Do not
> click any links or open attachments unless you recognize the sender and
> know the content is safe.
>
>
>
> On 3/22/24 14:58, Michael Peddemors via mailop wrote:
>
> If they are 'dedicated', doesn't matter if they are coming from
> SendGrid, the PTR should reflect your clients domain.
>
> host 149.72.234.90
> 90.234.72.149.in-addr.arpa domain name pointer
> wrqvzxrx.outbound-mail.sendgrid.net.
>
>
> If Sendgrid claimed that these IPs are dedicated to you, their PTR says
> otherwise. It should reflect your sending domain. Note that Sendgrid has a
> rather poor reputation when it comes to spam exiting their network.
>
> And given the amount of abuse of SendGrid servers, anything you can do
> to differentiate from their generic naming conventions will help you.
>
>
> Or avoid Sendgrid entirely.
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
>
> --
> The Delivery Expert
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Delivery hints and commentary: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> 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] Yahoo! error-codes page seems broken

[Tim Starr via mailop]

Yahoo says they're aware & working on it.

-Tim

On Tue, Jan 16, 2024 at 11:25 AM Andy Smith via mailop 
wrote:

> Hi,
>
> While trying to debug:
>
> <[redacted]@yahoo.co.uk>: host mx-eu.mail.am0.yahoodns.net[188.125.72.74]
> said:
> 554 5.7.9 Message not accepted for policy reasons. See
> https://postmaster.yahooinc.com/error-codes (in reply to end of
> DATA command)
>
> I and others note that https://postmaster.yahooinc.com/error-codes
> just redirects to a page that simply says "Cannot GET /error-codes".
>
> Though as regards the actual NDR, i think it will be a result of
> our user forwarding email into Yahoo!, because the address we sent to
> was a personal domain.
>
> Thanks,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
> ___
> 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] Yahoo! error-codes page seems broken

[Tim Starr via mailop]

I had that happen to me yesterday, but I was able to get there from the
main page:

https://senders.yahooinc.com/smtp-error-codes/

I think they have the wrong URL in the bounce. Will report to Yahoo.

-Tim

On Tue, Jan 16, 2024 at 11:25 AM Andy Smith via mailop 
wrote:

> Hi,
>
> While trying to debug:
>
> <[redacted]@yahoo.co.uk>: host mx-eu.mail.am0.yahoodns.net[188.125.72.74]
> said:
> 554 5.7.9 Message not accepted for policy reasons. See
> https://postmaster.yahooinc.com/error-codes (in reply to end of
> DATA command)
>
> I and others note that https://postmaster.yahooinc.com/error-codes
> just redirects to a page that simply says "Cannot GET /error-codes".
>
> Though as regards the actual NDR, i think it will be a result of
> our user forwarding email into Yahoo!, because the address we sent to
> was a personal domain.
>
> Thanks,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
> ___
> 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] [ADMIN] BIMI, Logos etc

[Tim Starr via mailop]

Noted, will discontinue further replies.

-Tim

On Mon, Jan 15, 2024 at 2:26 PM Graeme Fowler via mailop 
wrote:

> On 14 January 2024 15:55:43 Graeme Fowler via mailop 
> wrote:
>
>> Unless anyone has anything new, valid, on-point and worthy of further
>> discussion, I'd suggest that we're done here.
>>
>
> I'm no longer suggesting. Just stop rehashing the thread. It's dead. It's
> not pining for the fjords.
>
> Thanks
>
> Graeme, preparing the mod- and ban- hammers for those who appear desperate
> to trash the utility of the list.
> ___
> 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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

On Fri, Jan 12, 2024 at 5:58 PM Jaroslaw Rafa via mailop 
wrote:

[snip]

Dnia 12.01.2024 o godz. 14:04:59 Tim Starr via mailop pisze:
> > BIMI's value is not dependent upon MUAs
> > never doing anything outside its spec.
>
> Yes, it is. Because it depends on the condition that the logo is displayed
> only if it is a verified BIMI logo.
>

Nope. It depends on mailreaders displaying logos they think will be helpful
to their users. BIMI is a way for senders to nominate candidates for their
own logos, which mailreaders are free to accept or reject, as they see fit.

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

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

I don't see how you're disagreeing with me. BIMI is a complicated if-then
statement. If X, then do Y. It says nothing about doing anything else. I
didn't say displaying non-BIMI images was contrary to the spec, just that
it was something outside the spec. BIMI's value is not dependent upon MUAs
never doing anything outside its spec.

-Tim

On Fri, Jan 12, 2024 at 12:05 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 12.01.2024 o godz. 11:18:32 Tim Starr via mailop pisze:
> > By publishing the BIMI spec. No one's required to follow the spec, but if
> > they don't, then they're not doing BIMI, and that's not the fault of the
> > spec.
>
> Does the BIMI spec *require* that *only* BIMI-authenticated messages can
> have logos displayed alongside them in the MUA?
>
> In my understanding no. If it actually states so, then it's far too
> restrictive and unacceptable (and this *is* fault of the spec). That's what
> im talking about all the time.
>
> So MUAs that display "other" (non-BIMI !) logos, are doing BIMI *plus*
> something else. They are not contrary to the BIMI spec. They are just in
> addition doing something that is completely orthogonal to BIMI, but gives
> similar visual experience to the user.
>
> Which actually defeats the purpose of BIMI, as I understand it.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> 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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

By publishing the BIMI spec. No one's required to follow the spec, but if
they don't, then they're not doing BIMI, and that's not the fault of the
spec.

-Tim

On Thu, Jan 11, 2024 at 5:31 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 11.01.2024 o godz. 17:02:01 Tim Starr via mailop pisze:
> > The image has to be specified in the DNS, and it has to be certified w/ a
> > VMC. The VMC certification process includes checking if it's trademarked.
> > So, in order for a trusted brand's BIMI logo to get spoofed, the email
> > would have to be DMARC-authenticated and the logo specified in the DNS
> > would be the one presented to the mailbox provider when they do DNS
> lookups
> > on the authentication domains.
>
> Under the assumption that that he MUA will display *only certified BIMI
> logos* and not any other "avatars" with the emails, ever.
>
> How are you going to force MUA developers to do that?
>
> Assume the recipient uses a MUA that displays not only BIMI logos, but eg.
> avatars from Gravatar service as well. The attacker just sets as his
> Gravatar picture the logo he wants to spoof. Then sends mail to the
> recipient. Recipient sees a familiar logo (without BIMI being used at all!)
> and assumes the mail is genuine.
>
> As I wrote previously, the only method to prevent this is a (totally
> unrealistic) *legal prohibition* for MUA developers to display any other
> images than certified BIMI logos. Not possible.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> 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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

The image has to be specified in the DNS, and it has to be certified w/ a
VMC. The VMC certification process includes checking if it's trademarked.
So, in order for a trusted brand's BIMI logo to get spoofed, the email
would have to be DMARC-authenticated and the logo specified in the DNS
would be the one presented to the mailbox provider when they do DNS lookups
on the authentication domains. IOW, the only real way to do it would be
with account takeovers. If you can hack into the ESP account of a trusted
brand, then you can send fully-authenticated email for that brand, with its
BIMI logos.

The biggest spoofing risk here is with really inclusive SPF records that
include an entire cloud SMTP provider's IP ranges, where other senders also
send from those ranges, and they can then send SPF-authenticated email w/ a
trusted brand's return-path domain, which would then pass DMARC and BIMI.
But that's a security risk already, BIMI doesn't make it worse. Cloud SMTP
providers need to do a better job of locking down the sending domains their
clients can use to prevent that. However, even there, if the DNS accounts
of domain owners can be hacked into, authorization of domains can be faked,
too. But, again, that's an existing risk, which BIMI doesn't make any worse.

-Tim

On Thu, Jan 11, 2024 at 2:35 PM Bastian Blank via mailop 
wrote:

> On Thu, Jan 11, 2024 at 01:45:19PM -0600, Tim Starr via mailop wrote:
> > To elaborate on Marcel's answer, so he doesn't have to waste time
> > explaining it all over again, the "different logo" won't be displayed by
> > the mailbox providers, because it's not the authenticated one.
>
> What prohibits them from making it authenticated?  A trademark check?
>
> Bastian
>
> --
> Extreme feminine beauty is always disturbing.
> -- Spock, "The Cloud Minders", stardate 5818.4
> ___
> 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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

To elaborate on Marcel's answer, so he doesn't have to waste time
explaining it all over again, the "different logo" won't be displayed by
the mailbox providers, because it's not the authenticated one.

-Tim

On Thu, Jan 11, 2024 at 1:11 PM Marcel Becker via mailop 
wrote:

> On Thu, Jan 11, 2024 at 10:58 AM Randolf Richardson, Postmaster via mailop
>  wrote:
>
>>
>>  They could
>> easily afford set up a company, get a Trademark, and then use a
>> different logo image when sending their junk eMails.
>>
>
> No,  that's not how VMCs and BIMI set ups at participating mailbox
> providers work.
> ___
> 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] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

They can already rip people off, w/out BIMI. BIMI limits their ability to
do so in two ways:

1) It raises the cost, because BIMI setup costs more.
2) It makes it harder for scammers to impersonate trusted brands.

-Tim

On Thu, Jan 11, 2024 at 12:58 PM Randolf Richardson, Postmaster via mailop <
mailop@mailop.org> wrote:

> > I might have missed something, but wouldn't that be a phisher's wet
> dream?
>
> Indeed, and because the BIMI record references a URI to load the
> logo from, so the scammers (spammers, phishers, malware/virus
> distributors, etc.) could simply specify a different logo file with a
> recognized brand to make their bad eMail appear legitimate.
>
> > Most spammers know very well how to do a mail with valid DMARC. So, now
> > they only need to send a valid mail from any throw away cheap domain and
> > in their BIMI add the logo of paypal?
>
> Yes.
>
> > I understand it's not great to have to pay for the
> > verification/certification, but leaving the door open to abuse is a
> > dangerous path to take.
>
> Some scammers make a lot of money ripping people off.  They could
> easily afford set up a company, get a Trademark, and then use a
> different logo image when sending their junk eMails.
>
> So, once this happens often enough, end-users will just not trust
> the BIMI logos to be reliable and it will be another internet feature
> that security educators will recommend be taken with a grain of salt.
>
> > Being on the antispam side, I would hate to have to start implementing
> > BIMI spoof checks.
>
> I agree.  Even if someone else makes a SpamAssassin plug-in or a
> milter, it still adds to the overall complexity and will have a
> potentially-noticeable impact on busier systems ... and then everyone
> has to pay indirectly for BIMI with slower performance of system
> upgrades to counter the slower performance.
>
> > Regards,
> > Laurent
> >
> > On 11.01.24 00:05, Louis Laureys via mailop wrote:
> > >  We decided to keep this because I read that some webmail clients
> are
> > >  planning to support BIMI without checking for certificates, or,
> > >  perhaps, also displaying a little lock icon in the corner of the
> > >  sender's BIMI-style logo image where certification is verified.
> > >
> > > This is exactly what I have in mind for my client, thanks for
> publishing your
> > > logo in an easily accessible and standard way :)
> > >
> > > Groetjes,
> > > Louis
> > >
> > >
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
>
> --
> Postmaster - postmas...@inter-corporate.com
> Randolf Richardson, CNA - rand...@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Vancouver, British Columbia, Canada
> https://www.inter-corporate.com/
>
>
> ___
> 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] BIMI boycott?

[Tim Starr via mailop]

You seem to be taking a religious position based on your perception of
"need." If this feature is un-needed, why did Google and Yahoo do it? They
think their users want it, that's why they spent time building this feature
into their UIs, and why they keep it there. Among other things, it serves
as a visible indicator of email that is both authenticated and passes
DMARC. If you also object to authentication and DMARC, then you're making
yourself even more of a minority advocate. I do not expect any such boycott
to get widespread adoption.

Tim Starr

On Wed, Jan 10, 2024 at 11:34 AM Jaroslaw Rafa via mailop 
wrote:

> Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> > The hope is that as BIMI gets more widely adopted, the cost (and
> > automation) of the logo validation drops. Time will tell.
> >
> > Of course, for broader adoption, we also need to progress beyond
> > trademarks, which have their own cost and timeliness issues. The working
> > group is leaning heavily into this, as its our top priority to make BIMI
> > more broadly accessible.
> >
> > This covers our technical intent:
> > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00 and
>
> The document fails to convincingly answer THE one basic question:
>
> WHY in the hell is such a strange feature needed at all and for whom?
>
> As the OP has written, the only ones that may be interested in this may be
> marketers. Nobody else needs any logos, avatars etc. displayed alongside
> the
> email headers. There is a reason why the early attempt at this - I'm
> talking
> about the X-Face header, which you even refer to in this document - never
> gained any popularity. Simply, nobody needs this. The fact that Gmail
> implemented in its web client putting up some images alongside email
> headers
> (which, by the way, show anything non-default only if the sender is another
> Gmail user and has a profile picture defined in his/her account) shouldn't
> be any reference nor guide for designing email applications at all. NOBODY
> NEEDS THESE IMAGES.
>
> Also, I see no feasible way - neither now nor in the future - to use it any
> meaningful way in person-to-person communication, which is the topic OP
> asked about, and you seem to have ignored it completely in your answer. The
> document you are linking to isn't even trying to address this use case! It
> speaks all the time about "organizations" or "brands" and their logotypes,
> like companies or organizations were the only senders of emails. Or maybe
> this is the actual intent? To make individual people only reicipents of
> emails, without the ability to send?
>
> In section 3.3 you even predict that BIMI is about to go the same path
> DMARC
> went - "DMARC started with limited use to protect heavily phished domains",
> and now we have arrived to the point when you almost can't send mail to any
> big mail provider without having DMARC properly set up. You predict that
> likely the same will happen for BIMI, which means, you won't be able to
> send
> mail to any of the "big players" if you don't have BIMI set up. Which
> *will*
> cost money - you are also clear about it. Is the goal to make email a
> closed
> ecosystem in which only the big players can participate?
>
> This was a bad idea from the beginning (I would even say, a crazy idea) and
> will still be a bad idea no matter how much work and effort you put into
> it.
> So maybe it's better not to waste that effort at all and direct it towards
> something actually useful.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> 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 data missing recently - anyone else?

[Tim Starr via mailop]

Others have reported this, but I'm not seeing it, myself. It seems to be
intermittent. Some see it, some don't.

-Tim

On Mon, Dec 4, 2023 at 4:04 PM 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] Microsoft's block list?

[Tim Starr via mailop]

Go to the URL, open a ticket, be persistent, explain that you don't send
any spam.

-Tim

On Wed, Nov 22, 2023 at 8:41 AM Otto J. Makela via mailop 
wrote:

> Can someone shed light on a Microsoft/Outlook block list? Our hobby server
> (on upcloud.com) seem to have been blocked for quite some time now.
>
> At this time, SPF and DKIM should be correct for our outgoing messages.
> Is there anything to be done, apart from switching to some mail sender
> company instead of ourselves attempting a direct connection?
>
> 2023-11-15T08:27:37.762372+00:00 mail postfix/smtp[113710]: 7407B6274D:
> to=, relay=
> hotmail-com.olc.protection.outlook.com[104.47.18.97]:25, delay=0.29,
> delays=0.05/0/0.21/0.03, dsn=5.7.1, status=bounced (host
> hotmail-com.olc.protection.outlook.com[104.47.18.97] said: 550 5.7.1
> Unfortunately, messages from [SERVERIPADDRESS] weren't sent. Please contact
> your Internet service provider since part of their network is on our block
> list (S3150). You can also refer your provider to
> http://mail.live.com/mail/troubleshooting.aspx#errors. [
> AM6EUR05FT032.eop-eur05.prod.protection.outlook.com
> 2023-11-15T08:27:37.743Z 08DBE4B9C5B508E7] (in reply to MAIL FROM command))
>
> --
> /* * * Otto J. Makela  * * * * * * * * * */
>/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
>   /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
> /* * * Computers Rule 0100 01001011 * * * * * * */
> ___
> 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] Continuous DMARC temperrors with Microsoft

[Tim Starr via mailop]

I see those, too. I assumed it was due to temporary DNS lookup failures.

-Tim

On Fri, Mar 10, 2023 at 10:19 AM Gellner, Oliver via mailop <
mailop@mailop.org> wrote:

> Hello,
>
> we repeatedly receive DMARC reports from dmarcrep...@microsoft.com with
> allegedly failed DKIM checks. The result is always "temperror". This
> happens daily for all kind of domains, also under different top level
> domains.
> Noone else is reporting temperrors on such a regular level and also at
> Microsoft most messages (from the very same domains on the same day) pass
> the DKIM check, so it's not like the DNS entries were broken. The numbers
> of failed messages are not huge, but they happen frequently. Does anyone
> see such behaviour in their DMARC reports from Microsoft as well?
>
>
> Examples:
>   
> 
>   195.2.200.153
>   17
>   
> none
> fail
> pass
>   
> 
> 
>   hotmail.com
>   shop.dm-drogeriemarkt.ba
>   shop.dm-drogeriemarkt.ba
> 
> 
>   
> shop.dm-drogeriemarkt.ba
> acl20211215
> temperror
>   
>   
> shop.dm-drogeriemarkt.ba
> mfrom
> pass
>   
> 
>   
> --
>   
> 
>   136.243.101.209
>   9
>   
> none
> fail
> pass
>   
> 
> 
>   hotmail.com
>   rp.news.dm.de
>   news.dm.de
> 
> 
>   
> news.dm.de
> elaine
> temperror
>   
>   
> rp.news.dm.de
> mfrom
> pass
>   
> 
>   
> --
>   
> 
>   213.128.132.138
>   6
>   
> none
> fail
> pass
>   
> 
> 
>   hotmail.com
>   unserdm.at
>   unserdm.at
> 
> 
>   
> unserdm.at
> keyingress
> temperror
>   
>   
> unserdm.at
> mfrom
> pass
>   
> 
>   
>
>
> --
> BR Oliver
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> 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 Crash

[Tim Starr via mailop]

It's back up today for me.

Tim Starr
Senior Director, Deliverability
The Lifetime Value Company

On Sat, Mar 4, 2023 at 3:52 PM Emre Üst via mailop 
wrote:

> Thank you Mark , so there is a global problem .
>
> On Sun, Mar 5, 2023 at 12:40 AM Mark Alley  wrote:
>
>> I've seen the same with my domains. Just spins on load.
>>
>> On Sat, Mar 4, 2023, 3:35 PM Emre Üst via mailop 
>> wrote:
>>
>>> Hello ,
>>>
>>> Google Postmaster not working since Friday. After log in, it should list
>>> the domain list, but the loading screen returns and does not appear.
>>>
>>> Are you like that too? Or are we just experiencing this situation?
>>>
>>> Thank you
>>>
>>> --
>>> *Emre ÜST*
>>> Deliverability Team Leader
>>>
>>> *t.*   +90 212 343 07 39
>>> *f.*   +90 212 343 07 42
>>> *m.* +90 533 157 73 10
>>>
>>> *email: *emre@relateddigital.com <%23>
>>> *web:* relateddigital.com 
>>> Maslak Mah. Büyükdere Cd. No:249 Sarıyer - İstanbul
>>>
>>> 
>>> 
>>>  
>>>
>>> 
>>>
>>> Bu e-posta içeriği, mesajın alıcı kısmında belirtilmiş olan kişi/kurum
>>> içindir ve sadece gönderilen kişiye/kuruma yöneliktir. Mesajın gönderilmek
>>> istendiği kişi/kurum değilseniz, lütfen doğrudan veya dolaylı olarak mesajı
>>> kullanmayınız ve mesajın tüm kopyalarını sisteminizden derhal siliniz. Bu
>>> mesaj kişisel veri içerebilir, böyle bir durumda mesajın muhatabı
>>> değilseniz, ilgili mevzuat kapsamında kişisel veri içeren mesajı tüm
>>> sistemlerinizden derhal kaldırın. Related Digital, bu e-postada yer alan
>>> hatalardan veya eksikliklerden sorumlu değildir ve e-posta kullanımından
>>> kaynaklanan zararlardan sorumlu tutulamaz. Bu mesajda yer alan herhangi bir
>>> görüş ve beyan ya da herhangi bir ek yalnızca yazarına aittir ve Related
>>> Digital’i mutlak anlamda temsil etmemektedir.
>>>
>>>
>>> This e-mail content is solely for the individual/entity who has been
>>> mentioned specifically in the recipient section of the e- mail and intended
>>> solely for the addressee. If you are not the intended addressee, please do
>>> not use the message directly or indirectly and delete the message and all
>>> its copies immediately. This message may contain personal data, if you are
>>> not the recipient of the message remove the message immediately from all
>>> your systems under the relevant legislation within the scope of personal
>>> data. Related Digital is not responsible for errors or omissions in this
>>> message and cannot be held responsible for any damage arising from the use
>>> of e-mail. Any opinion and other statement contained in this message and
>>> any attachment are solely those of the author and do not necessarily
>>> represent Related Digital.
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://list.mailop.org/listinfo/mailop
>>>
>>
>
> --
> *Emre ÜST*
> Deliverability Team Leader
>
> *t.*   +90 212 343 07 39
> *f.*   +90 212 343 07 42
> *m.* +90 533 157 73 10
>
> *email: *emre@relateddigital.com <%23>
> *web:* relateddigital.com 
> Maslak Mah. Büyükdere Cd. No:249 Sarıyer - İstanbul
>
> 
> 
>  
>
> 
>
> Bu e-posta içeriği, mesajın alıcı kısmında belirtilmiş olan kişi/kurum
> içindir ve sadece gönderilen kişiye/kuruma yöneliktir. Mesajın gönderilmek
> istendiği kişi/kurum değilseniz, lütfen doğrudan veya dolaylı olarak mesajı
> kullanmayınız ve mesajın tüm kopyalarını sisteminizden derhal siliniz. Bu
> mesaj kişisel veri içerebilir, böyle bir durumda mesajın muhatabı
> değilseniz, ilgili mevzuat kapsamında kişisel veri içeren mesajı tüm
> sistemlerinizden derhal kaldırın. Related Digital, bu e-postada yer alan
> hatalardan veya eksikliklerden sorumlu değildir ve e-posta kullanımından
> kaynaklanan zararlardan sorumlu tutulamaz. Bu mesajda yer alan herhangi bir
> görüş ve beyan ya da herhangi bir ek yalnızca yazarına aittir ve Related
> Digital’i mutlak anlamda temsil etmemektedir.
>
>
> This e-mail content is solely for the individual/entity who has been
> mentioned specifically in the recipient section of the e- mail and intended
> solely for the addressee. If you are not the intended addressee, please do
> not use the message directly or indirectly and delete the message and all
> its copies immediately. This message may contain personal data, if you are
> not the recipient of the message remove the message immediately from all
> your systems under the relevant legislation within the scope of personal
> data. Related Digital is not 

Re: [mailop] Gmail Postmaster Tools Issue?

[Tim Starr via mailop]

I just got confirmation that it's a bug of theirs.

-Tim

On Thu, Dec 12, 2019 at 10:25 AM 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] Strange Optimum bounce code

[Tim Starr via mailop]

Trying those, thanks! Already tried similar role accounts for their other
domains, but those bounced...

-Tim

On Wed, Oct 30, 2019 at 5:50 PM Chris Woods <
christopherwoods+list-mai...@gmail.com> wrote:

> It's an RBL-style block response but it may be due to an internal
> blacklist. Have you contacted optimum/Optonline/Cablevision?
>
> Found ab...@cv.net on https://www.optimum.net/pages/ReportAbuse.html if
> you haven't already tried them... Perhaps also inet...@cv.net? (tech
> contact on ARIN for optonline's block incorporating various mail-related
> servers)
>
> Best of luck
> Chris
>
> On Wed, 30 Oct 2019, 21:15 Tim Starr via mailop, 
> wrote:
>
>> My client the New York Post is getting this intermittent bounce code I've
>> never seen before from optimum.net:
>>
>> 550 5.7.1 Unacceptable Sender address @be6.maropost.com from host
>> 162.247.112.102 : denied - 01
>>
>> What does that mean? I'm trying abuse@ & postmaster@ the mailbox
>> provider, but are there any better channels to reach them?
>>
>> Tim Starr
>> Senior Director - Deliverability
>> Maropost.com
>> ___
>> 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] Strange Optimum bounce code

[Tim Starr via mailop]

Each message has its own unique return-path address with that parent domain
and subdomain naming convention. They're redacting the localpart for
unknown reasons.

-Tim

On Wed, Oct 30, 2019 at 7:45 PM Ángel via mailop  wrote:

> On 2019-10-30 at 16:02 -0500, Tim Starr via mailop wrote:
> > My client the New York Post is getting this intermittent bounce code
> > I've never seen before from optimum.net:
> >
> >
> > 550 5.7.1 Unacceptable Sender address @be6.maropost.com from host
> > 162.247.112.102 : denied - 01
> >
> > What does that mean? I'm trying abuse@ & postmaster@ the mailbox
> > provider, but are there any better channels to reach them?
> >
> > Tim Starr
>
> Which sender address is used on these mails? I would read it as the
> sender being "@be6.maropost.com" (i.e. 'MAIL FROM:<@be6.maropost.com>')
> which yes, would be unacceptable.
>
> (on rfc terms: there is no trailing :, so this is not an at-domain but a
> Mailbox, and mailbox starts with a local-part, which requires at least
> one atom)
>
> Cheers
>
>
> ___
> 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] Strange Optimum bounce code

[Tim Starr via mailop]

My client the New York Post is getting this intermittent bounce code I've
never seen before from optimum.net:

550 5.7.1 Unacceptable Sender address @be6.maropost.com from host
162.247.112.102 : denied - 01

What does that mean? I'm trying abuse@ & postmaster@ the mailbox provider,
but are there any better channels to reach them?

Tim Starr
Senior Director - Deliverability
Maropost.com
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AT - Need assistance with /24 listing

[Tim Starr via mailop]

Seems to be our turn to get a class C blocked by ATT for the first time in
years. Haven't made any progress via official channels yet. Anyone else
have a recommendation?

Tim Starr
Senior Director, Deliverability
Maropost Postmaster
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop