Re: [mailop] oauth2 for mail clients

[Scott Q. via mailop]

What exactly is missing for broad acceptance ?


https://openid.net/specs/openid-connect-discovery-1_0.html  defines
some pretty clear ways to autodiscover the endpoints.


MS & Google and Keycloak both offer this URL:


https://login.microsoftonline.com/domain.com/.well-known/openid-configuration
https://accounts.google.com/.well-known/openid-configuration


I believe the latest Yahoo mobile app won't even connect to imap/smtp
servers that don't have oauth2 support.

It seems as if the big guys are closing down the eco-system...
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Ralph Seichter via mailop]

* Viktor Dukhovni via mailop:

> But even that has been made significantly easier through projects like:
>
> https://mailinabox.email
>
> which deliver a turnkey software appliance that takes care of SMTP,
> IMAP, DNS, ...  Naïve users can start with something along those lines,
> before considering ground up DYI for the whole stack.

I am sure projects like iRedMail or Mail-in-a-Box can be useful for
some. However, based on the venture we are discussing this in (i.e. the
mailop maling list), I would hope that we can assume a degree of
technical expertise and the motivation to expand existing knowledge.

If things go wrong, I expect "naïve users" are going to have a bad time
anyway, unless they bring in outside help. I have nothing against folks
experimenting, with or without prepackaged software stacks, but I don't
recommend experiments when email is business critical. If a mail server
turnkey solution creates a false sense of operating a mail service
stack, I don't consider it a good idea.

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Mohit Godiya via mailop]

Hey All,

I am a MSP operating out of Northern Canada and have been hosting our 
own email servers(builing mailservers ground up using qmail and dovecot 
on debian).
on an average, moving about 5-7K emails a day on average between 100+ 
domains and 1200+ email addresses.

Here to share my experience and not advocate for their services.

I have used serverpronto at my current company and previous company with 
a shared history of about 20+ years.
Recently started moving to a cpanel system due to the company's growing 
hosting customer base.
My experience with them is 100% positive and very quick turn around 
time.
I have about 5 servers with them, some mail servers, custom hosted 
applications and all of them have ipv4 and ipv6.



I also took a stab at vultr with the same setup where I build the 
servers ground up. Not something I would use for production

- anti spam policy MIGHT block traffic to and from your instance
- privacy concerns: I read from sources that they data mine(do your 
research, dont take my word for it)

- their maintenance did affect my services, so not an option

Another player I am exploring is CPanel on godaddy. (purely from a 
economical POV, because I am moving away form building servers from 
scratch)
I would use Godaddy despite their strict anti-spam policy. i.e., if one 
of the emails on your system gets hacked (due to phishing or weak 
password) GD will block your server till you contact them and get them 
to clear your block.


Sorry if this was not the info you were looking for, but sharing my 
years of experience in hosting space(emails and custom applications).


Hope that helps!


On 2024-07-08 17:49, Tony G via mailop wrote:

Friends - Apparently I wasn't clear. Sorry about that.

This isn't a new venture. Long ago, I considered and decided to move
forward against the sage advice "if you're thinking about DIY SMTP,
don't". I've been running our Postfix/Dovecot servers for years now. I
have no problem with that, and I've dealt with the RBLs and other
issues mentioned. It's the additional burden imposed by others that
has raised the priority on this:

 - Too many receiving servers using bad RBLs and for the wrong
reasons.
 - Too many bad actors allowed to commission services.
 - Global IP address pools that are easily compromised.
 - Hosts that can't keep up with the damage from the above bad
decisions.
 - IPv6 not globally implemented yet.

Use existing services? A typical cheap service costs
$5/user/domain/month. (Free? Not when you use your own domains.) For
just 1 user and 10 domains, that $50 is already more than what I pay
for two cloud servers. Multiply that by more users and domains. I'm
also running DNS, websites, and other services on these systems
(arguable practice, but remember, low volume), and I'm already paying
for these servers, so new services only start at doubling my costs.
And because services don't guarantee anything better, we'll still be
subject to the same issues. Been there, done that, not interested.

So for this inquiry I really am asking about reliable hosts - anywhere
in the world. That may or may not include names like Hetzner, Vultr,
or AWS - I'm looking for confirmations. I mean, most people here are
running in a data center - I'd really like to know who is providing
the stable resources.

Or is this a unicorn that doesn't exist?

Thanks again.
___
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] Cloud hosts for responsible mail servers?

[Viktor Dukhovni via mailop]

On Tue, Jul 09, 2024 at 06:34:50PM +0200, Ralph Seichter via mailop wrote:

> It takes some technical knowledge and putting in work to keep
> a mail server running smoothly, 

But even that has been made significantly easier through projects like:

https://mailinabox.email

which deliver a turnkey software appliance that takes care of SMTP,
IMAP, DNS, ...  Naïve users can start with something along those lines,
before considering ground up DYI for the whole stack.

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Jeff Pang via mailop]

On 2024-07-10 08:18, Lyndon Nerenberg (VE7TFX/VE6BBM) via mailop wrote:
With such low volume, you will really struggle to get email delivered 
to the
larger mailbox providers, whose filtering is largely based on 
reputation.
It's almost impossible to build up (and maintain) a reputation unless 
you

can manage at least O(hundreds) of messages to them per day.



That's not my experience.


Mine either.  I've been running my own personal MTAs since the
mid-80s, and have switched VM hosting providers several times over
the years.  There are only three domains I can't send mail to:
sympatico.ca, t-online.de, and bell.net.  All three spit back 5XX
responses in their initial greeting (before I can even send an
EHLO), then promptly hang up.



sympatico.ca, bellnet.ca, bell.net, bellsouth.net, sbcglobal.net, 
att.net ...
from my (limited) experience, they all belong to att systems, and a 
manual confirmation is required for new mailserver sending messages to 
them.


regards.

--
Jeff Pang
jeffp...@aol.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Lyndon Nerenberg (VE7TFX/VE6BBM) via mailop]

> With such low volume, you will really struggle to get email delivered to the
> larger mailbox providers, whose filtering is largely based on reputation.
> It's almost impossible to build up (and maintain) a reputation unless you
> can manage at least O(hundreds) of messages to them per day.

> That's not my experience.

