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

[Scott Mutter via mailop]

On Mon, Jul 8, 2024 at 3:23 PM John Levine  wrote:

> It appears that Scott Mutter via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >On Sun, Jul 7, 2024 at 7:54 AM Alessandro Vesely via mailop <
> >In my opinion this is where the industry could use some oversight.  As you
> >say there is nothing to stop a large operator from blocking a small
> >operator simply because they can. ...
>
> You really REALLY do not want to go there. There are a lot of spammers
> who send mail that is 100% CAN-SPAM compliant. (It's not hard.) If a
> big mailer has to deliver your mail, why don't they have to deliver
> the spammer's mail, too?
>
> Apropos of Anne's comment, the CDA says providers can block material
> they consider "obscene, lewd, lascivious, filthy, excessively violent,
> harassing, or otherwise objectionable."  Courts have repeatedly found
> that otherwise objectionable includes spam filtering.
>
> R's,
> John
>

Most of the comment about oversight was meant as tongue-in-cheek.  But I do
echo everything that Alessandro Vesely said.  It's impossible for a
small-time operator to get any traction with any of the too-big-to-fail
mail service providers, they just simply don't care.  I think that should
be more publicly announced.  When one of these too-big-to-fail mail service
providers are blocking our IP address for no reason 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.  And when email begins
to be this walled off, it ceases to be useful.

I'm not so much after the legality of blocking an IP.  It's more the lack
of remediation or timely remediation.  And AT is a perfect example of
this.  They advertise abuse_...@abuse-att.net as the address to write with
inquiries, but they never check this email address or never respond.  Why
even include it in the rejection message?  The message might as well say:

553 5.3.0 alph749 DNSBL:RBL 521< 23.239.97.150 >_is_blocked. Neener,
Neener, Neener!

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

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

[Scott Mutter via mailop]

On Sun, Jul 7, 2024 at 7:54 AM Alessandro Vesely via mailop <
mailop@mailop.org> wrote:

> It seems to me that large operators don't care a tinker's cuss about
> blocking
> small operators.  If I'm unable to send to Outlook users, it is my fault
> by
> definition, certainly not Outlook's.
>
>

In my opinion this is where the industry could use some oversight.  As you
say there is nothing to stop a large operator from blocking a small
operator simply because they can.  And then from an end-user's point of
view, it's obviously because of an issue with the small operator because
the large operator certainly can't be wrong.  (I refer to these operators
as "too big to fail", much like the banking systems).

I understand a mail server administrator being reluctant to disclose why a
particular IP or email was blocked.  But if there was a trusted third party
oversight involved where the large operator had to disclose why a small
operator was being blocked, that might stop some of this.  The oversight
could determine whether the justification for blocking another mail server
was valid and explain this to the small operator.

Of course, any time you add oversight you always get corruption - so I'm
speaking merely in a vacuum.

Outside of that, a trusted third party could publish a routinely updated
list scoring how difficult or easy it is to get through to a real mail
server administrators for a lot of these too big to fail email service
providers - of which AT would seem to be rated fairly low right now - in
which these small operators could point to when their customers are
complaining about being blocked by one of these large providers and see the
difficulties with which they are to work with.

There comes a point where dirty laundry has to be aired out publicly.
While my specific beef right now is with AT, they're not the old
culprit.  But the fact that their rejection message says "For assistance
forward this error to abuse_...@abuse-att.net" when it's very clear that
abuse_...@abuse-att.net is rarely if ever checked or managed, that's
something the public needs to be aware of.  If AT is going to block IPs -
for no apparent reason, and provide no means of having the issue addressed,
then the public needs to know that if you intend to write to an @att.net
email address it very well may never get delivered.  If you're an @att.net
email account user, maybe you need to think twice before using that email
account in any official capacity.


> Some restrict the audience of possible complainants to the first RIR's
> delegates.  That way a small operator can try to convince its ISP to
> either
> deal with such questions, or do a RIR registration in its name, neither of
> which is an available option to small customers.
>
>

This is also true.  And this relates to my question earlier:  Are we all on
this mailing list to learn?

I get where certain mail server administrators only want to discuss issues
with the direct owner of an IP address.  But I can tell you, from a small
operator's perspective, that's not how a lot of this works any more.  Maybe
it worked that way at one point in the past, but the times have changed
now.  The industry that I work in - the shared hosting industry - where we
get our servers from, and their related IP addresses have no involvement at
all with the management of that server or its mail server operation.  Now
it may be that the administrator that is supposed to be managing that
server has no clue what they are doing or how to manage abuse - I'm not
going to say that that doesn't happen.  But for me, and I suspect several
other small operators, I like to think that we manage the system fairly
well and have a lot of monitors in place to detect outbound spamming or
abuse.  Is there room for improvement?  There always is.  But I think we
keep it down to a minimum the best we can.  But we're the ones that manage
what goes out from these servers.  The owner of the specific IP doesn't
necessarily have the same sense of urgency when an IP block is made.

All of our servers have FCrDNS.  And any time I send an inquiry related to
one of our IP addresses being blocked, I always send out that mail from
postmaster@<> so that replying to that message will show
ownership of the reverse DNS of that blocked IP address.  This would serve
to prove that I can make configuration changes for the operation of the
mail server sending out mail from that IP address.

While I respect that this may not necessarily illustrate that you should
always go a level or two under the owner of an IP address (the first RIR
delegates) I do hope that it illustrates that being a level or two under
the RIR for an IP doesn't necessarily mean that they carry no weight.  If
you receive spam or abuse from an IP address, by all means contact the IP
address owner/first delegate under RIR - I'm not against that.  But if
someone inquires about a block and they are not the IP address owner or
first RIR delegate, it may not be right to just 

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

[Scott Mutter via mailop]

On Mon, Jul 8, 2024 at 10:54 AM Marcel Becker via mailop 
wrote:

>
> On Sat, Jul 6, 2024 at 9:27 AM Scott Mutter via mailop 
> wrote:
>
> We're all on this mailing list to learn (aren't we?).  Maybe take some of
>> the input you see from the messages on this mailing list and work to
>> improve the systems you offer.
>>
>
> Just in case that "you" is referring to me: I am also not ATT
>

Yes, just to be clear, I'm sending all of these replies to the list so any
use of "you", "them", "us" or any other pronoun is meant in the general
context.  I am not specifically pointing a finger at any one person
specifically.  While this particular topic is aimed more specifically at
AT, some of the themes within this discussion apply to other mail systems.

This particular reply might be better read as:


*We're all on this mailing list to learn (aren't we?).  Maybe take some of
the input you (all the various mail server administrators on this list) see
from the messages on this mailing list and work to improve the systems you
(all the various mail server administrators on this list) offer.*
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Scott Mutter via mailop]

On Sat, Jul 6, 2024 at 10:26 AM Marcel Becker via mailop 
wrote:

>
> ATT runs their own inbound servers. Lili is not ATT. Please always use
> official support channels first.
>
> That's kind of the issue.

Nobody responds when you write abuse_...@abuse-att.net

Why is that address included in the rejection message if nobody is going to
respond to inquiries sent to that email address?

And I've heard the same bull over and over again that the email address
likely gets inundated with messages.  If that's the case, then figure out a
better way to handle inquiries so that you can separate the legitimate
inquiries from the not-so legitimate.  I like the idea of directing users
to a web page where you enter the IP address that is being blocked and a
challenge email is sent to postmaster@
to show that the person submitting the concern can speak for the IP
address's usage.

Or better yet, if you're going to automatically reject new/cold IPs then
design a way to announce to AT that these new/cold IPs will soon start
sending out mail so that they are not automatically rejected.

We're all on this mailing list to learn (aren't we?).  Maybe take some of
the input you see from the messages on this mailing list and work to
improve the systems you offer.

If we're all tired of seeing "Anyone from BLANK able to help with the IP
BLANK being blocked?"  Then perhaps this is a nod to BLANK that they need
to do better at handling these inquiries or that their means of blocking
IPs is too liberal.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] AT Block

[Scott Mutter via mailop]

Anyone from AT on the list that can assist with the blacklisting of the
IPs:

23.239.97.150
5.101.141.35

Message is

553 5.3.0 alph749 DNSBL:RBL 521< 23.239.97.150 >_is_blocked.For assistance
forward this error to abuse_...@abuse-att.net

As is the usual case, I've gotten no response from an inquiry to
abuse_...@abuse-att.net.  I sent one to abuse_...@abuse-att.net for
23.239.97.150 on July 2nd and no response.  To be fair, I wrote
abuse_...@abuse-att.net about 5.101.141.35 just yesterday (July 4th) so it
really hasn't been 24 hours yet, but past experience has taught me that I
rarely get a response from an inquiries sent to abuse_...@abuse-att.net.

I suspect that this is being blocked because these are new IPs that AT
has never received mail from, so they block them by default.  Is there an
official way to inform AT before trying to send mail from new IPs that
new IPs will be sending mail?  As far as I know AT is the only service
that outright blocks messages from new and unseen IP addresses by default.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloudmark blocklist

[Scott Mutter via mailop]

On Fri, Jun 28, 2024 at 9:24 AM James Hoddinott via mailop <
mailop@mailop.org> wrote:

> Your main issue is that Transip sure do like to let spammers make use of
> many IPs within the /24 that you're in, we'll just need to flag yours as
> separate to prevent this from reoccurring.
>
>
Wouldn't you expect to see 37.97.176.137 listed in several public RBLs and
have a low sender score if this were the case?

If Cloudmark (or any other anti-spam system) is just blocking the whole /17
or ASN - wouldn't it be just a simple fix to look specifically for
37.97.176.137
and see how much spam 37.97.176.137 has sent?  Or when the last time
37.97.176.137
sent spam or attempted to send out any mail?  And exclude 37.97.176.137
from this block (I don't like the term whitelist here, but if you want to
use whitelist you can use it here) so that mail from 37.97.176.137 can go
through when this specific issue is raised?

This is what kind of creates mistrust with all of these too-big-to-fail
email and anti-spam providers.  They block an IP but don't provide any
information for remediation and take days or weeks to get an issue cleared
up.  There's seemingly little evidence to show that blocking the IP is
validated.

Where would one go to learn of this situation prior to sending an email to
a random email service provider that utilizes Cloudmark (or insert whatever
anti-spam system) so that the situation could be handled proactively and
timely?

There needs to be something publicly available that would point to IP
addresses - such as 37.97.176.137 - being red flagged or to suggest that
there may be issues sending from these IPs.  But instead the system teeters
on providers being able to block IPs simply because they can.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Yahoo/AOL Blocking

[Scott Mutter via mailop]

On Tue, Jun 25, 2024 at 12:31 AM Marcel Becker via mailop 
wrote:

> I assume you have already reached out to the official Yahoo postmaster
> support team via the link conveniently provided in the SMTP response?
>
>
No response on that ticket in over 24 hours.  And the IP address is still
blocked.

Frustrating because Yahoo is the only one blocking this IP address.  The IP
address is not on any other public RBL.  The IP address has a Senderscore
of 98.  I'm just being held hostage by Yahoo.

If the IP address was blocked because of historical usage - before we came
into use of the IP address - I would ask, when was the last time the IP
address sent spam?  If it was 3 days ago, that's one thing.  If it was 3
years ago, that's another.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Outlook JMRP IP Feedback not available

[Scott Mutter via mailop]

On Wed, Jun 26, 2024 at 8:15 PM Al Iverson  wrote:

> Try jumping directly to the appropriate "view data" page in SNDS for this
> IP.
> How? Use my little jumper widget here:
> https://www.wombatmail.com/jump.cgi?d=
> Plug in the IP, and it will convert the IP to the right format for the
> SNDS URL.
> That'll help you bypass the browse/select screen.
> Of course, you'll get access denied if you don't actually have access for
> the IP.
> Then you'll know it's not a data issue, it's an access issue.
>
> Cheers,
> Al
>

When I visit the SNDS page using this, I get:

Error: no data for the specified IP

Not an access denied error.  I guess Outlook has to receive mail from the
IP before it can be registered with JMRP?  I guess being proactive doesn't
really mean a lot.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Outlook JMRP IP Feedback not available

[Scott Mutter via mailop]

What would cause an IP address to not show as being available for Outlook's
JMRP?

Going to

https://postmaster.live.com/snds

and using the link for Access Control, the IP in question is shown as being
authorized to view data about.

But clicking on Junk Mail Reporting Program and then clicking Manage, the
IP address is nowhere to be found.

Usually when adding a new IP address, I have to request access for the IP
address and verify that access by clicking the link in the email they
send.  I've done that.  Then when I visit the Junk Mail Reporting Program
link and click Manage, the IP address is listed under the heading IPs
Sending Feedback and directly under IP Addresses.  I check the box next to
the IP address and Save Settings.

But the IP address is not listed under the IP Addresses heading.

I ask because the whole Microsoft/Outlook Postmaster Tools/SNDS/JMRP system
has been a bit wonky of late.  I'm wondering if there is a system issue
somewhere along the lines that's not making the IP address available for
the JMRP.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Yahoo/AOL Blocking

[Scott Mutter via mailop]

Anybody from Yahoo/AOL able to assist with what's causing the IP address -
67.222.148.107 - to be blocked?

All messages from 67.222.148.107 will be permanently deferred; Retrying
will NOT succeed. See https://postmaster.yahooinc.com/error-codes

Messages have DKIM and DMARC

IP is not listed in Spamhaus (or any other RBL)

Does not seem to be message specific, seems to be IP related.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Cloudmark Blocklist

[Scott Mutter via mailop]

Anyone from Cloudmark able to assist with why the IP address:

67.222.148.107

is listed in their blacklist?

I filled out the form

https://csi.cloudmark.com/en/reset

two days ago.  I got the Confirm CSI IP Address Statistics Reset Request
email and responded to it.  But the IP still appears to be listed.  I do
not know why.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AT Blocklist

[Scott Mutter via mailop]

On Tue, Jun 18, 2024 at 8:31 PM Jeff Peng via mailop 
wrote:

> Mike is right.
>
>   mx1.amscomputer.com has an A RR 107.181.229.51 which points back its
> PTR to zephyr.wznoc.com.
>
> the two domains are not matched, hence messages sent from this server
> will be rejected by postfix's such configuration:
>
> smtpd_sender_restrictions = reject_unknown_client_hostname
>
> I believe many postmasters (including me) are using this setup in their
> postfix.
>
>
Not sure why this has shifted focus to amscomputer.com.

But the MX record for tls-mail.com points to mail.tls-mail.com.
mail.tls-mail.com resolves to 20.120.225.36.  20.120.225.36 reverses to
tls-mail.westus2.cloudapp.azure.com.

I'd very much like to learn why it's wrong for me, but right for you.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AT Blocklist

[Scott Mutter via mailop]

On Tue, Jun 18, 2024 at 6:18 PM Michael Peddemors via mailop <
mailop@mailop.org> wrote:

> https://wznoc.com/
>
> With a obscure page like that, you are asking for trouble..
> Just like the pages many of the bullet proof hosters throw up..
>
> Why not use amscomputer.com in the PTR records, if these are your servers?
>

I work in the shared web hosting industry, which may be foreign to a lot of
people on this list.

With shared hosting, 1 physical server and 1 IP address hosts 100s of other
websites and email accounts.  And some of those accounts are resold
accounts that don't need to be aware of the amscomputer.com brand.  That's
why we use the generic wznoc.com domain.

I can assure you that we're not the only ones that operate this way.  Take
a stroll down the shared hosting industry and you'll find that this is the
way it operates.  I understand that for the majority of people that are on
this Mailops list, they still tend to gravitate towards "one IP address
means one domain means one email server."  That's not how shared hosting
works.  The days of one IP address being tied to one domain name being tied
to one physical or pseudo-physical server are way in the past.

I also would very much like to understand how what a domain's website shows
has any bearing at all towards the reputation of a mail sending IP.  I'll
pose the question to Mailops... do you build your reputation list by
visiting the website of the hostname of the reverse DNS of a mailing
sending IP and gauge its well-being on the look and feel of that website?

Might be a fun exercise, take a look at some of the domains people are
writing from on this mailing list.  Do an IP address lookup of those domain
names.  Then do a reverse DNS lookup of those IP addresses - do they always
return the same domain name the individual is writing from?  What happens
if you add an http:// before those IP addresses and try to visit the
website of the IP address - does it always show the website for the domain
that the individual is writing from?

My experience has shown that almost ALL of the blacklisting, blockings, and
outright rejection of emails has to do solely with the IP address.
Obviously you have to have proper FCrDNS - if you don't have that then that
would be grounds for email rejection.  Proper SPF, DKIM, and DMARC for the
sending domains are also needed.  But none of that means a hill of beans if
one of the big email service providers want to block or blacklist your
sending IP address.

One of the things I absolutely hate is the fact that none of the major
email service providers (AT in this case, Outlook, Yahoo, Gmail) provide
no way of checking to see if an IP address is on their blacklist.  You only
find out that the IP is on their blacklist when a customer tries to send an
email to an email address at one of these providers.  The first thing I do
with any new server or IP address is check it for blacklists at
https://multirbl.valli.org - now these IPs may be listed on a couple of
blacklists - rbl.rbldns.ru and SPFBL.net RBL - but every IP in existence is
on these blacklists.  Nothing stands out to me from the reports from
multirbl.valli.org that indicates widespread problems.

If these IPs were on a bunch of blacklists as reported at multirbl.valli.org
then I wouldn't be so upset with the IPs being listed at AT (or Microsoft
or Yahoo whenever those cases may be).  But when an IP address is seemingly
only listed at one email service provider, that provides no way to check
this - AND THEN proceeds to include an email address for assistance that
never gets checked.  Yea.. I get upset.  Every single person on this
mailing list would get upset if they were in those same shoes.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] AT Blocklist

[Scott Mutter via mailop]

What's going on with AT?

They're blocking our mail servers left and right (IPs aren't on any other
blacklist mind you) and not hearing a peep from abuse_...@abuse-att.net.

What's the point of having your blocked message state to send an email to
abuse_...@abuse-att.net if nobody is going to monitor
abuse_...@abuse-att.net?

IPs in question are:
173.209.54.179
67.222.148.107
173.225.104.91

All have the same error message

553 5.3.0 flph832 DNSBL:RBL 521< 173.209.54.179 >_is_blocked.For assistance
forward this error to abuse_...@abuse-att.net
553 5.3.0 flpd591 DNSBL:RBL 521< 67.222.148.107 >_is_blocked.For assistance
forward this error to abuse_...@abuse-att.net
553 5.3.0 alph767 DNSBL:RBL 521< 173.225.104.91 >_is_blocked.For assistance
forward this error to abuse_...@abuse-att.net

Emails were sent (to abuse_...@abuse-att.net) on June 14th and June 17th -
I've not heard so much as a confirmation that they got those messages.

This isn't the first time I've had issues with AT's blacklist.  It's just
frustrating, if you're going to block IPs for no apparent reason, at least
have someone check the email address you give for assistance or find some
other way to provide assistance.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

I don't know if it's completely broken... but it's definitely very sick and
not well.

Keep hitting refresh, it will eventually load (at least it does for me).
But I believe this is indicative of some problems on the backend of this
website and maybe of the entire Microsoft postmaster/SNDS/JMRPP system.
It's been quite literally months since I've received anything from
Microsoft's JMRPP.

When problems like this start to show up I start to wonder if the project
has been abandoned and what its usefulness is.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

Yea, I got all of mine this morning when I checked.

I guess they found whatever was causing the issue and fixed it.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

Yea, the authorization emails aren't coming through.  I don't know if they
aren't being sent or if they're being stopped some where else.  But it's
been 10 hours and I still haven't received the authorization verification
email.

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