Mine either.  I've been running my own personal MTAs since the
mid-80s, and have switched VM hosting providers several times over
the years.  There are only three domains I can't send mail to:
sympatico.ca, t-online.de, and bell.net.  All three spit back 5XX
responses in their initial greeting (before I can even send an
EHLO), then promptly hang up.

I publish SPF records, but refuse to participate in DKIM or DMARC.
By avoiding the latter two, I don't have to navigate all their
associated stupidity, and my mail goes through just fine.

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Mark Alley via mailop]

Assuming you're talking about Azure Communications Service; from my
experience/knowledge, it shares the same IP space and outbound pools that's
used by Outlook/Live/Exchange Online, etc.

So, yes.

-Mark Alley

On Tue, Jul 9, 2024, 5:36 PM Jeff Pang via mailop  wrote:

> On 2024-07-10 05:43, Ken Johnson via mailop wrote:
> > Opinion based on personal experience follows:
> >
> > I would not choose Amazon SES because of the poor content quality
> > (spam, phishing, etc.) of many messages received here where the header
> > contains the string "amazonses.com".
>
> does azure messages service have that issue?
>
> --
> Jeff Pang
> jeffp...@aol.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] Cloud hosts for responsible mail servers?

[John Levine via mailop]

It appears that Jeff Pang via mailop  said:
>On 2024-07-10 05:43, Ken Johnson via mailop wrote:
>> Opinion based on personal experience follows:
>> 
>> I would not choose Amazon SES because of the poor content quality 
>> (spam, phishing, etc.) of many messages received here where the header 
>> contains the string "amazonses.com".
>
>does azure messages service have that issue?

Well, it doesn't say amazonses but the amount of crud I get from MS'
self-service mail system is so large that I have a separate spam trap
just for Microsoft.

In my experience SES is pretty good.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[John Levine via mailop]

It appears that Tony G via mailop  said:
>This is a key fault in the "system" for which we lack collective drive to
>fix. We don't have industry-accepted mechanisms to expedite communications
>and actions between ISPs and BL entities. This could be handled in seconds
>with automation, while manual processes consume hours and only serve to
>lull all parties to inaction.

I gather you've never had a spammer complain about not accepting their
mail. It is not pleasant, and they will overwhelm your "automatic"
system.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Ken Johnson via mailop]

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of mailop@mailop.org
Sent: Tuesday, July 09, 2024 5:32 PM
To: kjohn...@eclypse.org
Cc: mailop@mailop.org
Subject: Re: [mailop] Cloud hosts for responsible mail servers?

On 2024-07-10 05:43, Ken Johnson via mailop wrote:
> Opinion based on personal experience follows:
> 
> I would not choose Amazon SES because of the poor content quality 
> (spam, phishing, etc.) of many messages received here where the header 
> contains the string "amazonses.com".

does azure messages service have that issue?

-- 
Jeff Pang


--

I am not very familiar with azure messages service, so perhaps not here.  
Perhaps I should be on the lookout, though.

Ken


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

Re: [mailop] Cloud hosts for responsible mail servers?

[Jeff Pang via mailop]

On 2024-07-10 05:43, Ken Johnson via mailop wrote:

Opinion based on personal experience follows:

I would not choose Amazon SES because of the poor content quality 
(spam, phishing, etc.) of many messages received here where the header 
contains the string "amazonses.com".


does azure messages service have that issue?

--
Jeff Pang
jeffp...@aol.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Ken Johnson via mailop]

Opinion based on personal experience follows:

I would not choose Amazon SES because of the poor content quality (spam, 
phishing, etc.) of many messages received here where the header contains the 
string "amazonses.com".  That string in the header gets a +3.0 spamassassin 
bonus on the server I manage.  Your mileage may vary of course.  And it may be 
that my experience with received email with that characteristic is atypical.  
It is true that the content quality of such mail as observed here has improved; 
the 'amazonses' spamassassin bonus used to be even higher.

Your server, your rules.

Ken


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

Re: [mailop] proofpoint - possible missmatch with ipcheck

[Paul Gregg via mailop]

PPE uses PDR, but we use it to reject the connection with a
"550 5.7.1 Service unavailable"
We don't defer - so you shouldn't be seeing PPE causing deferrals
due to PDR.

For PPE at least, this stage is IP reputation only... domain reputation
checks happen later in the engine after mail handoff (so can lead to
mail being quarantined rather than NDRed).

PG


On Thu, Jul 04, 2024 at 11:29:23AM -0500, Mark Alley via mailop wrote:
> I know a rep from PPE is on-list, and can elaborate on the PPE side if they
> want to.
> 
> - Mark Alley
> 
> On Thu, Jul 4, 2024, 11:08 AM Patrick Landolt wrote:
> 
> > There were less mails to *.ppe-hosted.com mx but there were no deferred
> > mails there.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT Block

[Anne P. Mitchell, Esq. via mailop]

> On Jul 9, 2024, at 2:11 PM, Bill Cole via mailop  wrote:
> 
> On 2024-07-09 at 13:53:47 UTC-0400 (Tue, 9 Jul 2024 11:53:47 -0600) 
> Anne P. Mitchell, Esq. via mailop  
> is rumored to have said:
> 
>> Receivers don't block email from new IPs by default; they block them when 
>> they notice something amiss with the email (be it improper authentication, 
>> spam complaints, or something else).
> 
> That's not 100% true. Most receivers don't, some clearly do.

Yes, I should have said "Generally receivers don't block email from new IPs by 
default" and for sake of clarity should have also added "for the sole reason 
that they are new IPs".  

Mea culpa.

Anne

--
Anne P. Mitchell, Esq.
Email Law & Policy Attorney
Legislative Advisor
CEO Institute for Social Internet Public Policy
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, eMail Abuse Prevention System (MAPS)


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

Re: [mailop] [E] Re: AT Block

[L. Mark Stone via mailop]

Feel free to tell me I'm naive/unrealistic/self-serving/whatever (granted I run 
a 98% B2B email hosting company), but I think we on this list bear a collective 
responsibility to educate users that:

1. Free email service providers have a level of customer service commensurate 
with their prices, and;
2. The terms of service for all of the free email providers (whose ToS's I have 
read, which is most of them) contain comparable clauses which grant them a 
perpetual, irrevocable license to email content, including republishing rights 
and the rights to create derivative works.

Sure, there's a role for free email service providers, but not for really 
important emails IMHO. Especially not where the contents are 
sensitive/proprietary/regulated etc., and/or where delivery must be traceable 
and delivery fails rectifiable.

What AT decides to do (or not do) is up to them.  But, if we educate our 
customers that deliveries to free email service providers are neither 
guaranteed, nor is there a mechanism to sort out delivery issues with such free 
email service providers in a timely, interactive manner -- as well as that the 
contents of those emails are no longer private -- then, at least with my 
customers, I have seen my customers better manage their own customers' 
expectations when their customers are using a free email service provider.

Hope that helps, 
Mark 

-- 
_ 
L. Mark Stone, Founder 
North America's Leading Zimbra VAR/BSP/Training Partner 
For Companies With Mission-Critical Email Needs

- Original Message -
| From: "Scott Mutter via mailop" 
| To: "mailop" 
| Sent: Tuesday, July 9, 2024 3:38:07 PM
| Subject: Re: [mailop] [E] Re: AT Block

| On Tue, Jul 9, 2024 at 12:53 PM Anne P. Mitchell, Esq. via mailop < [
| mailto:mailop@mailop.org | mailop@mailop.org ] > wrote:

|| Instead of grumbling, if you can give us information, perhaps someone here 
can
|| help you.

| You are right - if an IP is blocked, it's likely blocked for a reason. The
| question is whether that reason is stupid or not.

| A lot of times I suspect that the IP address is blocked because of a larger
| network block. Instead of blocking individual IPs, providers choose to block
| entire Class-C's or Class-B's.

| Now, as I've tried to explain - perhaps I did that poorly - that's not the way
| IP addresses are used any more, at least in some industries. If, as a 
provider,
| you are getting spam from 23.239.97.121, 23.239.97.63, and 23.239.97.24 - then
| when you block the entire Class-C [ http://23.239.97.0/24 | 23.239.97.0/24 ] ,
| you're blocking a lot of IPs that have nothing to do with each other. I
| understand that you, as a provider, can't really know that. But, as a teaching
| moment, you - as a provider - should know that this is plausible.

| I understand that people probably don't want to hear that because it goes
| against what they've gotten ingrained as how server administration and IP
| addressing works. There's a lot of "My way works, it's always worked, and
| that's the way it's always going to be."

| As I've said, we're on this list to learn, correct?

| Having said that - I don't so much mind a provider blocking an entire Class-C,
| BUT when a verified administrator of an IP address in that Class-C writes in
| about the block and you can find zero/zilch/nada complaints of spam from that
| IP address, then it should be excluded from the block. This process shouldn't
| take days or weeks to complete, it should just take hours.

| And if a too-big-to-fail email service provider is going to block IP 
addresses,
| they should offer Feedback Loops and they should have to send something to 
that
| Feedback Loop before the IP address can be blocked. Numerous times I've had 
IPs
| blocked when the IPs were on Feedback Loops and I've gotten zero/zilch/nada
| from the Feedback Loop prior to the block happening. I've never gotten a hint
| of ANY activity on any of our servers with Google because apparently we fall
| below the cutoff to register any type of feedback. If we register that low,
| then what's the justification for blocking a server when we can't get any
| feedback?

| My gripe right now with AT is why do they even include [
| mailto:abuse_...@abuse-att.net | abuse_...@abuse-att.net ] in their rejection
| notice if they're never going to respond to inquiries to that address? I wrote
| that address on July 2 about an IP being blocked. It's now July 9th. I haven't
| heard a peep from them. No I have written them again. I shouldn't have to. If
| they're telling me to write to [ mailto:abuse_...@abuse-att.net |
| abuse_...@abuse-att.net ] to get my issue addressed then they need to expect
| email at [ mailto:abuse_...@abuse-att.net | abuse_...@abuse-att.net ] and
| respond to those messages. They're not doing that. Before they shutdown their
| community forums there was a HUGE thread there about the lack of response from
| [ 

Re: [mailop] [E] Yahoo 'temporarily' deferred

[Kasper Peeters via mailop]

> >  [TSS05] Messages from x.x.x.x temporarily deferred due to unexpected
> > volume or user complaints - 4.16.55.1; see
> > https://postmaster.yahooinc.com/error-codes  
> 
> 
> Click that link. Read through it. Open a ticket with the support team.

I did that, but it doesn't seem to have had any effect. No response, and 
messages still waiting in the queue. Apologies if I am impatient.

Thanks,
Kasper




pgpuzNkGLktZK.pgp
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT Block

[Bill Cole via mailop]

On 2024-07-09 at 13:53:47 UTC-0400 (Tue, 9 Jul 2024 11:53:47 -0600)
Anne P. Mitchell, Esq. via mailop 
is rumored to have said:

Receivers don't block email from new IPs by default; they block them 
when they notice something amiss with the email (be it improper 
authentication, spam complaints, or something else).


That's not 100% true. Most receivers don't, some clearly do.

My 2 (satisfactory, if a bit slow) experiences with AT blocking IPs 
have both  been with IPs that had never previously sent any mail. Until 
AT unblocked them, AT had never seen any mail from them at all in 
the lifetime of the Internet. Both were in an ARIN-allocated /21 network 
with accurate contact info.





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Tony G via mailop]

Michael Peddemors wrote:

>
> Transparency is key.  Make sure your rDNS is sane, has your domain, and
> an associated URL for that domain.
>

Yes, RDNS, DMARC, DKIM, and SPF ... all done correctly, and we can still
get on a list through no fault of our own.



> However, yes.. hosting companies DO complain that it can take up to 8
> man hours for removal.


This is a key fault in the "system" for which we lack collective drive to
fix. We don't have industry-accepted mechanisms to expedite communications
and actions between ISPs and BL entities. This could be handled in seconds
with automation, while manual processes consume hours and only serve to
lull all parties to inaction.

This is why I'm looking for an assertive and proactive host with
established relationships that eliminate or mitigate that long and painful
process.



> and you might want to consider your neighbours on
> the provider you have chosen.  If the hosting company allows spammers,
> you might get painted by the same brush. And if you have a hosting
> company that doesn't support you getting off a blocklist, it is a good
> indication you have the wrong provider.
>

I've been with my big hosting company for almost twenty years, running my
own SMTP servers for about five. Overall they're a decent company in a
complex industry that shares many challenges.