Re: [mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

I'm still not getting the authorization emails.  But maybe that's just me.
I seem to recall that these emails aren't instant and sometimes take
several hours to come in.

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

[mailop] Microsoft SNDS website not working

[Scott Mutter via mailop]

Trying to add an IP address to our SNDS accounts at:

https://sendersupport.olc.protection.outlook.com/snds/index.aspx

Is resulting in a lot of failed page loads, a lot of having to refresh,
authorization emails seemingly not being sent.

Anyone else having issues with Microsoft's SNDS site?  Is this a known
issue?

Anyone from Microsoft want to investigate these issues?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/iCloud message blocking

[Scott Mutter via mailop]

On Wed, Jun 5, 2024 at 10:43 PM Suresh Ramasubramanian 
wrote:

> What address did you send it from? We don’t seem to see any email from
> your address so can you please resend it.
>
>
> --srs
>

postmas...@olympic.wznoc.com

The apple.com mail server doesn't return any traceable message id upon
message acceptance, but my logs show the message being accepted with a  250
2.5.0 Ok response.

First message:
2024-06-03 14:03:49.293 [1314] 1sECyA-LB-0l => icloudad...@apple.com F=<
postmas...@olympic.wznoc.com> P=
R=dkim_lookuphost T=dkim_remote_smtp S=2669 H=mx-in.g.apple.com
[17.32.222.242]:25 I=[205.251.153.98]:48242
X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes
DN="/C=US/ST=California/O=Apple Inc./CN=mx-in.g.apple.com" L C="250 2.5.0
Ok" QT=2.995s DT=2.813s

Second message:
2024-06-05 09:34:33.460 [37726] 1sErif-0009oT-2Q => icloudad...@apple.com
F= P=
R=dkim_lookuphost T=dkim_remote_smtp S=2587 H=mx-in.g.apple.com
[17.32.222.242]:25 I=[205.251.153.98]:60066
X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes
DN="/C=US/ST=California/O=Apple Inc./CN=mx-in.g.apple.com" L C="250 2.5.0
Ok" QT=3.655s DT=3.494s
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/iCloud message blocking

[Scott Mutter via mailop]

Day 3 - still no response from icloudad...@apple.com.

Guessing there's nobody from Apple or iCloud is on this list.

And nobody at Apple/iCloud really cares.


favicon.ico
Description: Binary data
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/iCloud message blocking

[Scott Mutter via mailop]

On Mon, Jun 3, 2024 at 12:24 PM Faisal Misle  wrote:

> Have you tried contacting them as per their postmaster page?
>
> Postmaster information for iCloud Mail - Apple Support
> 
> support.apple.com 
> [image: favicon.ico] 
> 
>
>
> Best,
> Faisal
>

Sent an email to icloudad...@apple.com.

I've gotten no response.


favicon.ico
Description: Binary data
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Apple/iCloud message blocking

[Scott Mutter via mailop]

Anyone from Apple/iCloud able to assist with why certain messages from one
of our servers - 67.215.1.235 - to certain @icloud.com email addresses are
bouncing back with:

554 5.7.1 [CS01] Message rejected due to local policy. Please visit
https://support.apple.com/en-us/HT204137

Bounce back messages?

Can't find a rhyme or reason.

Some messages to @icloud.com email addresses are going out.  Some are not.

The same message that generates the above message when sent to an @
icloud.com email address is sent out successfully when the message is sent
to icloudad...@apple.com - although I'm not sure if @apple.com and @
icloud.com email servers use the same infrastructure.

The sending domain has SPF, DKIM, and DMARC and passes all of the tests at
https://www.learndmarc.com

I am not aware of 67.215.1.235 being listed on any reputable RBLs (I do see
it listed in Ascams but I'm not sure how legitimate that RBL is and it's
not listed in any others)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google Postmaster Tools

[Scott Mutter via mailop]

It's basically worthless unless you are a big box sender.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] RSA-SHA1 DKIM signatures still in use?

[Scott Mutter via mailop]

How is everyone handling senders that sign their emails with RSA-SHA1 DKIM
keys?

I'm a bit surprised to see eBay and Match.com sending out messages using
SHA-1.

I'm seeing a lot of signatures coming in that use SHA-1 but most of the
domains are questionable at best.  But eBay and Match.com caught my eye as
being larger companies that I would expect to know better.

To be clear, eBay is sending out some messages with SHA-256 hash, but they
are also sending out some with a SHA-1 hash.  It appears to be the dkim1k
selector that is SHA-1.

The Match.com (d=connect.match.com) is using the 102022s2048 selector with
SHA-1.

Just wondering what everyone else is doing with these?  I thought SHA-1 was
deprecated a long time ago.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Scott Mutter via mailop]

On Fri, Feb 9, 2024 at 9:56 AM Gellner, Oliver via mailop 
wrote:

> Whether an email passes SPF or DKIM is no indicator of whether its spam.
> It just allows you to tie messages to the reputation of a domain, similar
> as you rate messages based on the IP address they are coming from.
> While I'm no advocate on external email forwarding, SPF does not perform a
> good job on identifying emails regardless of forwarding. Most companies
> send emails from shared IP addresses (Office 365, GSuite, Sendgrid, Amazon
> SES, ...), so their SPF records are all, well... identical, which is not
> really useful to tell them apart. This opens a window for various attacks,
> see for example the recent SMTP smuggling attack. A better approach would
> be to get rid of SPF and base DMARC solely on DKIM.
>

Well, this is why I distinguish a properly set SPF record.

A sender has to know EXACTLY what IPs are going to be sending out
legitimate emails from their domain name.  Not a "maybe these IPs" or
"sometimes this IP and sometimes this other IP" it has to be an EXACT
list.  And if the sender doesn't know what the EXACT list is... then what
else are they forgetting?

But external forwarders is always going to break this.

PayPal can list EXACTLY all of the IPs that they will send out messages
from.  And if you're not using an external email forwarders to receive your
email, then you can be sure that any email coming from the paypal.com
domain name that is being sent from an IP published in that SPF list,
actually came from PayPal (now whether or not if the PayPal servers have
been hacked or compromised is another story - insert whatever
domain/organization you want in place of PayPal, the lesser the
organization the more likely that security is not a paramount concern).
But the second you forward mail from PayPal to an external email address,
the precise SPF record is rendered useless.

This is why organizations never bothered to set EXACT SPF records, because
what was the point?  External forwarders were too prevalent to  make it
worthwhile.

This is why we can't have nice things.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Scott Mutter via mailop]

On Thu, Feb 8, 2024 at 12:20 PM Randolf Richardson, Postmaster via mailop <
mailop@mailop.org> wrote:

> > Am 08.02.2024 schrieb Cyril - ImprovMX via mailop :
> >
> > > But forwarding an email from a domain that have DMARC enabled (with a
> > > policy different than "none") could still work if the sender signed
> > > their email with DKIM. Isn't it correct?
> >
> > That is true. But not all domains have DKIM.
>
> Spammers forging eMail accounts is the primary reason SPF and DKIM
> are so prevalent these days.
>
> I believe the day will come when it will be pointless to send
> eMail
> from a domain that doesn't have a properly-configured SPF record and
> all of its outbound mail signed with DKIM.
>
> I think the issue with SPF and DKIM is that it's becoming trivial for ALL
email to have SPF and DKIM that pass muster.  At which point, you're right
back where you started.  Lots of spam getting into the Inbox because they
all pass SPF and DKIM.

This is part of the issue I have with all of these band-aid solutions when
it comes to "fixing" the spam problem with email.  You're going to continue
to have these issues with email until people realize that they are going to
have to let go of some of these grandfathered standards - like external
email forwarding.  If external email forwarding was not a thing, then a
properly constructed SPF record is going to do a pretty good job (a
complete job?) of identifying messages that are forged (phishing) and those
that are legitimate.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Spamfolder mini rant (Was: Contact Google Postmaster)

[Scott Mutter via mailop]

On Mon, Jan 29, 2024 at 10:01 AM Todd Herr via mailop 
wrote:

> Users can only click "This is spam" on messages that end up in their
> inbox. If all of your traffic went to the spam folder, perhaps because it
> was unfortunately remarkably similar to previous traffic that was deemed
> spam, you won't get any complaints through an FBL, because the "This is
> spam" button isn't available when viewing the Spam folder.
>
> There have been topics on this list as to what actually qualifies an FBL
trigger.  Is it when a user flags the message as spam?  Or is it when the
receiving server's MTA delivers the message into the recipient's spambox?
As far as I know, there's never been a consensus on that.  Some providers
may do it one way, other providers may do it another.

But from my perspective (as an administrator of the mail server that sent
out the message) it doesn't really matter to me.  With one option, the
recipient controls their fate (they can click the "this is spam" button or
they cannot) with the other option they're at the mercy of how their email
service provider handles messages.  In either case, it's something the
receiving individual needs to remedy, if they wish to continue to receive
messages.


> They have a Feedback Loop, but it's not a traditional one. It's part of
> their Postmaster Tools -
> https://support.google.com/a/answer/6254652?sjid=15660904710347572920-NA
>

The Google Postmaster Tools are useless to me.  We don't send out enough
volume from any of our servers to get noticed at Google Postmaster Tools.
The server that was originally mentioned in this topic had sent out 68
messages in the month of January when it got blocked.  There's nothing on
the Google Postmaster Tools for this server.  All messages sent out from
our servers are signed with a server-specific DKIM key (and perhaps others)
so it should show up at Google Postmaster Tools, but the volume is not
there for it get recognized by Google.  So that makes Google Postmaster
Tools useless for me.

People can claim all they want that there is a reason why Google Postmaster
Tools requires a minimum number of messages to get recognized, but that
same minimum number of messages doesn't stop them from blacklisting or
sending messages to spamboxes from that server.

Besides that, it's a whole lot easier to have a traditionally FBL that
emails us about FBL triggered messages - I can automate that and be
notified when a message comes in.  I can't do that with Google, I have to
explicitly log into their tool and look for information.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Spamfolder mini rant (Was: Contact Google Postmaster)

[Scott Mutter via mailop]

> It would also give feedback to spammers allowing them to fine-tune their
> messages to avoid getting flagged.

What about feedback loops?  Don't those also fall into the category of
aiding the spammer?  But they are also a tool for legitimate mail server
administrators to combat spam on their network.

I like feedback loops.  The information I get back from these are immensely
helpful.  The only bone I have to pick is that too-big-to-fail email
service providers still tend to block our servers after we have received
ZERO messages back from the feedback loop.  Hard for us to know that their
users are signaling that messages from our servers are spam if we don't get
any feedback.

My approach to feedback loops is that if I receive a message from a
provider's feedback loop, then that recipient email address is immediately
blocked from receiving any mail from our server.  This may be harsh, but it
is what it is.  Whether the recipient explicitly tagged the message as spam
that triggered the FBL or if the recipient's mail server algorithm
determined the message was spam and triggered the FBL - I really don't
care.  If the recipient wants to dispute this, then they need to either
explain why they tagged the message as spam or they need to get an
explanation from their mail server's algorithm developer as to why the
message was determined to be spam - it's pretty simple to me.

I do agree that a lot of the messages I get back from the feedback loops -
they're not obvious spam.  I don't know if the recipient signed up to
receive mail from a user on our server and then decided they no longer
wanted to receive the message so they flagged it as spam.  Or if the
algorithm just decided that after 5 years of receiving similar message THIS
particular message is spam.  Either way, I don't care, that recipient gets
blocked from receiving any mail from our server.  I don't have the time or
the fortitude to coddle every recipient and every sender with "are you sure
you meant to tag this message as spam?" - they're never going to respond to
such messages, I block them and if that pisses them off... well it pisses
me off every time I have to deal with an overzealous too-big-to-fail email
service provider blocking our servers for no apparent reason.

As far as I know, Google does not have an FBL service, so there's no way to
get this level of information from Google.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)

[Scott Mutter via mailop]

What if the receiving mail server tagged the message in some way in their
final acknowledgement of the message.  For Google. instead of:

250 2.0.0 OK  1706409809
h4-20020ac8584400b10427e71c979dsi9837397zyh.449 - gsmtp

If the message is redirected to the user's spambox, the message could be:

250 2.0.0 OK  1706409809
h4-20020ac8584400b10427e71c979dsi9837397zyh.449-spam - gsmtp

Or provide some number attached to the ID that identifies how much
spamminess the receiving mail server thinks the message is.

This would at least give a tool for the sending server to know if the
messages being sent out of their server are being flagged as spam.

I get that it's a thin line between offering this information and that
information being abused by spammers to circumvent the receiving
server's anti-spam measures.  But there's also no judicial system or
oversight in making these determinations.  The receiving server gets to be
judge, jury, and executioner when it comes to making these determinations.
And because these email service providers are "too-big-to-fail" it's never
their fault for being overzealous with their blocking or weighing scale.
They can block whoever they want, whenever they want, with no explanation
at all.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact Google Postmaster

[Scott Mutter via mailop]

I've had domains listed in Google Postmaster Tools since 2016.  Never
gotten one lick of any information from any of those except for "No data to
display at this time. Please come back later. Postmaster Tools requires
that your domain satisfies certain conditions before data is visible for
this chart."

I eventually stopped adding domains because it didn't do me any good.

The 173.225.104.91 server has sent 68 emails to gmail.com email addresses
thus far in January 2024.  As far as I know, this block just happened
today.  Today was the first time it was brought to my attention that
messages from this server are going into the spam folder.

Again, how am I supposed to know that Google is treating this IP's
reputation poorly?

How am I supposed to remedy a low reputation?


I set up another domain on the same 173.225.104.91 server, SPF, DKIM, and
DMARC all set up (and verified with https://www.learndmarc.com).  Sent a
message to an @gmail.com address through this account, and it went to the
spam folder.

Set up the same domain on another server - 205.209.102.251 - which,
coincidentally is also an Interserver IP.  Again, verified that SPF, DKIM,
and DMARC were all set up with https://www.learndmarc.com.  I sent the same
test message to the same @gmail.com address.  Message came through in the
INBOX without incident.

What conclusions would everybody else draw?


It's frustrating because none of the too big to fail email service
providers have any way to test a sending IP or sending domain's reputation
with their service.  They block them or weigh them heavily without any
method of remediation.

It would be nice if I could check the reputation of my outbound IPs daily
and be proactive in remedying any issues with these major email service
providers, rather than have to be told by my clients that something is
amiss.  And then battle through a 2 week waiting period for the provider to
reply back or hope that someone from the provider is on MailOps and can
provide any insight.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Contact Google Postmaster

[Scott Mutter via mailop]

>> I'm not seeing where 173.225.104.91 is on any public blacklist.
> That is also not relevant. Your reputation and what receivers think about
your email is relevant.

Maybe not, but please pray tell how else I'm suppose to know the reputation
of my server's IP address?  Does Google have a public blacklist checker
that I can check?  Does Yahoo?  Does Microsoft?  I get that there's a
reason they keep these private.  But if I'm not seeing anything on a public
blacklist then what am I suppose to think?

If the IP was covered up with listing on public blacklists, then yea I'd
agree there's likely an issue on the server and a reason for the listing,
and probably a reason why Google is sending the messages into the spam box.

But as it stands now, it's only when our users notify us that their
messages are being sent to their Gmail spambox do I realize there's an
issue.  There's no rejection or anything from Google's acceptance of the
message to indicate that there is any problem.

You have to try to see this from my perspective.  How am I suppose to know
that Google is treating messages from this IP poorly?

The Google Postmaster tool is a joke for me.  Apparently you have to have
10's of millions of messages coming from the server for Google Postmaster
to report anything.  I've never had one ounce of anything helpful from
Google's Postmaster tools, the only thing I ever get is "No data to display
at this time. Please come back later. Postmaster Tools requires that your
domain satisfies certain conditions before data is visible for this chart"
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Contact Google Postmaster

[Scott Mutter via mailop]

It seems messages being sent from 173.225.104.91 are being delivered into
Gmail user's spam boxes.

These messages are DKIM signed, pass SPF and DMARC.

I'm not seeing where 173.225.104.91 is on any public blacklist.

Anyone from Google able to shed any light on this?

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

Re: [mailop] DMARC processing

[Scott Mutter via mailop]

If DMARC reports could be sent in JSON format, they would be more easily
parseable.

At least, that's my opinion.

On Tue, Dec 19, 2023 at 2:47 AM Eduardo Diaz Comellas via mailop <
mailop@mailop.org> wrote:

> Hi,
>
> I'm starting to deploy DMARC records in all our managed domains, but we
> don't have any specific tool to parse and extract meaningful information
> from the reports.
>
> Do you have any recomendations?
>
> Best regards
>
> --
> Eduardo Díaz Comellas
> Ultreia Comunicaciones, S.L.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] AT Blacklist - 205.251.153.98

[Scott Mutter via mailop]

Anybody from AT able to provide any insight as to why 205.251.153.98 is
being blacklisted?

Sent an email to abuse_...@abuse-att.net back on October 26, never got a
response.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Hotmail: why S1350 blocking every 3 months?

[Scott Mutter via mailop]

I think sometimes these "too big to fail" mail service providers block IPs
just because they can.  Who are your users going to believe?  It has to be
something you the small time email service provider is doing wrong, it
can't possibly be good ol "insert big brand here".

I certainly understand that there's a fine line between disclosing why an
IP address is being blocked and keeping that information private, because
nefarious users (spammers) can use this information to circumvent the next
barrage of spam.

But you also have to see this from the perspective of legitimate email
service providers.  How are we supposed to prevent our IPs from being
blacklisted if we have no information on what's causing the blacklist in
the first place?

And then you have situations like this where very few emails have been
sent, but the IP gets blacklisted anyway.  Without any oversight - without
something that's impartially determining whether or not the blacklisting
was warranted - we're left to wonder if you're just blocking IPs because
you can.

On Sun, Oct 29, 2023 at 2:47 PM Simon Arlott via mailop 
wrote:

> This happens every 3 months now:
>
> 2023-10-29T19:22:20.569+00:00 1qxBMV-0086ua-AC ** @hotmail.com
> P= R=dnslookup_ipv4 T=remote_smtp
> H=hotmail-com.olc.protection.outlook.com [104.47.58.161]:25
> I=[209.16.157.42]:40134
> X=TLS1.2:ECDHE_SECP384R1__RSA_SHA256__AES_256_GCM:256 CV=yes
> DN="C=US,ST=Washington,L=Redmond,O=Microsoft Corporation,CN=
> mail.protection.outlook.com":
> SMTP error from remote mail server after MAIL FROM:
> SIZE=4773:
> 550 5.7.1 Unfortunately, messages from [209.16.157.42] 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. [
> BN8NAM11FT042.eop-nam11.prod.protection.outlook.com
> 2023-10-29T19:22:20.489Z 08DBD7DEDE23957D]
>
> Every time I go through the mitigation dance and then it just happens
> again 3 months later. They've been doing this for over 2 years now.
>
> Between the last mitigation on 2023-08-16 and now there have been a
> total of 3 emails delivered to Hotmail.
>
> In the same period two other outgoing IPs have sent 9 and 8 emails to
> Hotmail but they have never experienced a single S3150 rejection.
>
> I know from netflow data that there's barely any SMTP traffic to Hotmail
> in the entire network (and only certain IPs are authorised to make SMTP
> connections) so why does Microsoft keep blocking me repeatedly?
>
> (SNDS: "All of the specified IPs have normal status")
>
> --
> Simon Arlott
> ___
> 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] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

Problem still persists.  I've stopped getting any responses from
icloudad...@apple.com.  I guess we're not big enough for Apple to care
about us.  I'll just advise our customers not to use Apple services, since
this is the best customer service that Apple can offer.

On Fri, Sep 22, 2023 at 10:45 PM Scott Mutter 
wrote:

> Nope.  Still the same.
>
> On Fri, Sep 22, 2023 at 9:42 PM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
>> Check again now
>>
>> --srs
>> ------
>> *From:* mailop  on behalf of Scott Mutter via
>> mailop 
>> *Sent:* Saturday, September 23, 2023 1:52:25 AM
>> *To:* mailop@mailop.org 
>> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
>> local policy
>>
>> Got a response from icloudad...@apple.com stating they've made changes.
>> But the issue still persists.
>>
>> We replied back on that message, but I'm not all that convinced that
>> whoever is checking the icloudad...@apple.com address actually knows
>> what they are doing.  Especially since it's taken a lot of arm twisting to
>> get any response at all.
>>
>> On Thu, Sep 21, 2023 at 7:56 PM Suresh Ramasubramanian <
>> ops.li...@gmail.com> wrote:
>>
>> Ok we will check
>>
>>
>> --srs
>> --
>> *From:* mailop  on behalf of Scott Mutter via
>> mailop 
>> *Sent:* Thursday, September 21, 2023 10:23:15 PM
>> *To:* mailop@mailop.org 
>> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
>> local policy
>>
>> Message sent again - today, 2023-09-21 11:51AM CDT.
>>
>> Subject of the message is - 209.236.124.55 IP Blacklisted
>>
>> I sent the message to icloudad...@apple.com and CC'd s...@apple.com
>>
>> On Thu, Sep 21, 2023 at 9:46 AM Suresh Ramasubramanian <
>> ops.li...@gmail.com> wrote:
>>
>> Can you resend your message to postmaster with a recent sample of the
>> logs? Bcc me at s...@apple.com so I can follow up with the team.
>>
>>
>>
>> *From: *mailop  on behalf of Scott Mutter via
>> mailop 
>> *Date: *Thursday, 21 September 2023 at 8:00 PM
>> *To: *mailop@mailop.org 
>> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
>> local policy
>>
>> How long should I have to wait for a response?
>>
>>
>>
>> I haven't heard anything back and icloud is still rejecting the message
>> due to local policy.
>>
>>
>>
>> On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian <
>> ops.li...@gmail.com> wrote:
>>
>> I will have the team check and reply to you
>>
>>
>>
>> *From: *Scott Mutter 
>> *Date: *Tuesday, 19 September 2023 at 6:28 PM
>> *To: *Suresh Ramasubramanian 
>> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
>> local policy
>>
>> I wrote icloudad...@apple.com on August 26, 2023.
>>
>>
>>
>> Message was from postmas...@thoroughbred.wznoc.com
>>
>>
>>
>> Subject of the message was - 209.236.124.55 IP Blacklisted
>>
>>
>>
>> Just tried resending a message from this server, same error message:
>>
>>
>>
>>  554 5.7.1 [HM08] Message rejected due to local policy. Please visit
>> https://support.apple.com/en-us/HT204137
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian <
>> ops.li...@gmail.com> wrote:
>>
>> Hi
>>
>>
>>
>> What address did you email icloudadmin from?
>>
>> I don’t see any current blocks on your IP
>>
>>
>>
>> --srs
>> --
>>
>> *From:* Suresh Ramasubramanian 
>> *Sent:* Tuesday, September 19, 2023 10:33:52 AM
>> *To:* Scott Mutter ; mailop@mailop.org <
>> mailop@mailop.org>
>> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
>> local policy
>>
>>
>>
>> I’ll have someone look at your email and reply if they haven’t yet
>>
>>
>>
>> --srs
>> --
>>
>> *From:* mailop  on behalf of Scott Mutter via
>> mailop 
>> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
>> *To:* mailop@mailop.org 
>> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to
>> local policy
>>
>>
>>
>> Anybody from Apple/iCloud able to provide any insight as to why messages
>> from 209.236.124.55 are being blocked with - Message rejected due to local
>> policy messages?
>>
>>
>>
>> I previously sent a message to icloudad...@apple.com but got no response.
>>
>>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