Like all hosts, they have policies against outbound spam, and REact when
there are issues. But I don't believe there is enough incentive for them to
be PROactive to prevent outbound abuse, or to implement and improve
mechanisms to react quickly enough when it happens. I've made many
suggestions to their management that I know have been considered. But
effective changes have not been made and the problems continue. So yes,
this is an indication that I have the wrong provider for my use case, and
that's why I finally posted here.



> You get what you pay for.. the hoster offering $.99 hosting can't afford
> good engineers or support teams problably, and don't give a darn who
> signs up..
>

If management decides to attract more random business to increase revenue,
and to cut costs for the resulting problems, that's just bad management,
and typical in corporate acquisitions as ISPs are bought up. The practice
sacrifices quality for quantity and ultimately sabotages the future. A "99
cent" host could make better business decisions, and secure even more
quantity by providing a higher level of quality. That's insight that takes
a bit more forethought and drive to implement. I don't think the pricing
model is directly related to the quality, that "you get what you pay for".
Paying more doesn't truly imply better services.

To be clear, I cited an example of our modest mail needs, but I am not
interested in cheap hosting. The established per-user/per-domain pricing
model doesn't agree with the less-common use case where there are many
domains and a few users. I also run my own DNS, LAMP sites, and more. For
our purposes here I'm looking to pay a reasonable fee to the right host(s)
for better services.

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

Re: [mailop] [E] Re: AT Block

[Scott Mutter via mailop]

On Tue, Jul 9, 2024 at 12:53 PM Anne P. Mitchell, Esq. via mailop <
mailop@mailop.org> wrote:

>
> Instead of grumbling, if you can give us information, perhaps someone here
> can help you.
>
>
You are right - if an IP is blocked, it's likely blocked for a reason.  The
question is whether that reason is stupid or not.

A lot of times I suspect that the IP address is blocked because of a larger
network block.  Instead of blocking individual IPs, providers choose to
block entire Class-C's or Class-B's.

Now, as I've tried to explain - perhaps I did that poorly - that's not the
way IP addresses are used any more, at least in some industries.  If, as a
provider, you are getting spam from 23.239.97.121, 23.239.97.63, and
23.239.97.24
- then when you block the entire Class-C 23.239.97.0/24, you're blocking a
lot of IPs that have nothing to do with each other.  I understand that you,
as a provider, can't really know that.  But, as a teaching moment, you - as
a provider - should know that this is plausible.

I understand that people probably don't want to hear that because it goes
against what they've gotten ingrained as how server administration and IP
addressing works.  There's a lot of "My way works, it's always worked, and
that's the way it's always going to be."

As I've said, we're on this list to learn, correct?

Having said that - I don't so much mind a provider blocking an entire
Class-C, BUT when a verified administrator of an IP address in that Class-C
writes in about the block and you can find zero/zilch/nada complaints of
spam from that IP address, then it should be excluded from the block.  This
process shouldn't take days or weeks to complete, it should just take hours.

And if a too-big-to-fail email service provider is going to block IP
addresses, they should offer Feedback Loops and they should have to send
something to that Feedback Loop before the IP address can be blocked.
Numerous times I've had IPs blocked when the IPs were on Feedback Loops and
I've gotten zero/zilch/nada from the Feedback Loop prior to the block
happening.  I've never gotten a hint of ANY activity on any of our servers
with Google because apparently we fall below the cutoff to register any
type of feedback.  If we register that low, then what's the justification
for blocking a server when we can't get any feedback?

My gripe right now with AT is why do they even include
abuse_...@abuse-att.net in their rejection notice if they're never going to
respond to inquiries to that address?  I wrote that address on July 2 about
an IP being blocked.  It's now July 9th.  I haven't heard a peep from
them.  No I have written them again.  I shouldn't have to.  If they're
telling me to write to abuse_...@abuse-att.net to get my issue addressed
then they need to expect email at abuse_...@abuse-att.net and respond to
those messages.  They're not doing that.  Before they shutdown their
community forums there was a HUGE thread there about the lack of response
from abuse_...@abuse-att.net.  This has been going on for years.

It's not necessarily the act of blocking IPs that gets stuck in my craw,
it's the lack of avenues for timely remediation.  It's the lack of evidence
to support an IP specific block, whether that be a Feedback Loop or listing
with another publicly accessible RBL.  It's the lack of avenues to notify
beforehand that a new IP address will be sending out mail.  It's the lack
of understanding that an IP address owner isn't necessarily the
administrator of the server operating on that IP address.  And there's a
lack of caring to learn anything new.

This will be the end of email when providers and administrators all around
the world stick to their "it's my way or the highway" motto and email
interoperability goes out the window.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT Block

[Ralph Seichter via mailop]

* Matt Vernhout:

> I'd say my usual experience is different, having worked with dozens of
> organizations moving to new Dedicated IPs for sending marketing emails
> [...]

I have not yet had dealings with customers who were in the business of
sending email for marketing purposes. I can imagine that different rules
apply to them, compared to my usual clientele who send mostly "hand
crafted" email (i.e. written by humans for a small number of recipients).

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

Re: [mailop] [E] Re: AT Block

[Gellner, Oliver via mailop]

On 09.07.2024 at 20:33 Ralph Seichter via mailop wrote:

* Anne P. Mitchell:

Receivers don't block email from new IPs by default; they block them
when they notice something amiss with the email (be it improper
authentication, spam complaints, or something else).

That looks like a too generalised assessment to me. As I mentioned in a
different thread on this mailing list, my experience with Telekom /
T-Online has been that their MXs soft-block servers with unfamiliar IPs
from handing over email by default.

There have been lengthy threads about this behavior of t-online.de like 
https://www.mail-archive.com/mailop@mailop.org/msg17245.html

Actually this is even documented in their mail server policy:
„A block may be in place, in particular, if you want to use an IP address that 
you have not previously used for sending e-mails“
https://postmaster.t-online.de/index.en.html#t4.7

Read: No throttling but a permanent block which can only be lifted by manual 
intervention.

I strongly discourage such an approach for reasons already mentioned, however 
there are in fact postmasters who put servers without a reputation (new 
servers) in the same basket as spam sending servers.

—
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.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Tony G via mailop]

Michael Peddemors wrote:

> It's not that hard to get off blocklists, but suggest you work with a
> hosting company that offers 'rwhois'.  That way it is easy to see that
> you are the new responsible party, and when you were assigned the IP
> address, so historical problems should not affect you.
>

I see rwhois as just another optional protocol that doesn't solve the
problems. First we need a host that supports it. Then we need RBLs that all
check and respect it. And/Or we need mail servers that check it and allow
legitimate IPs even if they're reported by a RBL.

You are correct. It is not that hard to get off blocklists. And correct
again (snipped) that it's most effective to take a few minutes to provide a
good request for exclusion, even IMO if it's processed by a bot. The
problem is that it can take hours to days or more for a list manager to
remove an address, and during this process damage might be done.

But when we go through the process once with a BL to establish credibility
for ourselves and our responsibility for an IPv4 address, we can only hope
that they wouldn't block the address again a year later. But some do
re-block, because they do not WL individual addresses when they BL an
entire class-C address block. And mail servers that use those lists also
don't check to see if the IP was banned for individual abuse or as a
collective slap on the hand against clients of a host.

There is too much inertia and apathy in the world to drive initiatives for
better processes. Big changes only seem to be effected when big providers
put their foot down and simply block transactions that don't comply with
their industry-level decisions.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT Block

[Matt Vernhout via mailop]

On Tue, Jul 9, 2024 at 2:32 PM Ralph Seichter via mailop 
wrote:

> * Anne P. Mitchell:
>
> > Receivers don't block email from new IPs by default; they block them
> > when they notice something amiss with the email (be it improper
> > authentication, spam complaints, or something else).
>
> That looks like a too generalised assessment to me. As I mentioned in a
> different thread on this mailing list, my experience with Telekom /
> T-Online has been that their MXs soft-block servers with unfamiliar IPs
> from handing over email by default.
>
> One needs to contact them via a specific service address contained in
> the rejection message, and have the new IP address cleared for mail
> delivery to T-Online operated domains. That's not exactly in the spirit
> of a free Internet, but obtaining server clearance is a matter of a few
> hours only, based on my own experience with this process over the years.
> It is also a once-per-IP-address thing.
>
>
I'd say my usual experience is different, having worked with dozens of
organizations moving to new Dedicated IPs for sending marketing emails,
Rate limits and slow growth is usually the way to resolve these blocks. At
AT and other mailbox providers, such as Yahoo.you need to send a trickle
of email at first to their networks, fully authenticated, and of high
quality (Desired emails) that are going to get good engagement from the
initial users. Then you can gradually grow this number over the next
several weeks.

Grow to fast, or don't properly look at the MXs/domain groups associated
with the network (i.e. Bellsouth, att, SBC, etc...), and you'll trigger the
alerts and get blocked. These are generally temporary, so back off and wait
and try again at a lower volume later.

T-online has a very specific set of rules that they want senders to follow,
the same thing applies to them: follow the rules, send slow and grow and
you typically won't have generic problems out of the gate.

Some mailbox providers appreciate a heads up to say - NEW IP coming online
please be aware - and they will take steps to help you out Yahoo and
Outlook are examples of this.

Turning on the firehose of email is not usually the best option for new IPs
regardless of the mail being sent.

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

Re: [mailop] [E] Re: AT Block

[Jaroslaw Rafa via mailop]

Dnia  9.07.2024 o godz. 11:53:47 Anne P. Mitchell, Esq. via mailop pisze:
> 
> Receivers don't block email from new IPs by default;

Some certainly do.

Perhaps the most known example is T-Online, as mentioned here in another
email. It's their official policy. Every new (unknown) sending IP is blocked
by default until admin contacts them and asks to be unblocked. I went
through this as well.

I have no experience with sending mail to AT, but from my experience,
similar case to T-Online applies to big Russian email service mail.ru (they
even have a special web form for unblocking requests to which they provide
link in the rejection message, and are handling this very effectively), and
in some extent to Microsoft. They also block unknown IPs, although some IP
ranges seem to be already unblocked by default. But if you happen not to be
in such a range, you get a reject (as it has been reported multiple times on
this list) and you have to contact them to be unblocked (usually you need
to escalate the request and contact them more than once).

So no, *in general* it is not true that "receivers don't block email from
new IPs by default". *Most* receivers don't, but they are some who do.
-- 
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

Re: [mailop] [E] Re: AT Block

[John Levine via mailop]

It appears that Anne P. Mitchell, Esq. via mailop  said:
>Receivers don't block email from new IPs by default; they block them when they 
>notice something amiss with the email (be it
>improper authentication, spam complaints, or something else).

Actually, they do. I recently renumbered my network into a /24 that
was allocated in the 1990s but had never been routed before. Yahoo
blocked all my mail. Someone I know there told me that they
automatically block any newly routed space on the assumption that it's
hijacked, and they're usually right. Then he unblcked it, but if I
hadn't happened to know him, it would have taken a while to do. It
sounds like AT does the same thing.

Similarly, even if an IP has been routed, if it suddenly starts sending
a lot of mail, it'll be blocked because that usually means it's spam.
There is a lot of folklore about how you "warm up" an IP sending
enough mail to get an IP reputation but not enough to trigger the
spam blocks.

Yeah, it's awful, but as someone might have mentioned, spammers ruin everything.

R's,
John

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

Re: [mailop] [E] Re: AT Block

[Ralph Seichter via mailop]

* Anne P. Mitchell:

> Receivers don't block email from new IPs by default; they block them
> when they notice something amiss with the email (be it improper
> authentication, spam complaints, or something else).

That looks like a too generalised assessment to me. As I mentioned in a
different thread on this mailing list, my experience with Telekom /
T-Online has been that their MXs soft-block servers with unfamiliar IPs
from handing over email by default.

One needs to contact them via a specific service address contained in
the rejection message, and have the new IP address cleared for mail
delivery to T-Online operated domains. That's not exactly in the spirit
of a free Internet, but obtaining server clearance is a matter of a few
hours only, based on my own experience with this process over the years.
It is also a once-per-IP-address thing.

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

Re: [mailop] [E] Re: AT Block

[Anne P. Mitchell, Esq. via mailop]

> blocking our IP address for no reason

In my 20+ years experience, there is never "no reason".  The reason may not be 
clearly revealed, the rejection message may be lacking in useful information, 
and the reason may be wrong, but blocks are there for a reason, even if not 
discernible by the sender.