Nope.  Still the same.

On Fri, Sep 22, 2023 at 9:42 PM Suresh Ramasubramanian 
wrote:

> Check again now
>
> --srs
> --
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Saturday, September 23, 2023 1:52:25 AM
> *To:* mailop@mailop.org 
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> Got a response from icloudad...@apple.com stating they've made changes.
> But the issue still persists.
>
> We replied back on that message, but I'm not all that convinced that
> whoever is checking the icloudad...@apple.com address actually knows what
> they are doing.  Especially since it's taken a lot of arm twisting to get
> any response at all.
>
> On Thu, Sep 21, 2023 at 7:56 PM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Ok we will check
>
>
> --srs
> --
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Thursday, September 21, 2023 10:23:15 PM
> *To:* mailop@mailop.org 
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> Message sent again - today, 2023-09-21 11:51AM CDT.
>
> Subject of the message is - 209.236.124.55 IP Blacklisted
>
> I sent the message to icloudad...@apple.com and CC'd s...@apple.com
>
> On Thu, Sep 21, 2023 at 9:46 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Can you resend your message to postmaster with a recent sample of the
> logs? Bcc me at s...@apple.com so I can follow up with the team.
>
>
>
> *From: *mailop  on behalf of Scott Mutter via
> mailop 
> *Date: *Thursday, 21 September 2023 at 8:00 PM
> *To: *mailop@mailop.org 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> How long should I have to wait for a response?
>
>
>
> I haven't heard anything back and icloud is still rejecting the message
> due to local policy.
>
>
>
> On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> I will have the team check and reply to you
>
>
>
> *From: *Scott Mutter 
> *Date: *Tuesday, 19 September 2023 at 6:28 PM
> *To: *Suresh Ramasubramanian 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> I wrote icloudad...@apple.com on August 26, 2023.
>
>
>
> Message was from postmas...@thoroughbred.wznoc.com
>
>
>
> Subject of the message was - 209.236.124.55 IP Blacklisted
>
>
>
> Just tried resending a message from this server, same error message:
>
>
>
>  554 5.7.1 [HM08] Message rejected due to local policy. Please visit
> https://support.apple.com/en-us/HT204137
>
>
>
>
>
>
>
> On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Hi
>
>
>
> What address did you email icloudadmin from?
>
> I don’t see any current blocks on your IP
>
>
>
> --srs
> --
>
> *From:* Suresh Ramasubramanian 
> *Sent:* Tuesday, September 19, 2023 10:33:52 AM
> *To:* Scott Mutter ; mailop@mailop.org <
> mailop@mailop.org>
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
>
>
> I’ll have someone look at your email and reply if they haven’t yet
>
>
>
> --srs
> --
>
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
>
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
>
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

Got a response from icloudad...@apple.com stating they've made changes.
But the issue still persists.

We replied back on that message, but I'm not all that convinced that
whoever is checking the icloudad...@apple.com address actually knows what
they are doing.  Especially since it's taken a lot of arm twisting to get
any response at all.

On Thu, Sep 21, 2023 at 7:56 PM Suresh Ramasubramanian 
wrote:

> Ok we will check
>
>
> --srs
> --
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Thursday, September 21, 2023 10:23:15 PM
> *To:* mailop@mailop.org 
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> Message sent again - today, 2023-09-21 11:51AM CDT.
>
> Subject of the message is - 209.236.124.55 IP Blacklisted
>
> I sent the message to icloudad...@apple.com and CC'd s...@apple.com
>
> On Thu, Sep 21, 2023 at 9:46 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Can you resend your message to postmaster with a recent sample of the
> logs? Bcc me at s...@apple.com so I can follow up with the team.
>
>
>
> *From: *mailop  on behalf of Scott Mutter via
> mailop 
> *Date: *Thursday, 21 September 2023 at 8:00 PM
> *To: *mailop@mailop.org 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> How long should I have to wait for a response?
>
>
>
> I haven't heard anything back and icloud is still rejecting the message
> due to local policy.
>
>
>
> On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> I will have the team check and reply to you
>
>
>
> *From: *Scott Mutter 
> *Date: *Tuesday, 19 September 2023 at 6:28 PM
> *To: *Suresh Ramasubramanian 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> I wrote icloudad...@apple.com on August 26, 2023.
>
>
>
> Message was from postmas...@thoroughbred.wznoc.com
>
>
>
> Subject of the message was - 209.236.124.55 IP Blacklisted
>
>
>
> Just tried resending a message from this server, same error message:
>
>
>
>  554 5.7.1 [HM08] Message rejected due to local policy. Please visit
> https://support.apple.com/en-us/HT204137
>
>
>
>
>
>
>
> On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Hi
>
>
>
> What address did you email icloudadmin from?
>
> I don’t see any current blocks on your IP
>
>
>
> --srs
> --
>
> *From:* Suresh Ramasubramanian 
> *Sent:* Tuesday, September 19, 2023 10:33:52 AM
> *To:* Scott Mutter ; mailop@mailop.org <
> mailop@mailop.org>
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
>
>
> I’ll have someone look at your email and reply if they haven’t yet
>
>
>
> --srs
> --
>
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
>
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
>
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

Message sent again - today, 2023-09-21 11:51AM CDT.

Subject of the message is - 209.236.124.55 IP Blacklisted

I sent the message to icloudad...@apple.com and CC'd s...@apple.com

On Thu, Sep 21, 2023 at 9:46 AM Suresh Ramasubramanian 
wrote:

> Can you resend your message to postmaster with a recent sample of the
> logs? Bcc me at s...@apple.com so I can follow up with the team.
>
>
>
> *From: *mailop  on behalf of Scott Mutter via
> mailop 
> *Date: *Thursday, 21 September 2023 at 8:00 PM
> *To: *mailop@mailop.org 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> How long should I have to wait for a response?
>
>
>
> I haven't heard anything back and icloud is still rejecting the message
> due to local policy.
>
>
>
> On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> I will have the team check and reply to you
>
>
>
> *From: *Scott Mutter 
> *Date: *Tuesday, 19 September 2023 at 6:28 PM
> *To: *Suresh Ramasubramanian 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> I wrote icloudad...@apple.com on August 26, 2023.
>
>
>
> Message was from postmas...@thoroughbred.wznoc.com
>
>
>
> Subject of the message was - 209.236.124.55 IP Blacklisted
>
>
>
> Just tried resending a message from this server, same error message:
>
>
>
>  554 5.7.1 [HM08] Message rejected due to local policy. Please visit
> https://support.apple.com/en-us/HT204137
>
>
>
>
>
>
>
> On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Hi
>
>
>
> What address did you email icloudadmin from?
>
> I don’t see any current blocks on your IP
>
>
>
> --srs
> --
>
> *From:* Suresh Ramasubramanian 
> *Sent:* Tuesday, September 19, 2023 10:33:52 AM
> *To:* Scott Mutter ; mailop@mailop.org <
> mailop@mailop.org>
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
>
>
> I’ll have someone look at your email and reply if they haven’t yet
>
>
>
> --srs
> --
>
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
>
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
>
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

How long should I have to wait for a response?

I haven't heard anything back and icloud is still rejecting the message due
to local policy.

On Tue, Sep 19, 2023 at 9:07 AM Suresh Ramasubramanian 
wrote:

> I will have the team check and reply to you
>
>
>
> *From: *Scott Mutter 
> *Date: *Tuesday, 19 September 2023 at 6:28 PM
> *To: *Suresh Ramasubramanian 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> I wrote icloudad...@apple.com on August 26, 2023.
>
>
>
> Message was from postmas...@thoroughbred.wznoc.com
>
>
>
> Subject of the message was - 209.236.124.55 IP Blacklisted
>
>
>
> Just tried resending a message from this server, same error message:
>
>
>
>  554 5.7.1 [HM08] Message rejected due to local policy. Please visit
> https://support.apple.com/en-us/HT204137
>
>
>
>
>
>
>
> On Tue, Sep 19, 2023 at 2:08 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> Hi
>
>
>
> What address did you email icloudadmin from?
>
> I don’t see any current blocks on your IP
>
>
>
> --srs
> --
>
> *From:* Suresh Ramasubramanian 
> *Sent:* Tuesday, September 19, 2023 10:33:52 AM
> *To:* Scott Mutter ; mailop@mailop.org <
> mailop@mailop.org>
> *Subject:* Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
>
>
> I’ll have someone look at your email and reply if they haven’t yet
>
>
>
> --srs
> --
>
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
>
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
>
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

I wrote icloudad...@apple.com on August 26, 2023.

Message was from postmas...@thoroughbred.wznoc.com

Subject of the message was - 209.236.124.55 IP Blacklisted

Just tried resending a message from this server, same error message:

 554 5.7.1 [HM08] Message rejected due to local policy. Please visit
https://support.apple.com/en-us/HT204137

On Tue, Sep 19, 2023 at 7:56 AM Suresh Ramasubramanian 
wrote:

> From which address?
>
>
>
> *From: *mailop  on behalf of Scott Mutter via
> mailop 
> *Date: *Tuesday, 19 September 2023 at 6:25 PM
> *To: *mailop@mailop.org 
> *Subject: *Re: [mailop] Apple/icloud blocking - Message rejected due to
> local policy
>
> I wrote icloudad...@apple.com on August 26, 2023
>
>
>
> On Tue, Sep 19, 2023 at 12:03 AM Suresh Ramasubramanian <
> ops.li...@gmail.com> wrote:
>
> I’ll have someone look at your email and reply if they haven’t yet
>
>
>
> --srs
> --
>
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
>
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
>
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

I wrote icloudad...@apple.com on August 26, 2023

On Tue, Sep 19, 2023 at 12:03 AM Suresh Ramasubramanian 
wrote:

> I’ll have someone look at your email and reply if they haven’t yet
>
> --srs
> --
> *From:* mailop  on behalf of Scott Mutter via
> mailop 
> *Sent:* Tuesday, September 19, 2023 9:11:02 AM
> *To:* mailop@mailop.org 
> *Subject:* [mailop] Apple/icloud blocking - Message rejected due to local
> policy
>
> Anybody from Apple/iCloud able to provide any insight as to why messages
> from 209.236.124.55 are being blocked with - Message rejected due to local
> policy messages?
>
> I previously sent a message to icloudad...@apple.com but got no response.
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Apple/icloud blocking - Message rejected due to local policy

[Scott Mutter via mailop]

Anybody from Apple/iCloud able to provide any insight as to why messages
from 209.236.124.55 are being blocked with - Message rejected due to local
policy messages?

I previously sent a message to icloudad...@apple.com but got no response.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google - Messages with multiple addresses in From: header are not accepted.

[Scott Mutter via mailop]

Thanks.

It's actually the mailing script this client is using that is adding the
headers in this way.  I will have to get with the client to resolve this.

That answers that issue.

On Mon, Sep 18, 2023 at 9:53 AM Scott Mutter 
wrote:

> We're seeing an increase of errors from Google's mail servers complaining
> about multiple addresses in the From header.  But these messages do not
> have multiple addresses in the From headers or multiple From headers.
>
> Best I can tell, this seems to be caused by additional spaces in some of
> the headers, I suppose the header immediately following the From header.
>
> I'm not really sure who is at fault here.  Are leading spaces in mail
> headers allowed?
>
> Headers formatted as:
>
> From: Name 
>  MIME-Version: 1.0
>
> Generates this multiple addresses in From header error.
>
> Headers formatted as:
>
> From: Name 
> MIME-Version: 1.0
>
> Does not generate this error and messages are sent through.
>
> (In case the formatting of this message does not portray the issue
> correctly, there is a single space before MIME-Version: 1.0 in the message
> that generates this error)
>
> I'm not sure if a leading space in a message header is proper.  But I
> would also kind of lean towards this being a wrong regex being used by
> Google's mail servers to detect multiple addresses in the From header.
>
> Anybody else seeing this or have any insights?
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Google - Messages with multiple addresses in From: header are not accepted.

[Scott Mutter via mailop]

We're seeing an increase of errors from Google's mail servers complaining
about multiple addresses in the From header.  But these messages do not
have multiple addresses in the From headers or multiple From headers.

Best I can tell, this seems to be caused by additional spaces in some of
the headers, I suppose the header immediately following the From header.

I'm not really sure who is at fault here.  Are leading spaces in mail
headers allowed?

Headers formatted as:

From: Name 
 MIME-Version: 1.0

Generates this multiple addresses in From header error.

Headers formatted as:

From: Name 
MIME-Version: 1.0

Does not generate this error and messages are sent through.

(In case the formatting of this message does not portray the issue
correctly, there is a single space before MIME-Version: 1.0 in the message
that generates this error)

I'm not sure if a leading space in a message header is proper.  But I would
also kind of lean towards this being a wrong regex being used by Google's
mail servers to detect multiple addresses in the From header.

Anybody else seeing this or have any insights?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Scott Mutter via mailop]

Going from the list provided at:

https://www.isipp.com/blog/validity-fbl-charging-how-much-cost/

The only one that I really get any feedback from is Comcast, maybe
Synacor.  And those are few and far between.  What's going to be the
incentive to pay for these ARF reports?

Sure, other people may be in a different boat than I am, and they may get a
lot of reports from those various providers.  But you've got to think that
it's a very small subset of Validity users that get enough feedback
messages from those providers, enough to warrant spending money for the ARF
reports.

Perhaps Validity is just exhausting all methods of trying to make money
before folding up shop.  But I can't see this as being a major money maker
for them.

On Wed, Sep 13, 2023 at 11:40 AM Opti Pub via mailop 
wrote:

> I think that’s the point, mostly all of them used to allow direct setup
> but don’t anymore (when universal fbl became widespread). Seznam is one of
> 20+.
>
> Now that you have to pay for it maybe more vendors will start allowing
> direct setup again? That’s what I’m wondering about.
>
> I guess we will see.
>
> On Wed, Sep 13, 2023 at 11:18 AM Gellner, Oliver via mailop <
> mailop@mailop.org> wrote:
>
>> On 13.09.2023 at 16:06 Scott Mutter via mailop wrote:
>>
>> > I also think one thing that Validity may not be understanding with this
>> move, and may lead to shooting themselves in the foot, the list of email
>> service providers that Validity provides feedback for isn't exactly major
>> players.
>> > We get more feedback from Yahoo and Outlook's FBL system than we do
>> Validity and Validity covers what?  21 different providers?  There's no
>> incentive there for me to pay for access to Validity's ARF feeds.  When
>> Validity stops sending ARF reports, I will simply no longer receive
>> Validity ARF reports - it won't be a major loss.
>>
>> On top of that some of the providers like Seznam also offer feedback
>> loops directly, so you don't need Validity for forwarding the reports.
>>
>> --
>> 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<mailto:dmt...@dm.de> * www.dmTECH.de<http://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
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Scott Mutter via mailop]

I also think one thing that Validity may not be understanding with this
move, and may lead to shooting themselves in the foot, the list of email
service providers that Validity provides feedback for isn't exactly major
players.

We get more feedback from Yahoo and Outlook's FBL system than we do
Validity and Validity covers what?  21 different providers?  There's no
incentive there for me to pay for access to Validity's ARF feeds.  When
Validity stops sending ARF reports, I will simply no longer receive
Validity ARF reports - it won't be a major loss.

On Mon, Sep 11, 2023 at 6:24 AM Support 3Hound via mailop 
wrote:

> Dear list,
> I would like to understand what the community think about the new Validity
> universal feedback loop service that is switching to a paid service
> starting 21 September 2023.
>
> As Validity worked in the the last years to achieve the management of the
> FBL service from all the "main" country-level and international mailbox
> providers (as the "universal" word suggest), I think that this new policy
> is unfair and a very bad news for the mail operators community.
>
> During years the FBL became a kind of "safe feature" for users that prefer
> to click "junk" or "spam" and be sure they will not receive anymore.
>
> The "one click unsubscribe/ List-unsubscribe header" should be the right
> way to do that... true! But this is not the focus, everyone know that FBL
> are -de facto- used like that from users and that they are honored from
> correct sender.
>
> FBL generates also a good data flow for the mailbox provider that may
> filter the "next e-mail" from a sender that don't honor the FBL (or can't
> act realtime the unsubcribe) generating a better service for the end user
> and a way to identify good player and bad ones.
>
> Switching to a paid service bring these metrics to fails; rich spammer may
> easily honor them getting a better reputation than a little correct player.
>
> It also means that it's needed to buy a paid service from a private
> company to follows best practices, something that seems to be unfair.
>
> But... as any collaborating service it's based on other
> peers/nodes/players so my question is: how mail players will act in this
> scenario?
>
> For example, if every mailbox is going to reactivate his own service to
> get back the control of their FBL, it will not have just a short term
> impact...
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Scott Mutter via mailop]

I thought Validity was making the free FBL more like Google's Postmaster
Tools FBL.  Which, I've never gotten one iota of anything relevant in
Google's FBL system.

If I had to venture a guess, I'd say that this is going to be the future of
FBLs.  I think providers want to be able to block certain mail servers
without having to show evidence of abuse and having an FBL system doesn't
really lend themselves to this.  This mailing list itself is flooded with
requests of "Anybody from XXX able to tell me why IP is blocked?" that is
basically a tell-tale sign that the provider is either blocking the mail
server because they want to or not providing enough tools for the sending
operator to investigate the issue on their own.

The idea of FBL is great.  The application of FBL is well below ideal.

If end-users would utilize FBLs as the intended function, to identify spam
- not just mailing list you no longer want to receive.  And if FBL
operators would send all of these complaints back to the sending server
administrator.  And if the sending server administrator would act upon them
properly, then FBLs are a great tool.

But too often we're seeing end users abuse the functionality of reporting
spam.  FBL operators aren't sending every complaint and instead are
requiring a certain threshold to be met and blocking the mail server before
reaching this threshold.  And server administrators are either ignoring the
complaints sent back to them, not signing up for them in the first place,
or are spammers themselves utilizing the reports with bad intentions.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Scott Mutter via mailop]

How an FBL is supposed to be used versus how an FBL is used is always a
topic for discussion that can be applied to anything.

How many of us expect email to be delivered instantly?  But where is it
defined that email has to be delivered the second the sender clicks that
send button?  But we all get up in arms when that email doesn't arrive in 2
minutes.

My take on users abusing the "this is spam" button is, if they click the
button then they don't want to receive mail from that sender ever again.
If 10 years later they wonder why they're not receiving mail from that
sender, then maybe they should have rethought clicking that "this is spam"
button from that sender.

If the recipient server wants to send messages from our server into their
users spam folders and report those as spam via the FBL, then obviously
that provider doesn't want to receive mail from our server.  If the
intended recipient of that message doesn't like it, then talk to the
recipient server administrator that's sending the messages into your spam
folder and sending it back along the FBL and ask them why they're doing
that.  Maybe it's time to consider a different provider?

Is all of that the intended function of the FBL?  Probably not.  But
there's got to be some end-user education.  End users are going to have to
realize that clicking the "this is spam" on a message from a recipient that
you clearly at one time wanted to receive messages from, doing that is
going to have consequences.

On Mon, Sep 11, 2023 at 11:58 AM Support 3Hound via mailop <
mailop@mailop.org> wrote:

> I agree with you Neil,
> let me specify it better even if it's a bit off topic.
> The FBL SHOULD NOT be used like that but this is how users act based on
> the feedback we collected from end users when we tried to understand why we
> was receiving so much FBL on double-optin collected lists and transactional
> e-mail.
> There is also a worst case: users sometime select the whole list of weekly
> e-mail received in years and click "junk" in order to achieve a "delete all
> + unsubscribe", often they do it when their mailbox get full it's a fast
> cleanup.
> So, TRUE! It's not the way it should be used but it's what the end users
> is experiencing and expecting.
>
> Coming back in topic:
> Not paying to get ARF FBL (so not unsubscribing anymore FBL) will be seen
> as a bad practice?
> Maybe this is the final act for the FBL service that is just mis-used and
> so no-more useful also for gathering reputation data...
>
>
>
>
>
> Il 11/09/2023 14:05, Neil Jenkins via mailop ha scritto:
>
> That's a … different perspective on this behaviour. Treating an FBL report
> as "unsubscribe" (or rather *proscribe* at the ESP level) is terrible for
> user experience and not at all what the feedback loop should be used for
> IMO. Users click Report Spam by mistake one time (this happens *a lot)*
> and suddenly they don't get emails they want. Even worse, as the
> proscription is often at the ESP-level, the original sender ban be unaware
> of the block and thinks they are still sending correctly. These are a
> nightmare for our customer support team to deal with — the sender's support
> are saying they are sending the message, our support are telling the
> customer there's no logs of it ever reaching our servers. The customer is
> stuck in the middle
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Cloudmark not sending remediation confirmation email?