> it should be more commonly understood that it's impossible to work with said 
> too-big-to-fail mail service provider, they just simply don't care.

I think that Hanlon's razor can be applied here.  Never ascribe to malice (or 
in this case, perhaps, apathy) that which can be explained by stupidity (or, in 
this case, ignorance or unawareness).

I've never, again, in my years of experience, run into a receiver who simply 
didn't care that their users were not receiving email that their users wanted.

> I do suspect that John Von Essen's opinion has some merit.  I wish this 
> information was posted on a trusted third party website.  Something to point 
> customers to when they complain about being unable to send mail to @att.net 
> email addresses.  There's no telling what email those same @att.net users are 
> not getting.

People who are trusted do have that information.  It's never going to be posted 
publicly on a website because a) spammers, b) malicious actors, c) people who 
just want to harass the people working for such entities, and d) people who are 
disgruntled or generally have a bone to pick, an ax to grind, or whom otherwise 
want to rant at them.

Is it a perfect system?  No, not by any means.

But it's not quite as broken as you think (and trust me I feel your pain).

You mentioned in your initial email that the issue is with these IP addresses:

23.239.97.150
5.101.141.35

AND that you "suspect that this is being blocked because these are new IPs that 
AT has never received mail from, so they block them by default."

Receivers don't block email from new IPs by default; they block them when they 
notice something amiss with the email (be it improper authentication, spam 
complaints, or something else).

What is the nature of the email which was being sent through those IP addresses?

Instead of grumbling, if you can give us information, perhaps someone here can 
help you.

Anne

--
Anne P. Mitchell, Esq.
Email Law & Policy Attorney
Legislative Advisor
CEO Institute for Social Internet Public Policy
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, eMail Abuse Prevention System (MAPS)





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

Re: [mailop] Cloud hosts for responsible mail servers?

[Pete Long via mailop]

> On 9 Jul 2024, at 07:40, Andrew C Aitchison via mailop  
> wrote:
> 
> 
> On Tue, 9 Jul 2024, Andy Beverley via mailop wrote:
> 
>> On 09/07/2024 03:17, Philip Paeps via mailop wrote:
>>> I've had a VM at Mythic Beasts doing mail for several years.  They're rock 
>>> solid and all my interactions with them have been very positive.  I don't 
>>> have any stake in them other than as a happy customer.
>> 
>> +1 for Mythic Beasts. You also have some choice over the region that you 
>> host in. Let's support the small hosting providers :)
> 
> I too am very happy with Mythic Beasts,
> although I use their email service, rather than running my own.
> 

Another +1 for Mythic Beasts. I've purchased all of my domains through them and 
have even had a dedicated server with them which was excellent.

Currently I'm just paying for the web hosting service.


Pete.

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Ralph Seichter via mailop]

* Michael Breuer via mailop:

> If you start from scratch: After booking your VM / IP check dns
> blocklists for the reputation of your new IP address. If you get a bad
> IP assigned, change it.

Agreed. The hosting company should feel motivated to get their IP
addresses unlisted, and has staff and potentially more leverage to
see it done.

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Ralph Seichter via mailop]

* Bjoern Franke via mailop:

> When everybody only uses a service for final delivery we possibly
> end up in a scenario in which only mails from the big players are
> accepted.

Good point!

I'd say that, based on the responses in this thread so far, it is
reasonable to assume that rolling your own mail server, even at a hoster
with less than stellar reputation for keeping out bad actors, is still
possible. It takes some technical knowledge and putting in work to keep
a mail server running smoothly, but if the operator is OK with these
requirements, I would encourage them to go for it. Falling back to some
paid service at a later time is still possible, if the home grown
solution does not quite turn out as expected.

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Michael Peddemors via mailop]

On 2024-07-09 07:58, Michael Breuer via mailop wrote:




On 9. Jul 2024, at 03:41, John Levine via mailop  wrote:


So for this inquiry I really am asking about reliable hosts - anywhere in
the world. That may or may not include names like Hetzner, Vultr, or AWS -


Take a look at Amazon SES. It's a pain to set up, but it's well run,
their mail gets delivered, and it's quite cheap. Their price estimator
says that 10 messages a day will be 15 cents/month. The free intro
lets you send 3000 messages/mo for a year.

You have to tell them and verify what domains you're sending from but the 
pricing
is per message, not per domain.

If you want your own IP, which at those volumes I doubt you do, it's
about $40/mo plus the message charge.



Please, don’t use Amazon SES. SMTP was designed as an open, interoperable 
protocol and I consider the market concentration harmful to the open internet. 
While others argue, that it’s too late to stop this process from my perspective 
it’s easier to start doing the right thing today than tomorrow.

Delivering mail from a cloud host / VM to the big players works reasonably well 
for me. If you start from scratch: After booking your VM / IP check dns 
blocklists for the reputation of your new IP address. If you get a bad IP 
assigned, change it. It’s easier than trying to remove it from the blocklists.

Regards,
Michael

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


It's not that hard to get off blocklists, but suggest you work with a 
hosting company that offers 'rwhois'.  That way it is easy to see that 
you are the new responsible party, and when you were assigned the IP 
address, so historical problems should not affect you.


Transparency is key.  Make sure your rDNS is sane, has your domain, and 
an associated URL for that domain.


https://www.m3aawg.org/sites/default/files/m3aawg-blocklist-help-bp-2018-02.pdf

And for gods' sake.. don't simply say 'remove me' and expect the 
blocklist operator to be much more helpful.  Provide full information on 
the server, and what it is used for.


However, yes.. hosting companies DO complain that it can take up to 8 
man hours for removal. and you might want to consider your neighbours on 
the provider you have chosen.  If the hosting company allows spammers, 
you might get painted by the same brush. And if you have a hosting 
company that doesn't support you getting off a blocklist, it is a good 
indication you have the wrong provider.


You get what you pay for.. the hoster offering $.99 hosting can't afford 
good engineers or support teams problably, and don't give a darn who 
signs up..



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

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

[mailop] Anyone from Namecheap on this list to stop a cat and mouse playing scamer?

[Benoît Panizzon via mailop]

Hi 

If you could contact me offlist would be great.

I'm playing Cat and Mouse with one of your fraud email sending
customers who, as I see it, just registers a new domain and opens a
new email hosting with namecheap as soon as he is being disconnected by
the namecheap abuse desk.

Sometime within 24 hours after being disconnected he is is back sending
scam mails from another namecheap hosted ip and domain.

-- 
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

Re: [mailop] Cloud hosts for responsible mail servers?

[Michael Breuer via mailop]

> On 9. Jul 2024, at 03:41, John Levine via mailop  wrote:
> 
>> So for this inquiry I really am asking about reliable hosts - anywhere in
>> the world. That may or may not include names like Hetzner, Vultr, or AWS -
> 
> Take a look at Amazon SES. It's a pain to set up, but it's well run,
> their mail gets delivered, and it's quite cheap. Their price estimator
> says that 10 messages a day will be 15 cents/month. The free intro
> lets you send 3000 messages/mo for a year.
> 
> You have to tell them and verify what domains you're sending from but the 
> pricing
> is per message, not per domain.
> 
> If you want your own IP, which at those volumes I doubt you do, it's
> about $40/mo plus the message charge.


Please, don’t use Amazon SES. SMTP was designed as an open, interoperable 
protocol and I consider the market concentration harmful to the open internet. 
While others argue, that it’s too late to stop this process from my perspective 
it’s easier to start doing the right thing today than tomorrow. 

Delivering mail from a cloud host / VM to the big players works reasonably well 
for me. If you start from scratch: After booking your VM / IP check dns 
blocklists for the reputation of your new IP address. If you get a bad IP 
assigned, change it. It’s easier than trying to remove it from the blocklists.

Regards,
Michael

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

Re: [mailop] [E] oauth2 for mail clients

[Marcel Becker via mailop]

On Tue, Jul 9, 2024 at 4:47 AM Kai Bojens via mailop 
wrote:

> there is actually no standard for implementing oauth2 for mail
> authentication and that the authentication for Google and Microsoft in
> mail clients is only for those two specific providers.
>
> Is this about right or have I missed something?
>

Incorrect. Oauth2 support is much broader and there's an RFC.

But clients have to explicitly support specific end-points.

Here's documentation on our implementation:
https://developer.yahoo.com/oauth2/guide/
Here's the RFC: https://datatracker.ietf.org/doc/html/rfc6749
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Al Iverson via mailop]

I also have run my own outbound Postfix MTA for years with no
problems, but a couple weeks ago my ISP decided to renumber my server,
so I lost 13 years of sender reputation history, boo.
I can -- and probably will -- go back to warm that new IP up and use
it for my dedicated MTA again, but for now I've switched over to
Amazon SES.
Like others have said, it's dead easy to set up. You can configure
Postfix to SMTP relay out through it easily enough.
I'm happy with it.

Cheers,
Al



-- 

Al Iverson // 312-725-0130 // Chicago
http://www.spamresource.com // Deliverability
http://www.aliverson.com // All about me
https://xnnd.com/calendar // Book my calendar
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] oauth2 for mail clients

[Brotman, Alex via mailop]

The support is a bit broader than that, however, there isn't currently a great 
method for auto-discovery/configuration.  For example, I believe that iOS and 
Yahoo have support for other providers in their clients, and Thunderbird 
supports I think ten or so providers.  There have been some discussions to try 
to make that auto-configuration a bit easier, and I suppose a bit more secure.  
Many folks would prefer that OAUTH support be more broadly deployed across 
providers and clients for a few reasons.

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

> -Original Message-
> From: mailop  On Behalf Of Kai Bojens via
> mailop
> Sent: Tuesday, July 9, 2024 7:28 AM
> To: mailop@mailop.org
> Subject: [EXTERNAL] [mailop] oauth2 for mail clients
> 
> I did some research on oauth2 for mail clients as I was thinking about
> implementing this feature for our servers. All I could find was that there is
> actually no standard for implementing oauth2 for mail authentication and that
> the authentication for Google and Microsoft in mail clients is only for those
> two specific providers.
> 
> Is this about right or have I missed something?
> ___
> mailop mailing list
> mailop@mailop.org
> https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!CQl3
> mcHX2A!G9kNl5HcB8IH8m4pYREL6Iy-
> evVnlVHvNFbopov57KN9mH40ImiDG8e3i1egpgSj6L-Bqlssji218vWW8Ug$
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] oauth2 for mail clients

[Taavi Eomäe via mailop]

On 09/07/2024 14:27, Kai Bojens via mailop wrote:
I did some research on oauth2 for mail clients as I was thinking about 
implementing this feature for our servers. All I could find was that 
there is actually no standard for implementing oauth2 for mail 
authentication and that the authentication for Google and Microsoft in 
mail clients is only for those two specific providers.


Is this about right or have I missed something?


There's the OIDC Dynamic Client Registration spec which might be what 
you're looking for. However, client support is currently lacking (and 
lack of server support has been brought up as the cause).


Most mail clients (I know of) that support OAuth2 in some way or form do 
so on per-provider basis.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] oauth2 for mail clients

[Neil Jenkins via mailop]

On Tue, 9 Jul 2024, at 21:27, Kai Bojens via mailop wrote:
> All I could find was that  there is actually no standard for implementing 
> oauth2 for mail  authentication and that the authentication for Google and 
> Microsoft in mail clients is only for those two specific providers.
> 
> Is this about right or have I missed something?

That's correct, however there is considerable industry interest in fixing this 
. 

Cheers,
Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] oauth2 for mail clients

[Jeff Pang via mailop]

On 2024-07-09 19:27, Kai Bojens via mailop wrote:
I did some research on oauth2 for mail clients as I was thinking about 
implementing this feature for our servers. All I could find was that 
there is actually no standard for implementing oauth2 for mail 
authentication and that the authentication for Google and Microsoft in 
mail clients is only for those two specific providers.




I login into yahoo via thunderbird, which always implements oauth for 
the authentication.


--
Jeff Pang
jeffp...@aol.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Jeff Pang via mailop]

On 2024-07-09 17:54, Julian Bradfield via mailop wrote:

On 2024-07-09, Ralph Seichter via mailop  wrote:

* Philip Paeps via mailop:


With such low volume, you will really struggle to get email delivered
to the larger mailbox providers, whose filtering is largely based on
reputation. It's almost impossible to build up (and maintain) a
reputation unless you can manage at least O(hundreds) of messages to
them per day.