[Scott Mutter via mailop]

Anybody from Cloudmark aware of any issues with their CSI IP Reputation
Remediation Portal form?

I've filled out the form - https://csi.cloudmark.com/en/reset - twice, I
get the message:

*An email has been sent to the email address you provided. Please follow
the instructions in this email to confirm the request for remediation.*

But I get no email.

Reviewing the logs on the server doesn't appear to show any attempt from
the Cloudmark servers of sending the email.

Is this an issue with the Cloudmark form?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] abuse_...@abuse-att.net is broken

[Scott Mutter via mailop]

Half the time they never respond to their abuse complaints.  There's a huge
thread on their forums:

https://forums.att.com/conversations/att-mail-login-security/rbl-ip-unblock-request-and-abuse_rblabuseattnet-is-not-responding/5e620c10758fed5c61aea8ff

Dates back several years.  Occasionally it gets reupped because AT isn't
responding.

On Mon, Jul 17, 2023 at 9:13 PM Byron Lunz via mailop 
wrote:

> Sent a request as instructed, but got this bounce:
>
> from alph841.aldc.att.com [135.50.89.39]
>
>- The following addresses had permanent fatal errors -
> 
> (reason: 550 5.1.1
> : Recipient address
> rejected: User unknown in local recipient table)
>
>- Transcript of session follows -
> ... while talking to a51-eastus2-prod-mtavm.az.3pc.att.com.:
> >>> DATA
> <<< 550 5.1.1 :
> Recipient address rejected: User unknown in local recipient table
> 550 5.1.1 ... User
> unknown
> <<< 554 5.5.1 Error: no valid recipients
> ___
> 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 Office365 not rejecting emails when instructed so by SPF recored?

[Scott Mutter via mailop]

On Fri, May 26, 2023 at 12:34 PM Brandon Long  wrote:

> When forwarding mail, there are two options: rewrite the envelope sender
> or not.  There are a variety of pros and cons to both of them, and cases
> where one or the other is more prominent.  Not rewriting has been the
> dominant form of 1:1 forwarding such as aliases and address migration, and
> enforcing SPF -all would break that use case.
>

If you ask me - a better solution would be to do away with forwarding
completely and incorporate POP checks, like Gmail does.  This alleviates
all of the issues with forwarding mail in relation to SPF and DKIM.

But I know that stance is wildly unpopular since it breaks the "it used to
work that way" narrative.  But at some point you add so much to a system
that it becomes so bloated and overloaded that nothing can be
accomplished.  The more simple a system is the more efficient it is going
to be.  Outside of external mail server forwarders, a properly constructed
SPF record can go a long, long way towards alleviating the spam problem.
How much is it worth to keep external forwarders working at the cost of
spam prevention?  If forwarding mail is so important, can a better system
for handling forwarded mail be developed?  I'm just not sure if the answer
is to continue to add systems and directives to email to solve all of this.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Scott Mutter via mailop]

It just seems that if people would read the documentation for SPF and
specify exactly what IP addresses are suppose to be sending email from your
domain name (I mean... if you own that domain name, shouldn't you know what
IP addresses are going to be sending legitimate mail from that domain?)
then the only all operator that should be used is -all.

But because nobody could seem to grasp this idea another record had to be
created to act as oversight for SPF and DMARC was born.

I fully expect that eventually another oversight record will be created to
oversee DMARC.

And we wonder why email is in the disarray that it is.

On Thu, May 25, 2023 at 10:38 PM Neil Jenkins via mailop 
wrote:

> On Fri, 26 May 2023, at 11:10, Scott Mutter via mailop wrote:
>
> So basically SPF is worthless.
>
>
> It's not worthless at all. It's a valuable signal to assign reputation as
> part of an overall filtering solution, and useful as part of DMARC. It's
> just the -all/?all etc. bit on the end that proved worthless.
>
> Cheers,
> Neil.
> ___
> 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 Office365 not rejecting emails when instructed so by SPF recored?

[Scott Mutter via mailop]

So basically SPF is worthless.  You can define all the IPs that legitimate
mail for the domain should be coming from and exclude everything else with
a -all and mail servers are just supposed to ignore that and look for a
DMARC record?

Talk about robbing Peter to pay Paul.

What's next?  Another DNS record to describe whether or not the DMARC
record should be honored?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Outlook JMRP unable to add new IP address

[Scott Mutter via mailop]

On Thu, Apr 6, 2023 at 4:52 PM Simon Arlott  wrote:

> If it's already in another JMRP feed you can't add it to a new one. Does
> someone else have access to the network that contains the IP? They may
> have created a JMRP feed and you're probably not able to see it.
>
> --
> Simon Arlott
>
>
Has that always been the case or is that something new?  Like within the
past 2 or 3 years new?

I don't actually own the IP address.  I just administrate (have root access
to) the server that we rent from a provider.   I don't own the IP address
for any of the servers I am an administrator to - but I am signed up on the
JMRP for most (all?) of them.  Although, truth be told, I get a
surprisingly low amount of messages/complaints from the JMRP FBL.

I can definitely understand what you are saying.  There probably does need
to be measures in place to govern who actually has access to the specific
JMRP FBL for the IP address.  But it's been my experience that the IP
address owners often lack the sense of urgency that I as the direct server
administrator have for these complaints.  I do actually review the
messages/complaints from all of the FBLs we are subscribed to daily and I
take action when a user on our server is being abusive based on these FBLS
complaints.

Can the owner of the IP address - if they are signed up to the JMRP FBL -
delegate access for the JMRP complaints of the specific IP address back to
us?  Whether or not if they'd be willing to do that is another question.
But procedurally are they able to do that from within their JMRP management
portal?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Outlook JMRP unable to add new IP address

[Scott Mutter via mailop]

Been a while since I've added an IP to our JMRP profile - but seems to not
be working.

I've done the request access for the IP and validated the IP by clicking
the link in the email.

But when I go to add the IP under the Junk Mail Reporting Program, the IP
address is not shown.

"If you want to add any IP addresses not shown below, please request access
to those IPs"

There's no IP addresses listed.  And like I've said, I've already done the
request access part.

How are we supposed to sign up new IP address to the JMRP?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spectrum/Charter.net Contact Available?

[Scott Mutter via mailop]

Kind of unnerving that this list gets filled with "Can someone from X
company contact me about a block/rejection?"

All because X companies that are too big to fail can't be bothered to
provide any way to dispute a listing or get in touch with someone that
actually administers their mail system.

On Fri, Jul 1, 2022 at 11:20 AM joe guereschi via mailop
 wrote:
>
> Haven't had luck in a while getting in touch with anyone at rr/spectrum.  
> Good luck!  I do know that senderscore has a pretty substantial impact on 
> placement as well.  If scores are below 85 or so, I start to see throttling.  
> 70 or lower, I'm typically seeing rejections.
>
> If anyone finds a legit contact, I'd love to get my hands on that as well!  ;)
>
> Happy Weekend!
>
> Joe
>
> On Fri, Jul 1, 2022 at 10:39 AM Brett Schenker via mailop  
> wrote:
>>
>> I too am looking for a contact for issues I'm seeing with a client, so would 
>> appreciate being pinged offline as well.
>>
>> Brett
>>
>> On Fri, Jul 1, 2022 at 10:04 AM Chris Truitt via mailop  
>> wrote:
>>>
>>> We're seeing intermittent AUP#In-1310 bounces from rr.com and other 
>>> Spectrum/Charter owned domains.
>>> Not getting a reply through normal channels.
>>>
>>> Can a Spectrum contact reach me offline?
>>>
>>> Thanks,
>>>
>>> Chris Truitt
>>>
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://list.mailop.org/listinfo/mailop
>>
>>
>>
>> --
>> Brett Schenker
>> Man of Many Things, Including
>> 5B Consulting - http://www.5bconsulting.com
>> Graphic Policy - http://www.graphicpolicy.com
>>
>> Twitter - http://twitter.com/bhschenker
>> LinkedIn - http://www.linkedin.com/in/brettschenker
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Forum/Blog spam turned up to 11

[Scott Mutter via mailop]

Are there effective anti-bot measures in place on the form?

How effective captcha systems are can be debatable.  BUT, if there are
no anti-bot measures on the form... then shouldn't this type of
activity/abuse be expected?

On Thu, May 26, 2022 at 8:48 PM Ken Simpson  wrote:
>
> No idea whether it’s bots or real people, but I suspect it’s bots given the 
> scale. We’re seeing thousands of unique sites per hour being “compromised” in 
> this manner.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Forum/Blog spam turned up to 11

[Scott Mutter via mailop]

Are you sure it's actual people registering or is it bots?

Do the sign up pages have effective captcha or other anti-bot/prove
you're human measures?

On Thu, May 26, 2022 at 7:30 PM Ken Simpson via mailop
 wrote:
>
> It's WooCommerce: 
> https://github.com/woocommerce/woocommerce/blob/ab1a35719c8719c0065f6053892ca970f7f01deb/plugins/woocommerce/includes/emails/class-wc-email-customer-new-account.php#L83
>
> On Thu, May 26, 2022 at 5:08 PM Ken Simpson  wrote:
>>
>> Hi Jarland,
>>
>> Yes, we see this as well - since this morning Pacific Time. They are 
>> snow-shoeing too, sending just one or two submissions per web form, 
>> presumably to keep a low profile. Same pattern of recipients as you are 
>> seeing.
>>
>> I'm trying to track down the victim software, which seems to be a WordPress 
>> plugin.
>>
>> Regards,
>> Ken
>>
>> On Thu, May 26, 2022 at 4:15 PM Jarland Donnell via mailop 
>>  wrote:
>>>
>>> Over the last week or so I've noticed an exceptional increase in
>>> outbound emails from my customers to invalid recipients. Obviously this
>>> is problematic but understandable. All of the customers in question run
>>> websites that send an email to confirm registration, and all of the
>>> recipients are properly formatted email addresses. They just don't
>>> exist, and they're increasing at an unusual rate. Others may have the
>>> same going on but may not yet be aware of the pattern. My hope is that
>>> by sharing the pattern others might begin to fight against it as well.
>>>
>>> Here is a look at some censored logs: https://clbin.com/Gxeoo
>>>
>>> Notice the trend being username + 4 digits, primarily at free email
>>> providers and regional ISPs. Examples:
>>>
>>> heidireynoldsplad2...@gmail.com
>>> susanpowersvgjfae2...@cox.net
>>> pabloharveyfhi6...@rediffmail.com
>>> florencenashhqjqj8...@orange.fr
>>> carlosfranklinlydy2...@comcast.net
>>>
>>> It's really off the charts, and it's impacting a wide variety of
>>> customers who have no relation to each other. The only similarity being
>>> that they send out website registration confirmations in all cases.
>>>
>>> Of course, my first theory is forum spam / blog comment spam. Even if
>>> they can't accomplish the spam, they have most likely built complete
>>> automation to handle this process of mass registrations for a wonderful
>>> "spray and pray" technique. Since the email accounts don't exist,
>>> they're most likely hoping that a confirmation isn't actually required
>>> to begin submitting content to the sites that they register on.
>>>
>>> Use this how you will <3
>>>
>>> Jarland
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://list.mailop.org/listinfo/mailop
>>
>>
>>
>> --
>>
>> Ken Simpson
>>
>> CEO, MailChannels
>>
>>
>> Facebook  |  Twitter  |  LinkedIn |  Help Center
>>
>> Our latest case study video: watch here!
>
>
>
> --
>
> Ken Simpson
>
> CEO, MailChannels
>
>
> Facebook  |  Twitter  |  LinkedIn |  Help Center
>
> Our latest case study video: watch here!
> ___
> 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] forwarding to gmail - problem

[Scott Mutter via mailop]

If you forward your mail to Google then Google is going to get your email.

If you give Google your POP password to retrieve mail, then Google is
going to get your email.

What more is Google going to get with your POP password versus plain
old forwarding email?

On Sun, May 8, 2022 at 6:00 AM Jaroslaw Rafa via mailop
 wrote:
>
> Dnia  6.05.2022 o godz. 14:41:49 John Levine via mailop pisze:
> >
> > Until then, I tell people who ask me to forward mail to Gmail that if
> > they actually want to get the mail, I'll put it in a local mailbox and
> > they can tell Gmail to poll it with POP.  That works quite well.
>
> As I already noted, by doing this you are giving Google the credentials to
> your mail account. This is a bad idea.
> --
> 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] forwarding to gmail - problem

[Scott Mutter via mailop]

On Fri, Apr 29, 2022 at 4:47 AM Jaroslaw Rafa via mailop
 wrote:
> I would say the opposite. Mail forwarding was there before SPF, so anybody
> who designed SPF should have taken that into account. They didn't. So SPF is
> the "bad guy" here among these two. SPF is the one that breaks forwarding,
> not forwarding the one that breaks SPF.

We'll have to agree to disagree on this one.

My opinion is that things change over time.  Innovations come about
that improve a certain situation (i.e. email) and sometimes that
encompasses certain sacrifices.

I feel like automatic email forwarders were more of a 90s technology.
People wanted to be able to check all of their mail in their Hotmail
account or in Eudora or Pegasus Mail.  Over time,
spam/phishing/spoofing (SPF is more of an anti-spoofing measure)
became more and more problematic.  Everywhere you looked people were
complaining about the spam/phishing/spoofed email messages they were
receiving.

Developers of SPF came up with the idea of authenticating email based
on the sending IP and DNS definition, BUT... this is going to break
automatic email forwarding.  So service providers that adopted SPF as
an anti-spam/phishing/spoofing measure had to decide, which was more
important:  Continuing to allow automatic forwarding or adopt a
measure that could lessen the spam/phishing/spoofed messages that
their user base receives.

I feel like automatic forwarders are used a lot less today than they
were in the 90s or 00s.  They're still used, but not as much.  Maybe
I'm wrong in that regard.  Maybe the mass of Internet and email users
need to start protesting against SPF and in favor of automatic email
forwarding because automatic email forwarding is preferred over
anti-spam/anti-phishing/anti-spoofing SPF measures.  If you survey 100
people and 80 people would prefer SPF measures over allowing automatic
email forwarding... sure it sucks if you're one of the 20 that voted
the other way... but that's how majority works.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Scott Mutter via mailop]

On Thu, Apr 28, 2022 at 7:20 PM Mark Milhollan via mailop
 wrote:
> It does not.  As recently discussed, Gmail plays a game of trying to
> guess whether SPF should have failed on a previous hop, rather than just
> the connected peer.

I don't really see that much of an issue with this in popping mail
into Gmail.  But I agree that it's something that really shouldn't be
done.

I was speaking more in terms of concept than Gmail's actual
implementation of collecting POP3 mails.

I'd argue that all spam scanning should be done on the server that is
initially receiving the mail (i.e the server Gmail is popping mail
from).  And then Gmail should just dump all mails from POP'd accounts
into the Inbox.  If Gmail can distinguish between content filtering
and authentication filtering, then they might apply content filtering
to these POP'd messages.  Although, I'd like to see an option in Gmail
when setting up to retrieve POP3 messages that there would be an
option to "Never flag these messages as spam" - thereby avoiding any
Gmail-based content (or authentication) filtering.  But yea, there's
no need to authenticate SPF or DKIM in POP'd messages - that's the job
that the receiving server (since presumably it obtained the messages
through an SMTP transaction) should be doing.

But just the concept:  The email service you are using as your MUA, if
it can collect mail from a POP/IMAP service - then it can't really
knock or blacklist that server since the MUA user has made a
conscientious decision to retrieve those mails.  It's a pull request
by the MUA.  Whereas forwarding or just sending mail in general to a
specific email address is a push to the MUA.  The MUA doesn't
explicitly acknowledge that they want to receive those messages, they
just get pushed on to them.

The service that is having these messages PUSHed onto them, sure they
can complain about the messages being spam and block the PUSHer if
they so deem.  And with automatic forwarding to Gmail, the server
doing the forwarding ... is PUSHing those messages to Gmail.  How is
Gmail supposed to know that the server is just PUSHing a message that
was PUSHed to them?  I suppose you could argue that Gmail can read the
headers and determine that the message was PUSHed onto the server that
is currently PUSHing it to them, but then what?  If they ignore it,
they're going to be receiving a lot of spam.  And they have no
jurisdiction to stop the message from being PUSHed to the original
collecting server.

But a PULL is different.  If the end user MUA doesn't want to receive
these messages... then stop PULLing them.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Scott Mutter via mailop]

Automatic email forwarders are generally a bad idea, at least in my
humble opinion.

They're always going to fail SPF unless you rewrite the
sender-envelope, which I also don't think is a good idea.

Ultimately, the argument generally comes down to "well, these used to
work" and that's part of the problem.  People expect everything to
work just like it used to - but they also want to gain all of the
benefits of newer anti-spam/anti-phishing components.  That's just
simply a false narrative.

I'm not sure what specific mail system the user is using, but my
suggestion would be to set up the address to collect into a local POP3
mailbox on the same server that's doing the forwarding.  Then
configure your Gmail account to POP mail from that POP3 mailbox.  This
side steps the issues of SPF failing, while also allowing the user to
remain exclusive to their Gmail account.

On Thu, Apr 28, 2022 at 2:02 PM Brandon Long via mailop
 wrote:
>
> Are they using the suggestions on 
> https://support.google.com/mail/answer/175365 for procmail forwarding?
>
> There's a double edge sword with SPF auth for forwarding.. if you re-write 
> the envelope sender to the forwarding address and forward spam, the 
> forwarding domain can accumulate poor reputation.  If you don't rewrite the 
> envelope sender, then the messages will no longer be SPF authed, and that may 
> cause spam detection issues.
>
> There's no great solution to this problem.  Theoretically, one could try to 
> walk the line and rewrite the sender for some messages where you think it's 
> not spam but having no auth causes issues ... though it won't work for say 
> domains with DMARC since there has to be alignment.
>
> ARC is the theoretical solution to this, where it can forward auth 
> information, but how to handle the forwarded auth information is still a work 
> in progress.
>
> In a long ago thread, we discussed the benefits of doing both forwarding and 
> pop fetching, to handle the edge cases.
>
> Brandon
>
> On Thu, Apr 28, 2022 at 11:49 AM Geoff Mulligan via mailop 
>  wrote:
>>
>> I have a user on one of my servers that uses procmail to forward messages to 
>> their gmail account.
>>
>> Every once in a while messages sent to them are "bounced" to the sender with 
>> the error fro gmail:
>>
>> 550-5.7.26 This message does not have authentication information or fails to 
>> 550-5.7.26 pass
>> authentication checks. To best protect our users from spam, the 
>> 550-5.7.26
>> message has been blocked.
>>
>> How can I diagnose this???
>>
>> Is it that the message sender's domain has a DMARC setting or some such that 
>> gmail is using and that my server (which is just forwarding the message) is 
>> failing?
>>
>> If so, how is someone supposed to forward messages to gmail???
>>
>> Thanks,
>>  Geoff
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo FBL per IP Range?

[Scott Mutter via mailop]

Been preaching about this for years.  Have yet to get anybody of value's
attention.

If you're going to block mail servers by IP address (which, to be clear, I
don't have a problem with providers doing this - and Yahoo does this along
with countless other mail services), then you need to have a feedback loop
that is IP based.

DomainKeys based feedback loops are worthless if you're an administrator on
a server that sends out mail from many, many different domains.

On Fri, Apr 22, 2022 at 7:00 AM Florian Vierke via mailop 
wrote:

> Hi Benoit,
>
> That's pretty much on top of my wishlist for Christmas as well, but so far
> there's no other option for adding domains to the Yahoo FBL.
>
> Regards,
>
>
> Florian Vierke | Senior Manager, Deliverability Services
> t: +49 89 12009713
> e: florian.vie...@mapp.com
>
> -Original Message-
> From: mailop  On Behalf Of Benoît Panizzon via
> mailop
> Sent: Freitag, 22. April 2022 11:52
> To: mailop@mailop.org
> Subject: [mailop] Yahoo FBL per IP Range?
>
> This email has reached Mapp via an external source
>
>
> Hi List
>
> I subscribed to the Yahoo FBL on after we got some 'low volume' phished
> account abused for spam and staying under our radar, targetting yahoo
> recipients which now tempfails our smtp outbound ip range for 'user
> complaints'.
>
>
> https://io.help.yahoo.com/contact/index?page=contactform=en_US=Zh%2FBBVqXzLHlIbokbUqVWTUbuuQeXGkGnZzhKR2JQ4O6mMQdy9JSWdtWFXvjthcYCRj9bUIFfycOfG%2B4GOHPHoOGa8HwDO2%2B0kYRtTcdR8Nja5P9HWkKh3VWfS3pyu4UdjhvwG%2BBCvnYFl5dToDK%2Fw%3D%3D=email-icon
>
> I added our ISP email service email domains. But we also host business
> customer domains on that email platform, which I can not all add.
>
> Does anyone know, if it is possible, to register a IP Range for YFBL?
>
> --
> 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
> Mapp Digital Germany GmbH with registered offices at Dachauer, Str. 63,
> 80335 München.
> Registered with the District Court München HRB 226181
> Managing Directors: Frasier, Christopher & Warren, Steve
> This e-mail is from Mapp Digital and its international legal entities and
> may contain information that is confidential or proprietary.
> If you are not the intended recipient, do not read, copy or distribute the
> e-mail or any attachments. Instead, please notify the sender and delete the
> e-mail and any attachments.
> Please consider the environment before printing. Thank you.
> ___
> 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] FYI - Google/Gmail hard enforcing SPF presence

[Scott Mutter via mailop]

It depends on what Google mail server you are sending to.  Some require
SPF, some don't.  Although, maybe they've since closed that loophole.
Google started requiring SPF records back in December 2021 according to the
logs I reviewed (at least for some of their mail servers).  The mail
servers that don't outright reject messages without SPF may be putting
those messages in the spam folder - I can't really verify that.

I'm a little surprised people are this upset.  Google's using SPF for what
it's actually meant for - and yet people are upset because they are doing
that?  What's the point of adding all of these anti-spam and anti-spoofing
measures into SMTP if you're blackballed for actually using them?

SPF is a great tool to prevent spamming and spoofing - but it depends on
the sender knowing how to set up a proper SPF record (as in knowing exactly
what mail servers their domain name is sending out from).  But very few
people know how to do this (or care to know).

I see Google embracing this as a good thing.  It's telling people that they
need to know what they're setting up and set it up properly.  Otherwise,
don't complain about the spam/phishing/spoofing that continues to go on.


On Tue, Apr 19, 2022 at 10:41 AM Laura Atkins via mailop 
wrote:

> On 19 Apr 2022, at 16:11, Michael Peddemors via mailop 
> wrote:
>
>
> And we also see that they have not yet 'hard enforced', but it looks like
> some trigger on a domain results in requiring SPF for that domain.
>
>
> It wouldn’t surprise me if there were some triggers that made
> authentication be looked at harder. But it is demonstrably incorrect to say
> that Google is requiring certain types of authentication for delivery.
>
> Of course, we don't expect Google to reveal their secrets, but we can
> assume things like new IP(s), new domains, sudden traffic surges, or
> customers clicking on 'this is spam' all might cause the requirement for
> SPF on a certain domain.
>
>
> This was a brand new IP without any rDNS (ie, it’s not intended to send
> mail).
>
> I do expect volume plays into it. But, as I’ve been saying: Google’s
> filtering is nuanced and tries to do the right thing most of the time.
>
> laura
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Email Delivery Blog: 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] Musings on Mail Service Operators

[Scott Mutter via mailop]

A lot of the issues stem from the way IT managers, and maybe technology
managers in general bathe in arrogance.  "There's no such thing as a good
idea, unless it is *my* idea."  It's easier to get blood out of a stone
than for someone in IT to admit that someone else's approach to something
has merit.

Email - as we know it - should have been dead years ago.  But instead we
keep adding band-aid after band-aid after band-aid to the system.

Why is it impossible to take a look at what Instant Messaging protocols,
SMTP, SMS do that make them successful and then blend those together into a
new "email-like" system?

I'm not going to pretend to know what the ultimate solution might be.  One
of the major issues with email is the address spoofing that goes on.  Maybe
a spoofed address doesn't authenticate with SPF or DKIM... but that only
works if EVERYONE else uses SPF and DKIM... that's the bandaid.  Instant
messaging and SMS can't as easily be spoofed, they may be fake but senders
have to register on the platform in some way (be it a Facebook account,
Twitter account, phone number, etc).  Would more need to be done to lock
this down?  Absolutely.  But it's at least A obstacle that potential
abusers have to overcome.  Email doesn't have that.

But as others have said there are definitely constraints to these instant
messaging and SMS protocols: size, content, searchability, etc.  These are
things that regular email does well.

Email was first invented in 1971 - that's over 50 years ago.  We've learned
a lot about how people tend to use email and how people tend to abuse email
within the past 50 years.  Instead of adding new constructs to email.  Why
not invent a new, more modern email alternative?  Something that takes a
lot of what we've learned from email usage over the years, what we've seen
in instant messaging, SMS, and other computer communication protocols and
builds on that from the ground up?  Wouldn't that be better than constantly
adding band-aids to email/SMTP to fix problems that pop up?

And don't be afraid to say no when it comes to adding every little feature
into this protocol.  I'm not a huge fan of mailing lists or distributed
mailings (forums accomplish the same thing with less of the hassle of email
deliverability concerns).  Not a huge fan of automatic email
forwarders/redirects, which tend to break SPF and DKIM.  Maybe things like
these don't need to be allowed?

I just think it's time we stop worrying about how we're going to carry
email over into the 2030s, 2040s, 2050s and on.  And instead start looking
at how we can create an email replacement from the ground up.  Too many
people invested in email, you say?  Email was around before SMS, before
Facebook, before whatever other communication medium kids are using these
days.  Yet those platforms don't seem to have an issue in getting people to
use them.  Why couldn't a properly reimagined email replacement do the same
thing?

On Wed, Feb 2, 2022 at 5:52 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia  2.02.2022 o godz. 18:26:38 yuv via mailop pisze:
> >
> > Either it will go the other way, or folks will move away from email all
> > together.  I am moving away.  I miss the ability to store away in
> > Maildir format my correspondence and to look back in the archives to
> > Eudora times and earlier, but since I made the decision to prefer other
> > methods of electronic communication over email, I feel much better.
>
> Just out of curiosity: what better methods of communication did you find? I
> can't find any. Text messages via phone won't do, any IM-type programs (be
> it Facebook Messenger, Signal, Telegram or anything else) won't do either.
> They are unsearchable, unmanageable, limited in size and in the type of
> content you can send, plus there is the mentioned "walled gardens" issue,
> that is, (except of text messages) you have to use the same service than
> the
> person you try to communicate with.
>
> For me, still nothing beats e-mail - even with all the deliverability
> problems...
> --
> 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] Forms vs email abuse reporting

[Scott Mutter via mailop]

I didn't really mean to go all out, anti-AT or anything.  I was just
merely using them as an example because when they block an IP address the
bounce back message says to contact them directly at an email address.  If
instead of the email address this pointed to a form on their website, I
think that would be much better.

AT is the only example I can think of right now that doesn't send you to
a form to dispute a blacklisting.  By contract, Microsoft (albeit, it's not
really that direct of a link) sends you to a form to dispute an IP
blacklisting - I like that better.

Further from that, I'm not really sure if that's the type of abuse contact
the OP was referring to in this thread.

On Wed, Jan 19, 2022 at 8:07 PM Michael Rathbun via mailop <
mailop@mailop.org> wrote:

> On Wed, 19 Jan 2022 15:55:40 -0600, Scott Mutter via mailop
>  wrote:
>
> >(AT is just an example here, but serves to better illustrate how a form
> >could be useful in this situation)
>
> Based on their corporate behaviour in recent experience, I would assert
> that
> AT is not a useful case, comparable to the general run.
>
> For instance, in the tariff side, it is well known that AT's Global Fraud
> Department has not responded to telephone calls for many years, and if we
> want
> to get traction handling a fraudulent account created in my wife's name,
> which
> AT required NO confirming identification to establish, my wife must
> appear
> in person at an official AT shop, with photo ID, to confirm that she is
> the
> person who did not set up the account.  We decline to do this, so they
> continue to bombard an email account I set up in 2008 for a test of a
> co-reg
> site, demanding payment.  The fraudsters appear to have access to AT's
> customer history database, my wife's SSAN, and access to the USPS database
> that will give you the addresses of newly-vacated residences, the names of
> the
> former occupants, when they moved, and where they have moved to.
>
> AT could have caught the folks who ordered the tricked-out iPhone 13 on
> installment, and had it sent to an address we vacated months ago, but yawn.
>
> At least we have a free phone for all the hassle, though we haven't decided
> what to do with it.  They do offer a form for fraud reports, but you can't
> fill it out without knowing the entire account number, which you can't know
> unless you activate the phone, or visit a store as noted above.
>
> So, imagine how keen they will be to handle silly little issues such as the
> ones you describe.  It's not difficult to imagine that the budget lines for
> all those abuse-handling activities are asymptotically approaching the cube
> root of zero.
>
> 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
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Forms vs email abuse reporting

[Scott Mutter via mailop]

It depends on what context you are referring to.

Are you talking about abuse contact as a means to dispute abuse
complaints?  In that case, I'd say a form is better.  An example is AT
When AT blocks our server, the bounce back message tells us to send an
email to abuse_...@abuse-att.net.  I'm sure abuse_...@abuse-att.net gets a
TON of spam messages sent to it.  So how are we supposed to ensure that our
message gets through all the spam noise and to the eyes of someone that can
make a difference?  Do I use a Subject of "You are blocking me!" or "I'm
blacklisted"  or "Please look into this blacklist" or what do I use?  What
specific information do they want to investigate the dispute?  Obviously
the IP address, but what else?

For AT I basically have to send a message to abuse_...@abuse-att.net
every day, sometimes for 2 weeks, before I finally get the attention of
somebody.  There's a slew of threads on AT Community forums about the
on/off nature of responses from abuse_...@abuse-att.net.

I can't help but wonder if they had a form on their website where you could
dispute their listings.  A website form can be sent to ANY email address,
such that nobody really knows what email address it's sent to.  For
example, AT could have a form that when submitted sends to
hsd9234hsdhf89sfh823g...@abuse-att.net - it's very, very unlikely that
someone just randomly sends an email to
hsd9234hsdhf89sfh823g...@abuse-att.net, so you know that every email coming
into hsd9234hsdhf89sfh823g...@abuse-att.net was sent to you from that
form.  You can cover the form with various anti-spam and anti-bot measures
you then GREATLY reduce the spam noise concerning would be listing disputes.

(AT is just an example here, but serves to better illustrate how a form
could be useful in this situation)