I have run different mailservers in different DC, it includes,

1. Azure west/east coast
2. RamNode (LA,US)
3. Liteserver (NL)
4. Netcup (DE)
5. Vultr (JP)
6. Naranja (NL)

They all seem having no delivery issues to those big providers.

(except for ATT and Telekom, they require a manual confirmation for new 
IP/server.)


--
Jeff Pang
jeffp...@aol.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] oauth2 for mail clients

[Kai Bojens via mailop]

I did some research on oauth2 for mail clients as I was thinking about 
implementing this feature for our servers. All I could find was that 
there is actually no standard for implementing oauth2 for mail 
authentication and that the authentication for Google and Microsoft in 
mail clients is only for those two specific providers.


Is this about right or have I missed something?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Julian Bradfield via mailop]

On 2024-07-09, Ralph Seichter via mailop  wrote:
> * Philip Paeps via mailop:
>
>> With such low volume, you will really struggle to get email delivered
>> to the larger mailbox providers, whose filtering is largely based on
>> reputation. It's almost impossible to build up (and maintain) a
>> reputation unless you can manage at least O(hundreds) of messages to
>> them per day.
>
> I disagree, because I have never struggled to get mail from my servers
> delivered to Google, Microsoft, etc.  Telekom appears to soft-block
> unfamiliar mail servers by default, and I had to notify them whenever
> a new server went online, but that was a one-time measure for each
> individual server. Call it a minor nuisance.

Similarly. I've been running my own mailserver for personal, family
and club domains (including a mailing list of several hundred at one
point) for 20 years or so. In the early days, there were no problems;
nowadays if I change server (I run one primary and two backups,
changin the provider only if one goes bust or becomes useless, so
changes are rare) I have to go through Microsoft's hoops (and
t-online, but they're more trouble than it's worth usually), but I
haven't run into my problem.

One of my users forwards all their mail to gmail, including the spam,
so sometimes I get rate-limited by gmail, but who cares.

(Unlike most people on this list, I do not think it is a provider's
job to censor people's email. Users should be able to see their spam
if they wish. I'm slightly curious about spam volumes - in my incoming
personal mail, last time I checked about 75% of it was spam. Is that
typical, or very low?)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Bjoern Franke via mailop]

Hi,



Gone are the days when you could just throw a Linux box up in a colo and 
expect to get your mail delivered. You can easily become the unwitting 
victim of being in a bad IP neighborhood through no fault of your own. 
Although this advice is painful, I recommend using a service for final 
delivery. Many services with free tiers are out there and would provide 
more than ample capacity for your volume at no cost.




I disagree. Except with some S1350-issues with Microsoft from time to 
time I had no issues e.g. when running a server at Netcup, which also 
offers now servers in the US.
When everybody only uses a service for final delivery we possibly end up 
in a scenario in which only mails from the big players are accepted.


Regards
Bjoern


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

Re: [mailop] Cloud hosts for responsible mail servers?

[Viktor Dukhovni via mailop]

On Tue, Jul 09, 2024 at 07:40:04AM +0100, Andrew C Aitchison via mailop wrote:

> > +1 for Mythic Beasts. You also have some choice over the region that you
> > host in. Let's support the small hosting providers :)
> 
> I too am very happy with Mythic Beasts,
> although I use their email service, rather than running my own.

Perhaps you'd be willing to encourage them to deploy inbound DANE (but
only with monitoring and a robust automated cert rollover process)?

https://stats.dnssec-tools.org/explore/?mythic-beasts.com

They've paid the price of admission (DNSSEC signed domain), may as well
enjoy the ride...

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Andrew C Aitchison via mailop]

On Tue, 9 Jul 2024, Andy Beverley via mailop wrote:


On 09/07/2024 03:17, Philip Paeps via mailop wrote:
I've had a VM at Mythic Beasts doing mail for several years.  They're 
rock solid and all my interactions with them have been very positive.  
I don't have any stake in them other than as a happy customer.


+1 for Mythic Beasts. You also have some choice over the region that you 
host in. Let's support the small hosting providers :)


I too am very happy with Mythic Beasts,
although I use their email service, rather than running my own.

They charge by domain, not per username, which works well for me
though maybe not for the OP with one user and 10 domains,
but I am paying less than his five bucks per month.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT Block

[Michael Rathbun via mailop]

On Mon, 8 Jul 2024 20:24:28 -0500, Scott Mutter via mailop 
wrote:

>I do suspect that John Von Essen's opinion has some merit.  I wish this
>information was posted on a trusted third party website.  Something to
>point customers to when they complain about being unable to send mail to @
>att.net email addresses.  There's no telling what email those same @att.net
>users are not getting.

Actually, the important party that's being entirely left out of this
discussion, the end user, is the one who needs the information.  A couple of
my clients have put notices on their sign-up forms, notifying persons with the
following email providers ... that they may not receive acknowledgements,
notifications, receipts, or other communications simply because the provider
they have selected cannot afford to exercise due diligence in their email
blocking.

A symmetrically opposite problem is when, e.g., Gmail users complain to me
that their recent mail was returned to them by Google, showing a

> 530 4.7.0 Connection refused 

response when the message delivery was attempted.

I have to respond that Google allows users to send between 20 and 40 messages
per week to "sudden death" spamtraps at this tiny domain, each of which will
cause the sending IP address to be banned for at least 24 hours.  Eventually,
a significant percentage of Google's outbound server farm is in the dog house.
They need to select a different provider.  Nobody is "too big to block".  My
users know this up front.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Peter via mailop]

On 9/07/24 13:47, Cody Millard via mailop wrote:

On 7/8/2024 7:49 PM, Tony G via mailop wrote:


 That may or may not include names like Hetzner, Vultr, or AWS - I'm 
looking for confirmations.



I use Vultr to host my email server.  You must ask support to unblock 
port 25, answer a few questions about your emails and agree to the 
following anti-spam policy.


https://www.vultr.com/legal/antispam-policy/

Ive never experienced a blocked due to IP reputation.


I too use Vultr and have not had issues with deliverability from them. 
I started before they implemented the port 25 block so I never had to 
fill out the form but that policy is a good thing, it really goes a log 
ways towards keeping the bad actors off of their IP space which helps to 
keep their IP reputation clean for legitimate users.  It is by no means 
a silver bullet but it sure is a good starting place.



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