If you're talking about Feedback Loops or otherwise automatically reporting
spam - then email is probably better.  Although you could also feed
information to a callback URL (much like PayPal's Instant Payment
Notification system) where the owner of the website would be responsible
for collecting the information fed into it.  A callback URL might have a
benefit in that the entity doing the reporting wouldn't have to worry with
bounce back messages to the abuse contact email address.  Either way - I
would think that the receiver of these abuse reports would want some way to
distinguish between feedback loop reports or automatic spam reports (they
don't really need a response, just action) and abuse messages that need an
actual written response.

On Wed, Jan 19, 2022 at 2:54 PM Jarland Donnell via mailop <
mailop@mailop.org> wrote:

> Some may see that as a good thing. It's the old Office Space scene where
> one thing happens and the guy has multiple bosses come by and tell him
> the same thing all day long. When I worked at a big cloud I'd catch a
> spammer and terminate them, then I'd have to talk to 16 different people
> over the next 30 days about it. Some see a clear path to abuse@ as kind
> and easy, while others see it as a place to vomit every single piece of
> trash they have to nuke it into oblivion. At least a form forces people
> to be intentional and thoughtful.
>
> Most of us on this list would probably scratch our heads as to why
> someone wouldn't want every single abuse complaint, but Linode and
> DigitalOcean just see all of their massive barely educated self-hosting
> Wordpress customers bombarding each other's abuse@ with endless piles of
> piss, for example. Everyone has their burden, and it's an interesting
> topic. Everything changes at scale.
>
> Personally, I'm fine with just the abuse@ route and my intention is to
> automate as many inbound reports as possible as I scale, but more often
> than not what I find when I hit various points of scale is that instead
> of doing better than OtherCompany is that I find out why they did what
> they do.
>
> On 2022-01-19 13:40, John Levine via mailop wrote:
> > It appears that Grant Taylor via mailop 
> > said:
> >> -=-=-=-=-=-
> >> -=-=-=-=-=-
> >>
> >> On 1/19/22 2:54 AM, Alessandro Vesely via mailop wrote:
> >>> I guess it is difficult to process, but I fail to understand how
> >>> forms can ease that task,
> >>
> >> I think it comes down to unstructured vs structured data.  Forms can
> >> have fields for each pertinent piece of information thus applying
> >> structure to the reports.
> >
> > You want structure, we have ARF and maybe XARF, which are delivered by
> > e-mail and designed to be machine generated and machine parsed. The
> > problem with forms is that they are not consistent and can't be
> > automated and I have much better things to do with my time than to
> > paste spam into other people's web forms.
> >
> > R's,
> > John
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> 

Re: [mailop] [SUBJECT CHANGE] Feedback loops

[Scott Mutter via mailop]

On Mon, Jan 17, 2022 at 6:06 PM Grant Taylor via mailop 
wrote:

> Why can't automated and manual reports go to the same address?  Isn't
> that what recipient side filtering is for?  E.g. separating RFC standard
> DSNs / MDNs from human generated messages, each handled by different teams.
>
> My problem with FBLs is that I have to know to sign up for FBLs.
> Conversely, mailbox operators can probably more easily send push
> notifications to published addresses, whatever the industry accepted
> method is.
>
>
I keep going back to the AOL Feedback Loop of yesteryear.  I didn't
actually READ every message in that mailbox.  But I could run a script
through a procmail recipe to increment counts by IP that AOL was sending
back to that FBL.  So that when an IP got 10 or so messages within a
certain period it would alert me at another email address that I watched.

The abuse email address and feedback loop email address don't have to be
different.  But, for me (which may not be the same thing for everyone
else), the FBL address was just means to tally information.  Sure, I could
go back into that address and manually review the feedback reports I got
and often that was the next step after being alerted to high number of
reports for a certain IP, but it's main purpose was just to automate a
tally.

I actually like feedback loops.  To my knowledge Microsoft is the only one
that has anything any where close to what the AOL Feedback Loop was like.
But it's a hassle to sign up for it, and it either goes through periods
where it's broken or it only sends reports if X number of mailings come
into Microsoft from an IP address.  Or maybe I just have some really nice
users that always send legitimate mail to Microsoft/Hotmail/Outlook
addresses and none of our servers ever get flagged as spam (begs the
question as to why Microsoft blocks our servers from time to time though).

Gmail and Yahoo all base their feedback loops on DomainKeys or something,
it's not IP based.  I know Comcast and some of the other ReturnPath
customers have feedback loops, but traffic on those are low too.

As a responsible server administrator - I don't mind signing up for
feedback loops to help safeguard my servers.  I would think any other
responsible server administrator would feel the same way.  I just want
those feedback loops to work.  If Microsoft is going to block my server IP
claiming that we sent them spam, but I never get anything in their feedback
loop - then that's an ineffective feedback loop.  Same for Yahoo and Gmail
and really any email service provider that's going to block my server IP.

Now if others in this discussion are arguing that Microsoft/Yahoo/Gmail/etc
are sending feedback loop reports to abuse contacts listed in RDAP, RP,
rWhois, any where else - then my bone to pick is with my IP delegation
provider because they're not forwarding these on to me.  Perhaps it's just
a lack of communication and they don't know that I want to receive these -
that's a fair point.  Or perhaps there's so many different ways to define
an abuse contact address (RDAP, RP, rWhois, etc) that different service
providers look for different contact structures and the feedback reports
all end up in a gobbled mess.  If that's the case then there needs to be a
SINGLE defined way to publish a contact address that receives feedback
reports.  BUT... I just really don't think Microsoft/Yahoo/Gmail/etc are
sending feedback reports for EVERY single spam message they get back to
these RDAP, RP, rWhois abuse contacts.  But I'm a big enough man to admit
that I've been wrong before.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] still not a good way to publish contact info, was What am I supposed to do

[Scott Mutter via mailop]

We've really taken the original topic off course.  But I feel that we may
be taking the secondary topic off course as well.

All the talk about abuse contacts in RDAP or RP DNS - I'm not saying that
these have merits... BUT... Is Microsoft/Yahoo/Gmail/*insert whatever big
name email service* sending EVERY spam/abuse complaint for messages from
the IP address to these contact addresses?

That's part of the issue - and we're kind of seeing that within this
discussion.  There's a lot of different ways to publish an abuse address,
so many in fact... do the entities reporting the abuse (i.e.
Microsoft/Yahoo/Gmail) follow all of these?  An abuse contact address is
only as good as the abuse information that's being funneled into it.
Another words, if Microsoft is never sending anything to the Abuse contact
in RDAP... what good does it do to have an abuse contact in RDAP?

Additionally, are all of these big name email service providers going to
automatically send feedback to these abuse contacts for every single
message that their users flag as spam or that their systems flags as spam?

That's where a distinction needs to be made.

I feel like the abuse contact that's being suggested in RDAP, RP, rWhois,
etc - are all intended to be manually sent by a human, i.e. someone from
one of these big name email service providers (Microsoft/Yahoo/Gmail).  And
I don't really see them having humans tasked with manually sending out
these abuse notices for every spam message that an IP address sends.

That's where I feel feedback loops are more automated and generally better
equipped to notify the difference makers that can really take action on the
spam/abuse.

An example situation would be, if Microsoft/Hotmail/Outlook is getting spam
from one of my servers - I'd very much like to know about it.  I'd very
much like to see the headers of those messages, so that I can track down
the offending account and stop it.  But I can only do that if
Microsoft/Hotmail/Outlook tells me that they are receiving spam from one of
my servers.  I can only track it down if I have some message headers to go
on.  If Microsoft/Hotmail/Outlook is not going to send me that notice and
information... then how can I be expected to stop it?  Is
Microsoft/Hotmail/Outlook sending ALL of that information/notices to the
abuse address in RDAP, RP, rWhois, etc?  Or are they just deciding at some
point that they've received too much spam from my server, that they're just
going to block the IP address and never tell anyone that could potentially
make a difference?

On Mon, Jan 17, 2022 at 5:08 PM John Levine via mailop 
wrote:

> It appears that Grant Taylor via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >On 1/17/22 11:49 AM, Scott Mutter via mailop wrote:
> >> Do reverse DNS entries support the TXT structure?
> >
> >I can't remember the last time I used it to say with any certainty.  But
> >would completely expect that it would.  Remember, reverse DNS is simply
> >a permutation to a forward DNS query to an ARPA subdomain.
>
> There's no technical difference between a reverse DNS zone and any
> other DNS zone.  I have an MX in mine so you can send mail to me
> at jo...@18.183.57.64.in-addr.arpa, just because I can.
>
> BUT ...
>
> See my previous message about RDAP.  If people want to publish
> contact info for their IP ranges, they can do it now in the
> RIR WHOIS.  The problem is that they don't want to.
>
> Also, in most organizations there is a great distance between the
> people who run mail servers and the people who run rDNS.  As often
> as not, the rDNS is run by an upstream network, not the operator
> themselves.  So even if it were a good idea to put RP records into
> the rDNS, which it isn't (see above) the practical obstacles would
> be huge.
>
> R's,
> John
>
> PS:
>
> >> Or an IP address has to reverse back to a hostname - put the TXT record
> >> in that DNS zone.
> >
> >I don't think it's good to /rely/ or /depend/ on PTR records resolving
> >IPs to host names.
>
> Dunno about you, but where I am, if an IP does not have matching forward
> and reverse DNS, that is a very strong signal that it's not supposed to
> be hosting a server and you don't want to accept mail from it.
> ___
> 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] What am I supposed to do with abuse complaints on legit mail?

[Scott Mutter via mailop]

On Mon, Jan 17, 2022 at 12:06 PM Grant Taylor via mailop 
wrote:

> Drive by comment:
>
> What if we had something like an MX record published for the IP
> address(es) in reverse DNS / in-addr.arpa for
> ... and configure those MX records to route to a mail server
> of the owners / administrators of the IP (space) in question?
>

Do reverse DNS entries support the TXT structure?  Why not just create a
special, specific TXT record for a contact email address?

Or an IP address has to reverse back to a hostname - put the TXT record in
that DNS zone.

I'd be onboard with something like that.

To perhaps extend on this topic, perhaps there should be two contacts - a
blanket abuse contact and a specific contact for feedback loops (feedback
loops being defined as when a user flags a message as spam or a
receiving server automatically flags a message as spam).  This way a
dedicated email address can be used just for feedback loops.  I would
further recommend some type of standard feedback loop form.  If information
in the feedback loops need to be tied to a specific data structure, I might
suggest sending this information in an encoded JSON format.  The point
being, feedback loops aren't necessarily reviewed by a human every time,
but instead are tabulated to measure by account/email address/IP address
where the abuse is coming from.

On the other hand of all of this, we would have to deal with all of the
spam that would be forthcoming to the email address since it would be made
publicly available.  Distinguishing between legitimate complaints coming
into that email address and the spam coming into the email address can be
difficult.  Further separating the blanket abuse contact (i.e. for when
someone needs to speak to a human concerning this IP address) and the
feedback loop address - with a standard feedback loop structure, would at
least allow me to better distinguish known spam/abuse that is being
reported to the feedback loop address.

I'm willing to listen to any suggestions, but I have absolutely no pull
within the industry to make things happen.

My hope was to just steer/open a discussion that I don't think a lot of
people realize the disconnected relationship between IP address ownership
and mail server administrators.  I'm not pretending to suggest that I have
all of the answers.  But I don't think this disconnected relationship is
fully understood throughout the industry, and especially with the large,
big name email service providers.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What am I supposed to do with abuse complaints on legit mail?

[Scott Mutter via mailop]

On Mon, Jan 17, 2022 at 5:32 AM Alessandro Vesely via mailop <
mailop@mailop.org> wrote:

> I'm not clear what you mean by "secure your own IP block".
>
> Besides, for the mxroute address you wrote from, 149.28.56.236, I find an
> abuse address of ab...@vultr.com, which looks like your ISP's.
>

This again points to some of the assumptions that people on Mailops seem to
have.  Often times, the owner of the IP (i.e. vultr.com) isn't necessarily
the administrator of the mail server sending out mail from the IP (i.e. who
has root to the server).  For us, we rent servers from various companies.
Those companies own the IP addresses (or sometimes they're renting rack
space and IP addressing in a datacenter and the ownership of the IP address
goes up another level), but they don't have root access to the server
(technically since they have actual hands in the datacenter, they could get
root to the server if they booted into single user mode).

At the same time, I understand why Mailops preaches that they send abuse
reports to the owner of the IP address - which, again, may be several
company levels up from the individual that actually has root to the server
and can take more immediate action against the abuse.  I'm not really going
to cry foul that Microsoft, Gmail, Yahoo, all the other big name mail
services aren't actually sending the abuse reports to the administrators of
the servers that matter.  Ideally, sure, the reports would go to the IP
owner and that would filter down to the root administrator of the server.
That doesn't happen very often - if ever.  Perhaps this is something these
IP owners (i.e. vultr.com, Linode, etc) need to address.  Perhaps these IP
owners need to require it so that when a customer signs up for their
services, they have to provide an email address to forward feedback loop
messages to for their assigned IP?

Whether or not if these big name mail services realize how razor thin the
connection is between IP owner and root server administrator is not
something I know, although I suspect that it's more likely they are
oblivious to this.

I might question whether those reports are actually being sent to the IP
owner in the first place, it provides plausible deniability in the event
that they unilaterally decide to block or blacklist an IP address.  Because
as I said, those notices from the IP owner rarely get filtered down to the
root server administrator.  It then becomes a closing ticket matter when
it's revealed that the person inquiring about the block (the root server
administrator) isn't the IP owner.

I still go back to the way the AOL Feedback Loop system worked in the
2000s.  I was able to stop A LOT of spam abuse on our servers when these
were reporting and being sent to AOL addresses - which often times included
many, many other email services (gmail, hotmail, yahoo, etc).  The signup
process made a ton of sense, you registered an IP address, AOL did a
reverse lookup on the IP, you had to acknowledge that you could receive
email at postmas...@reverselookupt.ld or ab...@reverselookupt.ld, and then
you were able to receive redacted messages that AOL users flagged as spam
(or maybe the system flagged as spam?) that came from that IP address.
There was no involvement in the "owner" of the IP address.

I just wish people could be a bit more open-minded when it comes to
reporting spam and abuse from mail servers.  It's like nobody wants to hear
or consider viewpoints on how email and email servers are being
administered and learn from those.  The second they see that someone isn't
managing their mail server the way THEY manage a mail server then
immediately that someone is wrong.  Why is it so hard to take feedback,
ponder on it, and maybe admit "hey! that's not a bad idea!"
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What am I supposed to do with abuse complaints on legit mail?

[Scott Mutter via mailop]

The issue is that big name mail service providers, like Gmail, Microsoft,
Yahoo - do not offer a way to get effective feedback loops.  Again, this is
why I say the AOL feedback loop system of the 2000's was so great.  I've
NEVER gotten anything from Gmail's Postmaster tools for any of the servers
(which asks for a domain name and not an IP address).  Once in a blue moon
I get something from Microsoft's JMRP, but they still block IPs with out
any reports.  Yahoo's FBL is based on DomainKeys.

The oft rumor with Gmail's Postmaster tools is that you have to reach a
certain mail sending limit for Google to generate reports, I suspect that
our servers all fall below that threshold.  I suspect it's the same or
similar thing with Microsoft's JMRP.  But both services block our IPs from
time to time.  How - pray, tell - am I supposed to know that these services
are seeing bad things or abuse from our IPs if they don't tell me?

Look, I get it.  It's difficult to justify expending resources generating
feedback reports for IPs that don't really send a lot of mail.  But that
doesn't mean that those IPs can't be sending out unwanted emails.  So I can
understand why these providers don't send out reports for IPs that fall
under a certain threshold.

BUT - that's got to work both ways.  You can't expect me to know that
you're receiving unwanted emails from my server's IP if you do not tell
me.  If I can understand your reasons for not sending out all feedback
reports then you have to understand why small mail server operators get
upset when you suddenly block our IPs and then give us the runaround to get
the IP unblocked.  If you think it's completely unreasonable for us small
time mail server operators to get upset when you block an IP without giving
us any feedback - that's where you've lost touch with reality.

On Thu, Jan 13, 2022 at 9:13 PM Jay Hennigan via mailop 
wrote:

> On 1/13/22 16:08, Scott Mutter via mailop wrote:
> > I'm not sure what value of Recipients is really referring to - but I
> > think this is kind of the question that needs to be asked.  Should the
> > administrator of a sending server (the IP address) be responsible for
> > removing addresses from a mailing list?  Probably.
>
> Absolutely. Not specifically removing addresses from mailing lists, but
> ensuring that the server associated with that IP address doesn't send
> UBE. If abuse originates from that IP address, the administrator of the
> machine bound to that IP is responsible for stopping it whether the
> abuse is spam, brute-force SSH attacks, viruses, SIP attacks, ping
> floods, or any other form of abuse.
>
> > But in order for the
> > administrator of the sending server to know about this, reports are
> > going to have to come to the administrator of the sending server based
> > on it's IP address.
>
> Yes, and that is accomplished by parsing headers, WHOIS, and having a
> working and responsive abuse contact.
>
> > I'm an administrator of a mail server (many mail servers).
>
> Then you should have a vested interest in running a clean shop.
>
> > I (personally) don't really send out emails through these servers.
>
> Most administrators of multi-user mail servers don't personally send
> much mail through them on a percentage basis.
>
> > We sell a service to customers that allows them to use the server to
> > send out emails.
>
> In other words, you profit from allowing others to use your server. You
> charge for the service of delivering mail on behalf of your customers.
>
> > It's those customers that are sending out mailing lists and/or
> > questionable marketing messages, etc.
>
> Then you need to fire the customers who you are presently allowing to
> abuse the Internet. "I don't personally robocall people to pitch car
> warranty scams. I sell phone service to customers. It's those customers
> that are placing the robocalls, etc. I just take their money and enable
> them to annoy people." Whose facility do you think is going to get
> blocked by other carriers and tracked down by the FTC/FCC? You or your
> customers?
>
> > When those customers send messages to Yahoo or any other email service
> > ... they really don't care if the individual recipient at Yahoo or
> > whoever flags that message as spam.  Is this wrong?  Absolutely!  But
> > this is the disconnect from reality that I think a lot of Mailops seem
> > to discount.
>
> Where's the disconnect? You profit by sending mail on behalf of
> customers. Those customers don't care if they are spamming. They aren't
> going to stop spamming because it's profitable for them. You may choose
> not to police your customers because it's profitable for you. The
> victims of the abuse don't know of or care about your relationship with
> your cu

Re: [mailop] [E] Re: What am I supposed to do with abuse complaints on legit mail?

[Scott Mutter via mailop]

> Domain reputation is a thing though. If your IP really gets blocked (and
not just throttled; that's a signal you have access to btw) you usually
have a bigger problem.

Unfortunately, that's not what I'm seeing in the real world.  Everything is
IP based.  Go through the archives here at Mailops.  Over the past month
how many messages has this list gotten with request for help from
Microsoft, Comcast, T-Mobile, etc all concerning their mail server IPs
being blocked?  They block by IP address.

I'm not really saying that blocking by IP address is a bad idea.  I get
it.  I get why it's so effective.  I'm just saying you can't say you're
acknowledging spam from certain domains or DomainKeys and then go and block
the IP that's sending.  You're comparing apples to oranges.

I remember the early 00's with AOL's feedback loop.  This was a wonderful,
wonderful thing.  It helped that a lot of people still had AOL email
addresses.  I could sign up all of my SMTP server IPs to funnel in spam
feedback to a single email address.  I could monitor that email address for
feedback reports.  The reports included all of the headers, including the
message ID that I could parse through my logs to identify the sender.  And
then I could take action against that account on our server.  But
eventually AOL addresses died off and that FBL became dormant.  I wish
Gmail, Yahoo, Microsoft, all had similar feedback loops - that would be the
most useful thing to me as a server administrator.  I think Gmail may have
something similar but it's useless because you have to send 100 million
messages a day (or some absurd high number) to get the feedback loop to
register a single incident.  AOL's feedback loop from the 2000s was the
pinnacle of feedback loops.  I think instead of looking at something that
lowly AOL did successfully, all of these big name mail service providers
are taking the idea and trying to "improve" it to the point that it's
ineffective.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What am I supposed to do with abuse complaints on legit mail?

[Scott Mutter via mailop]

I'm not sure what value of Recipients is really referring to - but I think
this is kind of the question that needs to be asked.  Should the
administrator of a sending server (the IP address) be responsible for
removing addresses from a mailing list?  Probably.  But in order for the
administrator of the sending server to know about this, reports are going
to have to come to the administrator of the sending server based on it's IP
address.

I'm an administrator of a mail server (many mail servers).

I (personally) don't really send out emails through these servers.

We sell a service to customers that allows them to use the server to send
out emails.

It's those customers that are sending out mailing lists and/or questionable
marketing messages, etc.

When those customers send messages to Yahoo or any other email service ...
they really don't care if the individual recipient at Yahoo or whoever
flags that message as spam.  Is this wrong?  Absolutely!  But this is the
disconnect from reality that I think a lot of Mailops seem to discount.
We've reached a point in society where individuals can't read and can't be
expected to take the 90 seconds it takes to read and understand something,
they want to be spoon fed information.  ... If an individual in the general
public gets a feedback loop report about a message being spam... they're
not going to read it... they're not going to take the time to understand
it... they're just going to keep sending out to their list just ignoring
that report

Now, eventually, Yahoo or whatever mail service, will say that the mail
server that I'm an administrator to has sent them too much spam and they
start to block/blacklist/throttle mail from the server.

I'm left out in the cold because 1) I'm not the one sending out the mailing
list messages 2) I have no way of getting feedback loop messages from Yahoo
or whatever mail service for this sending IP 3) there's a severe lack of
ways to get in touch with a human person at Yahoo or whatever mail service
to discuss the situation.

Some people seem to assume that 1 IP address = 1 domain sending out mail =
1 person responsible for managing that.  And that is just simply not true.
1 IP address may have 1000s of domains sending out emails, which may refer
to 1000s of different individuals.  The common denominator is the sending
IP address and that's why abuse reports, feedback loops, and all discussion
about the quality/quantity of mail coming from that IP address needs to
refer to the individual that is managing the SMTP service at that IP
address.

If a service is going to block/blacklist/throttle messages by the sending
IP, then what good does it do to base feedback loops and spam reports on a
domain basis?  A sending IP could have 1000 domains sending from it and
only 1 of those domains is sending spam or sending to a list that is being
flagged as spam, but the recipient server isn't going to block based on
domain, it's going to block based on IP.

On Thu, Jan 13, 2022 at 4:23 PM Grant Taylor via mailop 
wrote:

> On 1/13/22 1:00 PM, Scott Mutter via mailop wrote:
> > The person sending out the mails or mailing list often doesn't care if
> > their recipients are flagging messages as spam or if their messages are
> > being treated as spam or unsolicited.
>
> Does this imply that the person sending out the mails to the mailing
> list cares more about the message going to $RECIPIENTS and less about
> the actual value of $RECIPIENTS?  Sort of implying that the SMTP server
> operators have some leeway to remove / unsubscribe a few specific
> recipients from the larger $RECIPIENTS list in the spirit of protecting
> the larger overall system operation and flow?
>
>
>
> --
> Grant. . . .
> unix || die
>
> ___
> 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] What am I supposed to do with abuse complaints on legit mail?

[Scott Mutter via mailop]

I think some of what's lost in this discussion - and it's true this may be
dragging the discussion off-topic, but seems as good a time as any to bring
this up.

Often times the individual maintaining the mailing list or sending out the
emails, is not the same individual that administers and maintains the SMTP
server that's doing the actual sending out.

Props to a mailing list administrators that actually handles unsubscribing
members that flag messages as spam or email senders that actually care
about how their messages are being treated.  But this is most often, not
the case.

The person sending out the mails or mailing list often doesn't care if
their recipients are flagging messages as spam or if their messages are
being treated as spam or unsolicited.  It's only until it comes to the desk
of the SMTP server administrator that the server is blocked/blacklisted
that this then becomes a problem.  That's why I think it's better for mail
servers to focus their feedback loops or however else they report
spam/abuse back to the SMTP server administrator and not the emailing
domain owner.



On Thu, Jan 13, 2022 at 1:13 PM Matt Vernhout via mailop 
wrote:

> On Thu, Jan 13, 2022 at 1:41 AM Jay Hennigan via mailop 
> wrote:
>
>> Agreed 100%.
>>
>> A single acknowledgement of a successful unsubscribe is fine, but don't
>> make them jump through another flaming hoop. This goes double if the
>> "subscription" is the typical webinar/whitepaper spam that they never
>> wanted in the first place.
>>
>> In my opinion, a single reply email, "You have been unsubscribed from
>> xyz mailing list" is a good thing to do.
>>
>
> A number of years ago while working at an ESP we tried this, sending a
> notice that was along the lines of "Thank you for reporting this message as
> spam, we have taken action to remove you from the mailing list and will
> review the sending practices of XYZ Brand ."
>
> Two things happened:
>
> 1 - People replied in large numbers "I never reported this as spam, I want
> to continue receiving these emails" - depending on the day >20% of the
> messages generated this reply
> 2 - People reported the reply/notification as spam.
>
> Needless to say it was a short-lived experiment as it just created more
> support overhead for us having to undo the unsubscribe or deal with angry
> customers getting calls from their subscribers. Which is actually in line
> with where this whole conversation started...
>
> ~ Matt
>
> ___
> 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] What am I supposed to do with abuse complaints on legit mail?

[Scott Mutter via mailop]

Yahoo's Feedback Loop is DomainKey based, but their blocking is IP based.
At least that's how it used to be.  Never made much sense to me to have an
FBL based on DomainKeys, meaning every domain name that sends from an IP
address has to have a registered feedback loop based on the DomainKey.  All
of the other FBLs are IP based.

On Mon, Jan 10, 2022 at 4:08 PM Douglas Vought via mailop 
wrote:

> On 1/10/2022 4:41 PM, Marcel Becker via mailop wrote:
>
> > Can you clarify what you mean by the "Yahoo anti-spam feedback
> > system"? Is it an actual ARF report you get as part of our FBL/CFL
> > program
>
>
> Hi Marcel,
>
> My understanding is that it's an ARF report:
>
> > This is an email abuse report for an email message from themsgctr.com
> > on Fri, 7 Jan 2022 16:38:11 +
>
> The weird thing is that it came ~10 seconds after that email was sent.
> So I'm wondering if maybe it's automated. Or my customer has superhuman
> spam-reporting capabilities ;)
>
> Best,
>
> Douglas
>
> ___
> 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] No answer from abuse-att.net?

[Scott Mutter via mailop]

This is why I cringe everytime I see a provider asking you to "send an
email to x...@yyy.com to get delisted."

x...@yyy.com is going to get flooded with spam also.  Whoever is on the
receiving end of that email address isn't going to know what's legitimate
and what's not legitimate.

It's so much better to have a form on your website for handling this type
of request.  Then you can enact anti-bot and anti-spam bot measures.  You
can have that form be sent to an email address that remains completely
oblivious to anyone else on the Internet, and then you are much more sure
that messages being received at that email address are legitimate requests
that came from that form.


 a bit off-topic from this particular thread, but has anybody noticed
how this mailing list is becoming more and more a "anybody from company ZZZ
that can help with delisting?"  ... Maybe that should tell all of these
companies and email service providers that they need to address their
delisting procedures or the measures they are taking to block IP addresses.


On Wed, Dec 15, 2021 at 11:23 AM Bill Cole via mailop 
wrote:

> On 2021-12-15 at 10:30:27 UTC-0500 (Wed, 15 Dec 2021 08:30:27 -0700)
> Rob Nagler via mailop 
> is rumored to have said:
>
> > 216.17.132.35 is being blocked by AT We (bivio.com) got the
> > auto-response (twice) from abuse_...@abuse-att.net, but it's been a week
> > without a change or email.
>
> Random Related Data Point:
>
> I have just had a cycle of entirely unexplained IP blocking of that sort
> from AT this week and it appears to have been resolved (no longer getting
> a fast 5xx reply to MAIL) as soon as I got back the canned response (which
> took 6 days) despite a warning in that message that it might take 24-48
> hours. So that address CAN work, as recently as yesterday.
>
> OTOH, so little flow goes through that machine (a tight 1-customer relay
> for transactional mail to their paying customers from various web apps)
> that I don't know for sure that they haven't already reinstated the
> erroneous blocking for the same unknowable reason they did so originally...
> ___
> 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] Is there any analysis on root causes of mail account break-ins?

[Scott Mutter via mailop]

Another thing that people maybe haven't thought of, and it's actually a
wider issue than just email password compromises.

A lot of people just don't care that much about their password security.
The thinking is "what's someone going to do if they can log into my email
account and read my emails?"  They don't think of the other potential
consequences of having their password information leaked out.  They don't
consider the abuse that could happen when malicious users obtain this
information.  They see a password simply as a requirement to access their
not-so-government-secret correspondence.  So they choose a simple and easy
to remember password.

On Wed, Nov 17, 2021 at 2:17 PM Slavko via mailop  wrote:

> Hi,
>
> Dňa Wed, 17 Nov 2021 13:31:50 -0600 Scott Mutter via mailop
>  napísal:
>
> > Unless you are sending an encrypted password to your mail server (in
> > which case, the compromiser still has the necessary to log into your
> > email account) then this has to be decrypted some how by the email
> > application. Again, if you're not entering anything to decrypt this
> > then that means the necessary information to decrypt the encrypted
> > stored password is on the system in some manner.
>
> I agree in principle, but it becomes real problem if that software is
> used by 60 % of Internet users (hi Chrome), if it is used by 0,00x %
> users, it must be really targeted attack, otherwise its success will be
> very very low.
>
> Question remains, how valuable will be success targeted attack against
> **regular** users -- IMO more theoretical than real (and some people
> still consider me as paranoid ;-) ).
>
> regards
>
> --
> Slavko
> https://www.slavino.sk
> ___
> 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] Is there any analysis on root causes of mail account break-ins?

[Scott Mutter via mailop]

>If one use good email client/browser, locally stored passwords are not a
> problem as they are encrypted

Unless you are sending an encrypted password to your mail server (in which
case, the compromiser still has the necessary to log into your email
account) then this has to be decrypted some how by the email application.
Again, if you're not entering anything to decrypt this then that means the
necessary information to decrypt the encrypted stored password is on the
system in some manner.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is there any analysis on root causes of mail account break-ins?

[Scott Mutter via mailop]

Don't forget local compromises - keyloggers, spyware, and other malware -
running on an end-user's system.

If you are checking your email with an email client and not entering your
password every time you check for mail (which most of us don't do) then the
password to your email is stored some where locally on your system.  A
crafted piece of malware can get the password that way.

If you're checking your email via webmail and you're not typing in your
password every time you log in, i.e. it's stored in your browser... then
the password is stored some where locally on your system.  A crafted piece
of malware could find that password as well.

On Wed, Nov 17, 2021 at 11:21 AM John Levine via mailop 
wrote:

> It appears that Bill Cole via mailop  said:
> >Who needs to bother with brute force "cracking" when so many passwords
> >are just out there for the taking?
>
> Botnets.  My MTA accepts any login, says it works, and directs any
> subsequent mail
> to the spamtrap.  Here's attempts from the last 20 minutes.  Some of those
> logins
> are related to actual addresses here, some are just random.
>
> 2021-11-17 11:55:34.713814500 mailfront[19253]: Fake login hsttbhpvx /
> hsttbh123
> 2021-11-17 11:55:59.927913500 mailfront[19323]: Fake login leonard@c /
> leonar123
> 2021-11-17 11:57:13.664694500 mailfront[19603]: Fake login bob2@bob /
> bob22020
> 2021-11-17 11:57:19.972595500 mailfront[19614]: Fake login webmaster /
> webmas123
> 2021-11-17 11:57:24.721663500 mailfront[19622]: Fake login mcknight. /
> mcknig123
> 2021-11-17 11:57:49.227991500 mailfront[19676]: Fake login 1993jul19 /
> 1993ju123
> 2021-11-17 11:57:59.733940500 mailfront[19696]: Fake login saudadesd /
> saudad123
> 2021-11-17 11:58:32.167072500 mailfront[19806]: Fake login dofcowsou /
> dofcow123
> 2021-11-17 11:58:48.499845500 mailfront[19849]: Fake login xxuqtby@l /
> xxuqtb123
> 2021-11-17 11:59:15.775566500 mailfront[19933]: Fake login larisaxdv /
> larisa123
> 2021-11-17 11:59:19.308656500 mailfront[19937]: Fake login stratfor@ /
> stratf123
> 2021-11-17 11:59:27.927226500 mailfront[19960]: Fake login areferker@iec
> / areferker2020
> 2021-11-17 11:59:40.918734500 mailfront[20024]: Fake login postmaste /
> postma123
> 2021-11-17 11:59:55.085884500 mailfront[20061]: Fake login spayeddbe /
> spayed123
> 2021-11-17 12:01:19.801787500 mailfront[20349]: Fake login bobrisks@bob /
> bobrisks2020
> 2021-11-17 12:01:28.290702500 mailfront[20362]: Fake login asrg@joh /
> asrg2020
> 2021-11-17 12:02:13.205276500 mailfront[20537]: Fake login bobf@fra /
> bobf2020
> 2021-11-17 12:02:22.114495500 mailfront[20581]: Fake login airliners /
> airlin123
> 2021-11-17 12:02:52.691619500 mailfront[20704]: Fake login postmaste /
> postma123
> 2021-11-17 12:03:25.757517500 mailfront[20839]: Fake login postmaste /
> postma123
> 2021-11-17 12:03:47.168752500 mailfront[20891]: Fake login jonathon@ /
> jonath123
> 2021-11-17 12:04:03.789002500 mailfront[20934]: Fake login info@zeu /
> password
> 2021-11-17 12:04:15.674974500 mailfront[20970]: Fake login obnoxious /
> obnoxi123
> 2021-11-17 12:04:57.635122500 mailfront[21150]: Fake login kseniyawx /
> kseniy123
> 2021-11-17 12:05:18.170965500 mailfront[21242]: Fake login xwmhdral@ /
> xwmhdr123
> 2021-11-17 12:05:36.038108500 mailfront[21305]: Fake login asrg@bob /
> asrg2020
> 2021-11-17 12:07:38.065773500 mailfront[21776]: Fake login as@zeu / as2020
> 2021-11-17 12:08:00.444663500 mailfront[21851]: Fake login aalter@bobf /
> aalter@1234
> 2021-11-17 12:08:05.554393500 mailfront[21858]: Fake login andrewjnash@iec
> / andrewjnash2020
> 2021-11-17 12:08:08.867614500 mailfront[21872]: Fake login anna12550@zeu
> / anna125502020
> 2021-11-17 12:08:30.686983500 mailfront[21995]: Fake login approval@iec /
> approval2020
> 2021-11-17 12:08:52.278898500 mailfront[22082]: Fake login arsenii@iecc /
> arsenii@1234
> 2021-11-17 12:09:10.315914500 mailfront[22140]: Fake login yuliafrwy /
> yuliaf123
> 2021-11-17 12:09:42.345135500 mailfront[22207]: Fake login postmaste /
> postma123
> 2021-11-17 12:10:08.705233500 mailfront[22327]: Fake login atlantic@ /
> atlant123
> 2021-11-17 12:11:16.344928500 mailfront[22478]: Fake login pistols@c /
> pistol123
> 2021-11-17 12:11:29.804099500 mailfront[22512]: Fake login webmaster /
> webmas123
> 2021-11-17 12:11:55.193699500 mailfront[22605]: Fake login bobmarly@bob /
> bobmarly2020
> 2021-11-17 12:12:25.315811500 mailfront[22690]: Fake login travelmol /
> travel123
> 2021-11-17 12:12:25.576148500 mailfront[22675]: Fake login approve@tel /
> approve2020
> 2021-11-17 12:12:48.556795500 mailfront[22734]: Fake login 299.13@ /
> 13@1234
> 2021-11-17 12:13:45.074059500 mailfront[22933]: Fake login costcentr /
> costce123
> 2021-11-17 12:14:57.807258500 mailfront[23156]: Fake login barryjoe0 /
> barryj123
> 2021-11-17 12:16:11.739180500 mailfront[23449]: Fake login alison@iec /
> alison2020
> 2021-11-17 12:16:15.895229500 mailfront[23482]: Fake login shannoncb /
> shanno123
> 2021-11-17 

Re: [mailop] ATT.NET abuse_...@abuse-att.net contact ?

[Scott Mutter via mailop]

Just keep sending them an email everyday.  Sometimes you have to send an
email a day for a week or two before they pick up on it.

Not sure why they haven't created a website form to submit these.  Relying
on email for delisting like this is a recipe for disaster.  What do we set
the Subject as to ensure that the powers that be will actually recognize
the message as not spam?  What information do we include in the message?

On Thu, Nov 11, 2021 at 2:25 PM Ryan Prihoda via mailop 
wrote:

> I have a single well established IP address that has ended up being
> blacklisted by ATT. I have yet to hear anything back from their abuse
> email. Is there anyone can help?
>
> Thanks,
>
> Ryan Prihoda
> ___
> 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] [EXTERNAL] Re: Vade - Blacklisting

[Scott Mutter via mailop]

Thanks guys!  This all seems to be resolved now.  At least with Comcast -
it would seem they were kind enough to allow an exemption for our IP
address in this.  But I suspect any other mail server that is utilizing
Vade we may run into this issue with them as well.

Appreciate others checking and verifying that they were not seeing any spam
from this IP.  I know too well that spamming incidents can happen, but when
they do I can usually tell because the IP is blocked with numerous lists
and services.  And in those cases I very much understand why it's listed.
I do what I can to prevent these spamming incidents, but unfortunately some
fall through the cracks every now and then.

Unfortunate that an entire class C was listed in this.  It might be
important to note that a lot of providers further split up that class C
into multiple entities and then delegate those IPs out to others for use.
I guess desperate times call for desperate measures which leads to a class
C listing.  But seldom is it all 256 IPs in the class C that are a part of
the abuse.

On Tue, Aug 17, 2021 at 9:23 AM Brotman, Alex 
wrote:

> Comcast utilizes an RBL supplied by Vade, as the URL indicated.  This has
> been remediated as of early this morning, and it was noted that it wasn’t a
> single IP in the /24 that was to blame (I don’t have more information than
> that currently).
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* mailop  *On Behalf Of *Scott Mutter
> via mailop
> *Sent:* Monday, August 16, 2021 9:08 PM
> *To:* mailop@mailop.org
> *Subject:* Re: [mailop] [EXTERNAL] Re: Vade - Blacklisting
>
>
>
> Thanks Alex.
>
>
>
> This looks to be working now.
>
>
>
> Was this being blocked by Comcast or by Vade?
>
>
>
> Unfortunately I don't have services or access to the whole /24.  Tis a
> shame that an entire Class-C had to be blocked.
>
>
>
> On Mon, Aug 16, 2021 at 2:55 PM Brotman, Alex 
> wrote:
>
> Not sure why my response didn’t go to the list:
>
>
>
> Scott,
>
>
>
> It looks like the /24 is blocked, and I’ll see if I can find out why (I’ll
> reply off-list with that info).  In the meantime, we’ll put in an exemption
> for the range.  That should be in place shortly.
>
>
>
>
>
>
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* mailop  *On Behalf Of *Scott Mutter
> via mailop
> *Sent:* Monday, August 16, 2021 2:25 PM
> *To:* mailop@mailop.org
> *Subject:* [EXTERNAL] Re: [mailop] Vade - Blacklisting
>
>
>
> Got the response:
>
>
>
> *Hello,*
>
>
>
>
> *Thank you for your report. It has been taken into account in our
> continuous improvement processus. We will get back to you if necessary.
> Please note that the analysis may take a few days and your situation might
> improve in the meantime. We advise you to keep an eye on your performance.*
>
> *Regards*
>
> *Your Anti-Abuse Vade team.*
>
>
>
> And it's still blocked.
>
> Apologies because I'm probably not in the right state of mind right now.
> This is kind of a tipping point for me right now.  Just really frustrated
> at providers like this that feel they can hold us hostage simply because
> we're not Microsoft, or Yahoo, or Google.
>
> I mean, if the IP is really sending out spam (why is it not on any other
> blacklist?) then I want to know.  I want to remedy the situation.  But to
> block an IP for no reason.  To refuse to unblock an IP for no reason.  ...
> Why is a reputable company like Comcast (?) going to bed with such an
> entity?
>
>
>
> On Mon, Aug 16, 2021 at 1:03 PM Al Iverson 
> wrote:
>
> You might find https://sendertool.vadesecure.com/
> <https://urldefense.com/v3/__https:/sendertool.vadesecure.com/__;!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d77DtUYCAr9wO2-RhgVAc$>
> to be a better way
> to work through the issue.
>
> Good luck,
> Al Iverson
>
> On Mon, Aug 16, 2021 at 12:24 PM Scott Mutter via mailop
>  wrote:
> >
> > Anybody from Vade on the list able to give any details as to why
> 66.11.124.112 is listed?
> >
> > Apparently Comcast uses Vade as part of their blacklist and this IP is
> being blocked by Comcast's mail servers
> >
> > 554 resimta-po-40v.sys.comcast.net resimta-po-40v.sys.comcast.net
> 66.11.124.112 found on one or more DNSBLs, see
> http://postmaster.comcast.net/smtp-error-codes.php#BL001000
> <https://urldefense.com/v3/__http:/postmaster.comcast.net/smtp-error-codes.php*BL001000__;Iw!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d7

Re: [mailop] [EXTERNAL] Re: Vade - Blacklisting

[Scott Mutter via mailop]

Thanks Alex.

This looks to be working now.

Was this being blocked by Comcast or by Vade?

Unfortunately I don't have services or access to the whole /24.  Tis a
shame that an entire Class-C had to be blocked.

On Mon, Aug 16, 2021 at 2:55 PM Brotman, Alex 
wrote:

> Not sure why my response didn’t go to the list:
>
>
>
> Scott,
>
>
>
> It looks like the /24 is blocked, and I’ll see if I can find out why (I’ll
> reply off-list with that info).  In the meantime, we’ll put in an exemption
> for the range.  That should be in place shortly.
>
>
>
>
>
>
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* mailop  *On Behalf Of *Scott Mutter
> via mailop
> *Sent:* Monday, August 16, 2021 2:25 PM
> *To:* mailop@mailop.org
> *Subject:* [EXTERNAL] Re: [mailop] Vade - Blacklisting
>
>
>
> Got the response:
>
>
>
> *Hello,*
>
>
>
>
> *Thank you for your report. It has been taken into account in our
> continuous improvement processus. We will get back to you if necessary.
> Please note that the analysis may take a few days and your situation might
> improve in the meantime. We advise you to keep an eye on your performance.*
>
> *Regards*
>
> *Your Anti-Abuse Vade team.*
>
>
>
> And it's still blocked.
>
> Apologies because I'm probably not in the right state of mind right now.
> This is kind of a tipping point for me right now.  Just really frustrated
> at providers like this that feel they can hold us hostage simply because
> we're not Microsoft, or Yahoo, or Google.
>
> I mean, if the IP is really sending out spam (why is it not on any other
> blacklist?) then I want to know.  I want to remedy the situation.  But to
> block an IP for no reason.  To refuse to unblock an IP for no reason.  ...
> Why is a reputable company like Comcast (?) going to bed with such an
> entity?
>
>
>
> On Mon, Aug 16, 2021 at 1:03 PM Al Iverson 
> wrote:
>
> You might find https://sendertool.vadesecure.com/
> <https://urldefense.com/v3/__https:/sendertool.vadesecure.com/__;!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d77DtUYCAr9wO2-RhgVAc$>
> to be a better way
> to work through the issue.
>
> Good luck,
> Al Iverson
>
> On Mon, Aug 16, 2021 at 12:24 PM Scott Mutter via mailop
>  wrote:
> >
> > Anybody from Vade on the list able to give any details as to why
> 66.11.124.112 is listed?
> >
> > Apparently Comcast uses Vade as part of their blacklist and this IP is
> being blocked by Comcast's mail servers
> >
> > 554 resimta-po-40v.sys.comcast.net resimta-po-40v.sys.comcast.net
> 66.11.124.112 found on one or more DNSBLs, see
> http://postmaster.comcast.net/smtp-error-codes.php#BL001000
> <https://urldefense.com/v3/__http:/postmaster.comcast.net/smtp-error-codes.php*BL001000__;Iw!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d77DtUYCAr9wO26ZjDBa2$>
> >
> > Going to http://postmaster.comcast.net/smtp-error-codes.php#BL001000
> <https://urldefense.com/v3/__http:/postmaster.comcast.net/smtp-error-codes.php*BL001000__;Iw!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d77DtUYCAr9wO26ZjDBa2$>
> leads to a spill where they pass the buck to Vade.
> >
> > Would really like to know why this IP is listed with Vade.  Or does Vade
> just add IPs to their blacklist because they can?
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> <https://urldefense.com/v3/__https:/list.mailop.org/listinfo/mailop__;!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d77DtUYCAr9wO27e2wrTS$>
>
>
>
> --
> Al Iverson // Wombatmail // Chicago
> Deliverability: https://spamresource.com
> <https://urldefense.com/v3/__https:/spamresource.com__;!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d77DtUYCAr9wO20vhwXbl$>
> DNS Tools: https://xnnd.com
> <https://urldefense.com/v3/__https:/xnnd.com__;!!CQl3mcHX2A!XF25OLva-Ih77MhIuEK7cs4xHphSzQOYD2a2I7TNSNKYmE4d77DtUYCAr9wO2wEDljQc$>
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Vade - Blacklisting

[Scott Mutter via mailop]

Got the response:

*Hello,*




*Thank you for your report. It has been taken into account in our
continuous improvement processus. We will get back to you if necessary.
Please note that the analysis may take a few days and your situation might
improve in the meantime. We advise you to keep an eye on your performance.*

*Regards*

*Your Anti-Abuse Vade team.*


And it's still blocked.

Apologies because I'm probably not in the right state of mind right now.
This is kind of a tipping point for me right now.  Just really frustrated
at providers like this that feel they can hold us hostage simply because
we're not Microsoft, or Yahoo, or Google.

I mean, if the IP is really sending out spam (why is it not on any other
blacklist?) then I want to know.  I want to remedy the situation.  But to
block an IP for no reason.  To refuse to unblock an IP for no reason.  ...
Why is a reputable company like Comcast (?) going to bed with such an
entity?

On Mon, Aug 16, 2021 at 1:03 PM Al Iverson  wrote:

> You might find https://sendertool.vadesecure.com/ to be a better way
> to work through the issue.
>
> Good luck,
> Al Iverson
>
> On Mon, Aug 16, 2021 at 12:24 PM Scott Mutter via mailop
>  wrote:
> >
> > Anybody from Vade on the list able to give any details as to why
> 66.11.124.112 is listed?
> >
> > Apparently Comcast uses Vade as part of their blacklist and this IP is
> being blocked by Comcast's mail servers
> >
> > 554 resimta-po-40v.sys.comcast.net resimta-po-40v.sys.comcast.net
> 66.11.124.112 found on one or more DNSBLs, see
> http://postmaster.comcast.net/smtp-error-codes.php#BL001000
> >
> > Going to http://postmaster.comcast.net/smtp-error-codes.php#BL001000
> leads to a spill where they pass the buck to Vade.
> >
> > Would really like to know why this IP is listed with Vade.  Or does Vade
> just add IPs to their blacklist because they can?
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
>
>
> --
> Al Iverson // Wombatmail // Chicago
> Deliverability: https://spamresource.com
> DNS Tools: https://xnnd.com
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Vade - Blacklisting

[Scott Mutter via mailop]

Anybody from Vade on the list able to give any details as to
why 66.11.124.112 is listed?

Apparently Comcast uses Vade as part of their blacklist and this IP is
being blocked by Comcast's mail servers

554 resimta-po-40v.sys.comcast.net resimta-po-40v.sys.comcast.net
66.11.124.112 found on one or more DNSBLs, see
http://postmaster.comcast.net/smtp-error-codes.php#BL001000

Going to http://postmaster.comcast.net/smtp-error-codes.php#BL001000 leads
to a spill where they pass the buck to Vade.

Would really like to know why this IP is listed with Vade.  Or does Vade
just add IPs to their blacklist because they can?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So how do you actually manage to send mails to outlook/hotmail?

[Scott Mutter via mailop]

> If your correspondent opens a ticket with MS and says "I want to get
email from Marcus and it goes into spam and I don't think it should", they
may put mitigation in for you. It has less effect if you are the one
opening the ticket though.

What ticket form would these people need to fill out?  I'm curious about
this aspect.


On Sun, Jul 11, 2021 at 1:10 PM Mike Reed via mailop 
wrote:

> Hi Marcus,
>
> Is this mail ending up in spam folders or never appearing to your
> correspondents at all?
>
> It helps a lot if you can get your correspondents to mark the emails from
> you as "not spam" in their apps. You might learn some additional
> information if you can get some to send back the headers.
>
> If your correspondent opens a ticket with MS and says "I want to get email
> from Marcus and it goes into spam and I don't think it should", they may
> put mitigation in for you. It has less effect if you are the one opening
> the ticket though.
>
> Best of luck,
> Mike
> ___
> 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] Malware waves from hotmail.com

[Scott Mutter via mailop]

Many thanks for the links - these would seem to accomplish the desired task.

On Sat, Jun 5, 2021 at 6:11 PM joemailop--- via mailop 
wrote:

> Hello Scott,
>
> Azure's IP space, updated once a week with one week lead before they go
> live -
> https://www.microsoft.com/en-us/download/details.aspx?id=56519
>
> From the looks of the json filename, it is changed after each release, so
> I wouldn't recommend re-downloading the below json file for new updates -
>
> https://download.microsoft.com/download/7/1/D/71D86715-5596-4529-9B13-DA13A5DE5B63/ServiceTags_Public_20210531.json
>
> AWS - https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html  -
> If the download URL doesn't change (doesn't seem to me that it does), you
> can go straight to https://ip-ranges.amazonaws.com/ip-ranges.json. If you
> have an AWS account, you can sign up for notifications when new subnets are
> added. (It requires using their SNS service.)
>
> GCP - https://cloud.google.com/compute/docs/faq#find_ip_range - If the
> download URL doesn't change (doesn't seem to me that it does), you can go
> straight to https://www.gstatic.com/ipranges/cloud.json
>
> -joe
>
>
> On 6/5/2021 at 7:22 AM, "Michael Peddemors via mailop" 
> wrote:
> >
> >Sorry, bit laid up and typing with one hand, but luckily all the
> >top
> >three publicly list their IP(s), unfortunately they do it via web
> >URLs'
> >that you need to parse instead of via say a rwhois entry.
> >
> >(some are listed at various services you can query in RBL format
> >such as
> >RATS-AZURE)
> >
> >Some you can check via  PTR naming conventions, and others you can
> >do an
> >ASN lookup.
> >
> >don't have the URL's handy, but welcome to reach out off list.
> >
> >
> >
> >On 2021-06-04 4:08 p.m., Scott Mutter via mailop wrote:
> >> On Fri, Jun 4, 2021 at 1:24 PM Michael Peddemors via mailop
> >> mailto:mailop@mailop.org>> wrote:
> >>
> >> With apache, you can use modsecurity quite easily, and you
> >can block
> >> all
> >> azure (and other cloud providers ranges) from certain
> >services like
> >> wordpress, or contact forms etc.. (you can even do dns based
> >checks or
> >> rbldnsd) ..
> >>
> >>
> >> Are there any links for this? AFAIK mod_security is just a
> >module - to
> >> actually do anything it requires a ruleset.  Further from that,
> >how does
> >> it determine what is Azure and what is not?  Is it just blocking
> >IP
> >> addresses?  Seems you'd need a list of all of the Azure IP
> >address
> >> space.  And from what I have seen the offending IPs are all over
> >the place:
> >>
> >> 157.55.39.138
> >> 207.46.13.5
> >> 20.83.33.136
> >> 20.94.247.9
> >> 40.124.141.27
> >> 40.124.141.27
> >> 40.124.193.244
> >> 40.76.220.206
> >>
> >> Are just a few.
> >>
> >> But if there's a way to block Azure and other cloud based
> >services, I'd
> >> be interested in that.  But I'd suspect you'd need a list of all
> >of
> >> their IP address spaces - is that information available some
> >where?
> >>
> >>
> >> ___
> >> mailop mailing list
> >> mailop@mailop.org
> >> https://list.mailop.org/listinfo/mailop
> >>
> >
> >
> >
> >--
> >"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 Registered TradeMark of Wizard Tower TechnoServices
> >Ltd.
> >---
> >-
> >604-682-0300 Beautiful British Columbia, Canada
> >
> >This email and any electronic data contained are confidential and
> >intended
> >solely for the use of the individual or entity to which they are
> >addressed.
> >Please note that any views or opinions presented in this email are
> >solely
> >those of the author and are not intended to represent those of the
> >company.
> >___
> >mailop mailing list
> >mailop@mailop.org
> >https://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Malware waves from hotmail.com

[Scott Mutter via mailop]

On Fri, Jun 4, 2021 at 1:24 PM Michael Peddemors via mailop <
mailop@mailop.org> wrote:

> With apache, you can use modsecurity quite easily, and you can block all
> azure (and other cloud providers ranges) from certain services like
> wordpress, or contact forms etc.. (you can even do dns based checks or
> rbldnsd) ..
>
>
Are there any links for this? AFAIK mod_security is just a module - to
actually do anything it requires a ruleset.  Further from that, how does it
determine what is Azure and what is not?  Is it just blocking IP
addresses?  Seems you'd need a list of all of the Azure IP address space.
And from what I have seen the offending IPs are all over the place:

157.55.39.138
207.46.13.5
20.83.33.136
20.94.247.9
40.124.141.27
40.124.141.27
40.124.193.244
40.76.220.206

Are just a few.

But if there's a way to block Azure and other cloud based services, I'd be
interested in that.  But I'd suspect you'd need a list of all of their IP
address spaces - is that information available some where?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Malware waves from hotmail.com

[Scott Mutter via mailop]

Not to hijack this thread and send it off-topic, but I'm also seeing a lot
of brute force attempts (mostly WordPress login attempts) from various and
wide-ranging subnets of Microsoft IPs.

Has Microsoft's network been compromised?

On Fri, Jun 4, 2021 at 10:46 AM Jörg Backschues via mailop <
mailop@mailop.org> wrote:

> On 04.06.21 at 10:20h  Bjoern Franke wrote via mailop:
>
> > since several weeks we are getting several mails a day from hotmail.com
> > users with subjects like "fob xt k xerhc", an attached malware PDF like
> > [1] and adressed to ~200 recipients.
>
> The good thing is, that the patterns are very clearly here:
>
> - subject:   3 characters, blank, 2 characters
> - body:  4 characters, blank, 2 characters
> - file name: 7 characters with .pdf extension
>
> The bad thing is, that there's no feedback from Microsoft's abuse desk
> for several weeks.
>
> --
> Regards Jörg
>
> ___
> 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] protection.outlook.com refusing to accept mail with misleading temp error message

[Scott Mutter via mailop]

The issue - at least to me - has always been that Microsoft is viewed as
this big, huge company that can do no wrong.

When our users have issues sending to Microsoft email servers - it's
obviously because *we're* stupid and something is wrong with *our* server.
It can't possibly be a Microsoft issue.  Microsoft made Windows, what did
we make?

That's the narrative that needs to change.  If end-users would somehow
start to realize that Microsoft has a horrible email system, fewer people
would be inclined to use Microsoft based email accounts.

That's basically what we have done.  I'm sure we've probably lost some
clients over it.  But if you're using a Microsoft based email address for
anything mission critical, then I'm sorry, you're probably missing stuff.
And not just stuff from us, but from any number of other places.  Missing
stuff could be because of a no reason block/blacklist or just a silent
deletion of the message.


On Tue, Jun 1, 2021 at 3:50 PM Hans-Martin Mosner via mailop <
mailop@mailop.org> wrote:

> Am 01.06.21 um 21:39 schrieb John Levine via mailop:
> >
> > No, it's to deliver the mail that the users want. One point that bulk
> > mailers often miss is that, while the recipients at large providers do
> > not object to getting the bulk mail, they also do not really want it.
>
> We're not talking about bulk mail here. We're talking about messages
> between individual users, including such things as
> doctor or vaccination appointments, meeting schedule coordination, etc,
> which both affected parties consider important.
> Some occasional small mailing lists for group information exchange, too.
> No marketing stuff, social media notifications
> or other noise that people wouldn't miss.
>
> I'm pretty strict myself when it comes to blocking spam-emitting sites.
> And of course, it also happens that we block
> some IPs or IP ranges due to spamming and some time later it turns out
> that the same hosts are used by legitimate
> senders. We have several mechanisms in place to detect and remedy such
> situations quickly. And when we notice spam
> floods (such as the current hotmail bot flood) from mail systems we're
> going out of our way to implement very specific
> filters that keep out the drek while allowing legitimate mails through.
>
> It's really not necessary to play devil's advocate here. It's the devil,
> he can defend himself quite well if he chooses
> to speak.
>
> Cheers,
> Hans-Martin
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Scott Mutter via mailop]

Not to really defend Microsoft here - because I've had my own run-ins with
their system and agree that it doesn't make a lot of sense.

But this isn't an only-Microsoft problem.  Pretty much every big-name mail
service provider will employ similar tactics in some capacity.

I get it... Microsoft and these big-name mail service providers have a lot
of users and a lot of users that complain about spam.  But they don't
exactly do themselves any favors by working with entities that really want
to reduce the abuse on their servers and networks.

I fear that eventually the day will come where external mail really won't
work... have a gmail address and you want to write somebody at a hotmail
address?  Tough luck!  If you want to send an email to a hotmail address
you'll have to sign up for a hotmail address and send your message from
your own hotmail address.  Etc, etc.

If you ask me, it's high-time for a replacement for SMTP to come forward.
The replacement can largely operate just like SMTP, but instead of having a
who's who of meaningless authentication protocols (SPF, DKIM, DMARC) have
some type of standard authentication that all of these SMTP-replacement
servers have to follow.  I won't pretend to know what all of this might
entail.  But there's got to be some way we can move forward with all of
this.  There are just way too many instances of IPs and servers being
blocked/blacklisted with no way to challenge those listings and no way to
be informed of such listings.  Often times it seems like these big-name
mail service providers can just block/blacklist IPs on a whim, because who
is going to challenge them?


On Tue, May 11, 2021 at 12:45 PM André Peters via mailop 
wrote:

> What is this crap good for when it sends one out of 1000? There was not a
> single spam mail that left our system. It was an unwanted mail, not spam
> but just a message they did not like. We have hard rate limits and a no
> mass mail policy. We also check ridiculously detailed for patterns of spam.
>
> It's just one of the most stupid systems on this planet that is NOT
> working because you MS guys are so clever, no, it's still working because
> of its size. No matter who is responsible.  That's sad. Really sad.
>
>
>
> Am 11.05.2021 um 19:39 schrieb Michael Wise via mailop  >:
>
> 
>
>
>
> JMRP doesn’t send every email reported as spam to the sender.
>
> Last I heard, it was 1 in 1,000 or some such.
>
> This is to prevent listwashing, as should be obvious.
>
>
>
> And just ONE mail sent to the wrong address … well … that can get a whole
> lot of IPs blocked if it looks suspicious in the eyes of the investigator.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Open a ticket for Hotmail 
> ?
>
>
>
> *From:* mailop  *On Behalf Of *André Peters
> via mailop
> *Sent:* Tuesday, May 11, 2021 5:38 AM
> *To:* mailop 
> *Subject:* [EXTERNAL] Re: [mailop] Registered @ Microsoft JMRP -
> blacklisted without feedback received
>
>
>
> IMO it's a totally useless system.
>
>
>
> We have had ASNs blocked without a single complaint prior to it. Not a
> single one.
>
>
>
> Once every 2-3 month we get a complaint and contact the complaining
> person. Out of ~10 times it was only ONCE a mail, that the rcpt did not
> want to receive.
>
>
>
> If you want to receive mail, don't register with MS. I cannot say this
> often enough.
>
>
>
> To add a small hint: Try to send ~the same mail volume and don't cause
> peaks. Do not send to too many recipients in one session.
>
>
>
> Funny enough we receive a lot of spam from MS at the moment...
>
>
>
> -- Originalnachricht --
>
> Von: "Laura Atkins via mailop" 
>
> An: "mailop" 
>
> Gesendet: 11.05.2021 14:25:11
>
> Betreff: Re: [mailop] Registered @ Microsoft JMRP - blacklisted without
> feedback received
>
>
>
> Given you are the service provider, the best place to look is in your
> abuse queue. Look for complaints about mail from that IP (and surrounding
> IPs) going back for a while. Typically, the consumer ISPs will put mail in
> the bulk folder for a while before escalating to a block. When the mail is
> going to bulk you will not see complaints as users cannot send FBL messages
> related to mail in the bulk folder. This means low complaint rates
> immediately before a block Do Not Mean that the mail is fine. In fact, it
> often means that the mail is already identified as spam. You need to go
> back further, to before MS was putting the messages in the bulk folder, in
> order to see complaints about it.
>
>
>
> Going back over time will give you some information about what customer
> and what mail streams were causing problems. That should give you some
> insight into which customers you need to address to get the block lifted.
>
>
>
> The other place to look is your outbound logs. What are your customers
> doing and what types of mail are they sending? Did 

Re: [mailop] Microsoft Consumer Email Deliverability Issue

[Scott Mutter via mailop]

The fact that filling out their support ticket does nothing except generate
canned responses and that you have to come here to Mailops to get any
movement on a blocked IP address or blocked server - you would think that
that would tell Microsoft something about how ineffective their support
ticket system is.  (But as others have said, they don't really care).



On Sat, May 1, 2021 at 12:28 PM André Peters via mailop 
wrote:

> I can only agree. Using Outlook means check your junk for important mail
> and find a lot of trash in your inbox.
>
> We have moved countless new customers away from Outlook because of this
> issue. I don't know why they don't care. Really.
>
>
> > Am 01.05.2021 um 18:55 schrieb Matt Corallo via mailop <
> mailop@mailop.org>:
> >
> > If you're a small-scale sender, this is just the way it goes with
> Outlook.com - SNDS doesn't do anything except provide you %s, and because
> the number of emails from small-scale senders is so low (and the
> "customers" here don't even pay for the service), Microsoft isn't
> incentivized to fix the issue. The usual "if you're using
> outlook.com/hotmail and don't check your junk folder regularly, you're
> missing messages" rule applies.
> >
> > If you're in the very-small-scale sender club SNDS doesn't even show you
> % mails that went to spam, and exists purely to inform you that your IPs
> "have normal status" despite all the mail from them going direct to Junk
> (and all the headers, like you mentioned, showing scores of
> PCL=2/SCL=0/BCL=0).
> >
> > Worse, they haven't correctly resolved SPF/DKIM DNS records for many
> months (despite sending and receiving DNS queries for the associated
> records)[1], spuriously failing messages that others accept without issue.
> >
> > [1]
> https://techcommunity.microsoft.com/t5/outlook/received-spf-temperror-protection-outlook-com-error-in/m-p/1801696
> >
> > Matt
> >
> >> On 4/29/21 20:26, Robert Schoneman via mailop wrote:
> >> We're having issues sending order confirmations from our event
> ticketing system to users of Microsoft's consumer email services (Outlook,
> Hotmail, Live, MSN). The order confirmations are being sent to Junk. Some
> details are below this paragraph. I've communicated with Microsoft's
> "Outlook.com Deliverability Support Team" and while they were very
> responsive, unfortunately we hit a roadblock. They wanted us to enroll in
> JMRP and SNDS. Microsoft's JMRP system requires enrollment in SNDS.
> However, to enroll in SNDS requires verifying ownership of the sending
> IP's. We don't own them. Our event ticketing system vendor who does hasn't
> been helpful. We own the sending domain.
> >>  * SPF, DKIM, DMARC are all good and show as "pass" in the email
> headers of messages sent to junk.
> >>  * Sending IP's have the correct PTR records.
> >>  * Looking at the headers of a message sent to Junk, I see that our PCL
> = 2, SCL = 0 and BCL = 0.
> >>  * MS confirmed our sending IP's  and domain aren't the issue: "We were
> unable to identify anything on our side that
> >>would prevent your mail from reaching Outlook.com customers."
> >>  * MS did however determine that "messages are being filtered (i.e.
> sent to the Junk folder) based on the
> >>recommendations of the SmartScreen Filter."
> >>  * Email messages from the same sending domain and IP's, using the same
> address, which are other than order
> >>confirmations (reports, for example) deliver to my Outlook.com email
> address' Inbox without issue.
> >>  * The offending emails have
> >>  o No attachments
> >>  o One image stored on the same domain the message is sent from
> >>  o No links
> >>  o No card info
> >>  o A name and email address matching the recipient
> >>  * All emails are sent from a valid address and all NDRs/bounces are
> resolved.
> >>  * No marketing or bulk mail is sent from the domain.
> >>  * The same emails sent to Google, AOL, Yahoo deliver without issue.
> >> I'm out of ideas here and would welcome any help on or off list.  Our
> concern is if we can’t deliver an order confirmation to our customers who
> use these email services, we’ll also have issues delivering their
> electronic tickets.
> >> Robert Schoneman | Director of IT
> >> *Blumenthal Performing Arts*
> >> ___
> >> mailop mailing list
> >> mailop@mailop.org
> >> https://list.mailop.org/listinfo/mailop
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail issues with Level 3 / Tier.Net?

[Scott Mutter via mailop]

Looks like it's an issue with Verizon / XO

# mtr --report-cycles=20 --report-wide --report -n 209.85.146.27
Start: Sat Mar  6 14:45:56 2021
HOST: hornet.wznoc.com Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 66.11.124.1   0.0%201.4   4.3   0.4  12.3   4.2
  2.|-- 199.47.224.20 0.0%201.0   0.8   0.5   2.7   0.4
  3.|-- ???  100.0200.0   0.0   0.0   0.0   0.0

But they don't appear to be in any hurry to get it resolved.  Issue has
persisted for 36 hours now.

Haven't received any connections from any mail.*.google.com servers since
1AM EST March 5th.


On Sat, Mar 6, 2021 at 11:54 AM J. Hellenthal 
wrote:

> trace routes ? Pings ? Anything here?
>
> --
>  J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says
> a lot about anticipated traffic volume.
>
> > On Mar 6, 2021, at 10:50, Scott Mutter via mailop 
> wrote:
> >
> > 
> > Some of our servers have not received emails from Gmail since early
> Friday morning.  We're also not able to connect to some of Gmail's mail
> servers from these servers.
> >
> > Is Gmail blocking some of these IPs?  A routing issue?  Anybody from
> Gmail able to contact me off list to look into this?
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Gmail issues with Level 3 / Tier.Net?

[Scott Mutter via mailop]

Some of our servers have not received emails from Gmail since early Friday
morning.  We're also not able to connect to some of Gmail's mail servers
from these servers.

Is Gmail blocking some of these IPs?  A routing issue?  Anybody from Gmail
able to contact me off list to look into this?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hotmail and block on OVH: possible solutions alternatives?

[Scott Mutter via mailop]

> Aren't things like FBLs, or Google's Postmaster Tools, exactly the thing
> that COULD (and IMHO should) be used for this?

Ideally, yea, they probably could be.  But are Feedback Loops still in
use?  I've never gotten a single iota from Google's Feedback Loop or
Postmaster tools.  Maybe there's a certain threshold volume you have to hit
before it starts registering and we never reach that.

I'm also not getting anything from Microsoft's JMRP - and again, maybe
that's a threshold thing.  But I have had IPs blocked by Microsoft before.
Was it explicitly the IP address I am USING?  Or was it a neighbor IP that
caused the block?  Nobody knows, so we all just kind of shrug our
shoulders, request delisting, and (eventually... maybe) get delisted and
move on, never solving the "spam" issue.

Back in the day, the AOL feedback loop worked and was IMMENSELY helpful.
This was probably back before a lot of outgoing mail monitoring and
filtering was in place on our systems.  But it was definitely helpful when
we would get a sudden barrage of AOL FBL messages from a certain IP
address, and we knew then to stop everything and really investigate the
activity happening on that server.  This was back when AOL was probably a
more major player in the Email Service Provider realm, it's less so now,
there's just less aol.com email addresses in use these days.  And I'm not
even sure if the AOL FBL is still there.

On Thu, Feb 25, 2021 at 12:23 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 25.02.2021 o godz. 11:53:44 Scott Mutter via mailop pisze:
> > I'll end this little soapbox rant acknowledging that I don't really have
> a
> > solution to this.  How is Microsoft supposed to know that a USER of an IP
> > address is a well-respected and legitimate individual or company and not
> a
> > spammer?  That's certainly a valid question, but just because a question
> > doesn't have an immediate answer doesn't mean it's not a relevant
> > question.  Would time be better spent trying to solve this hurdle?  If
> > real, legitimate IP address USERS could be identified then they can
> address
> > more problematic spam incidents with more details.
>
> Aren't things like FBLs, or Google's Postmaster Tools, exactly the thing
> that COULD (and IMHO should) be used for this? Can these help to identify
> the user of the IP space and provide a point of contact (hopefully not only
> for automated messages) if there's something wrong with that IP space?
> --
> 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: IP based reporting for Yahoo feedback loop gone?

[Scott Mutter via mailop]

> I don't think so. I'm primarily a datacenter operator and
> commercial-only ISP and my AUP says no spamming. As the proactive type
> that prefers to prevent spamming instead of ignoring it for profit, I do
> like to know if anyone is emitting spam from any of our IP space.
> Feedback loops based on our IP ranges help with that goal, and provide
> effective evidence of AUP violations.

> I can't do that with DKIM. Feedback loops are also faster than waiting
> for someone to email abuse@ after looking in whois, if anyone bothers to
> go that far. If my abuse@ is already in whois, then why should I not be
> allowed to request automated reporting of the same?


I think there is a subset of people that don't really understand how
widespread IP space is being shared.  That subset seems to believe that 1
IP address means 1 domain name and 1 individual.  But that's just simply
not the case.

1 IP address may be sending out mail for 500 or more domain names - each
that may have 10 to 20 email accounts.  And that means there's a lot of
mail being sent out from a single IP address that doesn't necessarily
relate to each other.  The majority of these email account owners and
domain name owners care nothing about DKIM, DMARC reports, or any feedback
loop reports.  The people that do care?  They're the ones that serve as
server administrators (i.e. have root access) to those servers.  That is
who these reports need to be aimed at.  It then becomes the server
administrator's responsibility to keep those 500 domain names or 10,000
email email accounts in line when it comes to spamming or abuse.

There also needs to be a distinction made between the "owner" of an IP
address and the "administrator" responsible for the server using that IP
address.  I don't own any of the IP addresses that are used to send out
mail from our servers, but I administer all the servers we use.  If spam is
sent from one of our servers - the IP address of one of our servers - it's
me you ultimately want to contact, not the owner of the IP address.  If you
contact the owner of the IP address - they don't have root access to the
server - they will have to filter that report down to me, for me to take
action. And whether or not if that happens or if that happens in a timely
manner is anybody's guess.

Now, it's entirely possible that I'm the one that has tunnel vision with
this... but this is how I see things.  Maybe there are a lot of folks that
host one domain name on one IP address.  Or maybe everyone on this list
owns the IP address space that they send out mail from.  I don't know.  But
I think it's at least worth an open-mind in looking at how IP address space
is used and dispersed amongst people that can actually take actionable
changes from that IP address space.

My advice would be to have a centralized database of IP addresses that
lists 1) a human contact email address (or probably a form to disguise the
actual email address) and 2) a feedback loop address (which again would be
disguised).  Force server administrators of these IP addresses to verify
these email addresses (or I suppose you could do a callback URL) once a
month to ensure that the information remains up to date.  Then when spam is
identified as being sent from an IP address it is sent to the FBL address
listed in this central database.

Back in the day, AOL had a great feedback loop system.  This system was
immensely helpful for us, because it allowed us to find spammers on our
servers very quickly.  But either that feedback loop system died off or AOL
diminished in use (I suspect the latter).  Microsoft is suppose to have the
JMRP that was supposed to be similar, but I never found it useful - I very,
very rarely ever got anything from those reports, yet our servers would get
blocked by Microsoft - and it was a hassle to sign up for (again the
distinction between OWNER of the IP address and ADMINISTRATOR of the server
using the IP address).  Google also allegedly has a feedback loop system -
but I've never, ever received anything in that system, I'm guessing maybe
we don't have the volume of mail to gmail to register for this?

The bottom line is that the IP address is the only thing that is common
throughout the whole email infrastructure when it comes to identifying
abuse.  Every email message received, every spam message received, was sent
to the recipient's server by another server with an IP address.  So that's
the structure that makes sense for identifying where abuse is coming from.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IP based reporting for Yahoo feedback loop gone?

[Scott Mutter via mailop]

There was once an IP based one?

I only ever knew of the DKIM one.  Which never made a lot of sense to me -
since with shared hosting there can be multiple domains sending mail from
an IP.  To configure DKIM and the DKIM feedback loop for every domain
wasn't practical.



On Mon, Dec 28, 2020 at 11:29 AM Seth Mattinen via mailop 
wrote:

> On 12/28/20 9:28 AM, Marco Guillen Barrionuevo wrote:
> > There you go
> > Yahoo! Help - Submit a Form
> > <
> https://io.help.yahoo.com/contact/index?page=contactform=en_US=Zh/BBVqXzLHlIbokbUqVWTUbuuQeXGkGnZzhKR2JQ4O6mMQdy9JSWdtWFXvjthcYCRj9bUIFfycOfG+4GOHPHoOGa8HwDO2+0kYRtTcdR8Nja5P9HWkKh3VWfS3pyu4UdjhvwG+BCvnYFl5dToDK/w===email-icon
> >
> >
>
> It asks for DKIM stuff; I need IP based.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop