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

Re: [mailop] Looking for possible mailing list hosting

[Scott Mutter via mailop]

OK... OK...

First rule about fight club, eh?

On Wed, Dec 16, 2020 at 7:13 PM Jay R. Ashworth via mailop <
mailop@mailop.org> wrote:

> - Original Message -
> > From: "Grant Taylor via mailop" 
>
> > On 12/16/20 10:21 AM, Scott Mutter via mailop wrote:
> >> Have you considered simply putting up a website and putting phpBB or SMF
> >> or some other free forum software on it?  You can set the forum to be
> >> private so users have to login to see posts.
> >
> > That's a bait and switch to me.
> >
> > Web (only) forums do *NOT* offer the same functionality as mailing lists.
>
> Oh dear ghod, no.
>
> >> Honestly, I see mailing lists as a dying breed (said as I post this to a
> >> mailing list).
> >
> > That's your opinion.  One I happen to moderately disagree with.
> >
> >> A forum tends to work out better.
> >
> > That's also your opinion.  One I VEHEMENTLY disagree with.
>
> Concur with Grant here.
>
> > As someone who subscribes to, reads, and interacts with about 300
> > mailing lists and 200 newsgroups, there is no way in REDACTED that I'm
> > going to go to 500 different forums, many of which behave differently.
> >
> > For me, all 500 different lists / newsgroups come to /one/ interface
> > where I have /complete/ control over.
>
> Exactly.  Though I'm only on about 8 or so.
>
> Showoff.  :-)
>
> > Pulling from 500 different locations as opposed to 500 different
> > locations pushing to my single location is a COMPLETELY different usage
> > model.
>
> Well, devils advocate: 500 different mailing lists push to your inbox.
> :-)
>
> > Baiting me with a push and then switching to a pull model is
> > disingenuous at best.
> >
> > Don't even get me started on the UI/UX of things that I don't control.
> > --
> > Grant. . . .
> > unix || die
>
> And that's it, right there.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
> ___
> 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] Looking for possible mailing list hosting

[Scott Mutter via mailop]

Have you considered simply putting up a website and putting phpBB or SMF or
some other free forum software on it?  You can set the forum to be private
so users have to login to see posts.

Honestly, I see mailing lists as a dying breed (said as I post this to a
mailing list).  A forum tends to work out better.  It's a pull (users pull
content only if they want to receive the content) rather than a push (users
are pushed content - if they are subscribed - whether they want to or not).

On Wed, Dec 16, 2020 at 10:04 AM Dave Shevett via mailop 
wrote:

> Hey folks, maybe ya'll can help us out.  We've been running mailman on
> a set of linodes for... er, a long time.  We're having problems
> dealing with DKIM stuff, particularly with google.
>
> Does anyone know of a hosting company that uses mailman (or something
> roughly equivalent) and doesn't cost an arm and a leg?  We're a social
> community that uses the mailing list for internal dicusssions - this
> isn't customer facing stuff.
>
> We're looking at groups.io as well - any other suggestions?
>
> --
> Dave Shevett
> shev...@pobox.com
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] scam prevention

[Scott Mutter via mailop]

Good idea or not, that's a debate.

But if it did happen - be ready for the chorus of... "But it used to show
the person's name, why did it change?  Can you change it back?"

People don't respond well to change.  Even if it's for the betterment of
humankind, that's not really comprehensible.

On Tue, Dec 8, 2020 at 6:13 AM Tim Bray via mailop 
wrote:

> Hi,
>
> I'm wondering if it might be a good idea to strip all sender names from
> emails coming into our corporate email system.   To avoid a false name
> being used by a scammer.
>
> So rewrite a header like
>
> `From: Bob Smith ` to  `From: b...@example.org`
>
> Because the domain part is checked by SPF and DKIM.  The but name (Bob
> Smith) is not.
>
> Background:
>
> Some people at work fell for a scam email  where the From line was
>
> From: =?UTF-8?Q?Darren_Smith=C2=A0?= 
>
> That's a  Darren_Smith with a non breaking space on the end.
> mablecri...@gmail.com is the real scammer address.
>
> Darren Smith  (not his real name) is the Managing director of their
> employer.  And they just trusted the name, and didn't check the
> domain.   To the more experienced members of staff it was so blatantly a
> scam they just deleted it.  To the junior members, they rushed to the
> shops for amazon and google vouchers thinking they were on a special
> mission for the big boss. £1300 lost, some maybe recovered.
>
> If I stripped the name, they would have seen mablecri...@gmail.com and
> hopefully noticed sooner.
>
> Thoughts or ideas?
>
>
> --
> Tim Bray
> Huddersfield, GB
>
> ___
> 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] Effeciveness (or not) of SPF

[Scott Mutter via mailop]

> 1. You must have an SPF record in order for the big mail providers to
even think about accepting your mail (softfail seems sufficient).

> 2. It's not worth rejecting incoming mail simply because it fails
SPF.There are too many badly configured servers out there

This has been my observation as well.  You have to have an SPF record...
but because nobody apparently knows how to configure them accurately and
there's no desire to educate people ... nobody really cares what the SPF
record says.  But you've gotta have one!

Forwarders are one of the things that don't respond well to SPF.  But
honestly, it's 2020 ... why are we forwarding mail to external services?
SRS might be a bandaid for this, but isn't the easiest solution to just
tell people that forwarding mail to external servers is bad (mmkay).

For SPF to be effective, if you ask me, the -all modifier has to be used.
If you can't define a list of IP addresses where legitimate mail from your
domain is going to be coming from, then what's the point of SPF?  So a
message gets denied because you forgot to add that IP to your SPF list...
now you know to add it.


On Sun, Dec 6, 2020 at 8:03 AM Paul Waring via mailop 
wrote:

> On Sun, Dec 06, 2020 at 02:12:25PM +0100, Hans-Martin Mosner via mailop
> wrote:
> > In your experience, where does SPF really help? What are the use cases
> that I don't see in my spam-blocker tunnel vision?
>
> In my experience:
>
> 1. You must have an SPF record in order for the big mail providers to
> even think about accepting your mail (softfail seems sufficient).
>
> 2. It's not worth rejecting incoming mail simply because it fails SPF.
> There are too many badly configured servers out there - one example I
> see a lot is where a company has not added their web servers to their
> SPF record, but they send out transactional emails such as password
> resets. You end up not receiving mail or trying to convince the company
> that they should fix their SPF record (to which the response is the same
> as broken TLS - "problem must be on your end as it works for us").
>
> 3. It does seem to be worthwhile having SpamAssassin take SPF failure
> into account, not as an absolute rejection but a factor which indicates
> that the mail might be spam.
>
> --
> Paul Waring
> Freelance PHP developer
> https://www.phpdeveloper.org.uk
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] AT sending messages to spam

[Scott Mutter via mailop]

Who is hosting mail for bellsouth.net ?

bellsouth.net.  10571   IN  MX  10
ff-ip4-mx-vip2.prodigy.net.
bellsouth.net.  10571   IN  MX  10
al-ip4-mx-vip2.prodigy.net.
bellsouth.net.  10571   IN  MX  10
al-ip4-mx-vip1.prodigy.net.
bellsouth.net.  10571   IN  MX  10
ff-ip4-mx-vip1.prodigy.net.

Is bellsouth's mail handled by Verizon?  That'd be weird.

Have to assume that bellsouth.net's email is being handled by AT, since
bellsouth's MX records and AT's MX records are the same

att.net.14400   IN  MX  5 ff-ip4-mx-vip2.prodigy.net
.
att.net.14400   IN  MX  5 al-ip4-mx-vip1.prodigy.net
.
att.net.14400   IN  MX  5 ff-ip4-mx-vip1.prodigy.net
.
att.net.14400   IN  MX  5 al-ip4-mx-vip2.prodigy.net
.



On Fri, Dec 4, 2020 at 3:53 PM Marcel Becker 
wrote:

>
> On Fri, Dec 4, 2020 at 12:13 PM Scott Mutter via mailop 
> wrote:
>
>> Anybody from AT able to contact me off list concerning an issue with
>> messages sent from our server (192.158.238.23) to AT related email
>> addresses and being delivered into their spam folder?
>>
>>
> That highly depends on which domain you are sending to. Most consumer
> domains are not hosted by ATT but by us.
>
> Also remember that there are other reasons why emails might be delivered
> to an individual's spam folder, which have nothing to do with your
> reputation.
>
> Cheers,
> Marcel
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] AT sending messages to spam

[Scott Mutter via mailop]

Anybody from AT able to contact me off list concerning an issue with
messages sent from our server (192.158.238.23) to AT related email
addresses and being delivered into their spam folder?

I'm not seeing any issues with the 192.158.238.23 IP address. No
blacklistings or reputation issues.

Messages are being accepted by AT's mail server with:

250 2.0.0 0B4ILrFv023967 Message accepted for delivery

But going into the recipient's spam folder and we do not know why.

Any assistance would be appreciated.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Support Ticket Form not working

[Scott Mutter via mailop]

Was using FireFox with NoScript.

Tried Chrome with no extensions - same problem.

On Wed, Nov 11, 2020 at 12:09 PM L. Mark Stone <
mark.st...@missioncriticalemail.com> wrote:

> Hi Scott,
>
> In my experience, if you have uBlock Origin, Ad Block Plus or similar
> ad/tracker blocker plugins/extensions installed in your browser, you will
> get that result.
>
> I've had to turn off all that stuff on that site for the captcha
> completion and form submission to work.
>
> Hope that helps,
> Mark
> ___
> *L. Mark Stone, Founder*
>
> *North America's Leading Zimbra VAR/BSP/Training Partner*
> *For Companies With Mission-Critical Email Needs*
> *Need more email security & compliance? Ask me about Mimecast!*
>
>
>
> --
> *From: *"Scott Mutter via mailop" 
> *To: *mailop@mailop.org
> *Sent: *Wednesday, November 11, 2020 11:46:53 AM
> *Subject: *[mailop] Microsoft Support Ticket Form not working
>
> Not necessarily a mailing issue - although, I do have an issue with
> Microsoft blocking one of our IPs and I'm not able to submit a ticket, so
> perhaps loosely a mailing issue.
>
> The Microsoft form linked to at:
>
> http://go.microsoft.com/fwlink/?LinkID=614866
>
> Does not appear to be working.
>
> When I fill it out and complete the captcha (is this case sensitive?  Hard
> to tell what is capital letters and what is not) I get the error:
>
> We're sorry, but something went wrong on our end. Please try again later
>
> Tried multiple times to no avail.
>
> This is not the first time I've encountered this problem.  Seems that this
> form stops working quite a lot.
>
> ___
> 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] Microsoft Support Ticket Form not working

[Scott Mutter via mailop]

Not necessarily a mailing issue - although, I do have an issue with
Microsoft blocking one of our IPs and I'm not able to submit a ticket, so
perhaps loosely a mailing issue.

The Microsoft form linked to at:

http://go.microsoft.com/fwlink/?LinkID=614866

Does not appear to be working.

When I fill it out and complete the captcha (is this case sensitive?  Hard
to tell what is capital letters and what is not) I get the error:

We're sorry, but something went wrong on our end. Please try again later

Tried multiple times to no avail.

This is not the first time I've encountered this problem.  Seems that this
form stops working quite a lot.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] AT Silently discarding messages?

[Scott Mutter via mailop]

Has AT taken a page out of Microsoft's handbook and started silently
discarding messages even after their mail server has accepted them?

I've got a user that claims he's not getting our messages.  I checked our
outbound logs and the messages are showing as being accepted by AT's mail
servers - 144.160.235.144 - but the user is claiming they don't have the
message.

C="250 2.0.0 09SJYi67108691 Message accepted for delivery"

They say they have checked their spam folder as well.

I know Microsoft is famous for pulling this stunt.  I guess everybody's
wanting a piece of this pie?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any chance that Microsoft would tell it's customer that the 'junk' folder creates complaints?

[Scott Mutter via mailop]

> Maybe they should name it, "Unwanted mails you want to be reported"

I would second this.  Maybe a little more simple.  "Report as Junk" or
"Report as Spam".

Although I don't have the highest level of confidence in end-users reading
or knowing word meanings - so I'm not sure if it will really make a
difference. But the keyword "Report" would seem to me to indicate that an
additional action is going to happen if you put a message in this folder.
It would at least give fodder for the inevitable "what did you think was
going to happen when you put our message in your 'Report as Junk' folder?"
question when asked to the user.

Other large email service providers should also probably adopt this
language as I suspect their "Junk" or "Spam" folder does the same thing.



On Thu, Sep 24, 2020 at 4:22 AM Renaud Allard via mailop 
wrote:

>
>
> On 9/24/20 11:13 AM, Jaroslaw Rafa via mailop wrote:
> > Dnia 24.09.2020 o godz. 10:25:00 Thomas Walter via mailop pisze:
> >> BTW - "Spam" also is a bad name for those folders, because the word now
> >> seems to be a catch-all phrase for "E-Mails I do not like".
> >
> > But definitely better than "Junk". "Junk" doesn't bring - at least for
> me -
> > even that association of "E-mails I don't like".
> >
>
> Maybe they should name it, "Unwanted mails you want to be reported"
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Cloudmark Blacklist

[Scott Mutter via mailop]

Anybody from CloudMark able to contact off list?

Or how long does it generally take to get a response from CloudMark?

Sent a request at https://csi.cloudmark.com/en/reset on Sunday - clicked
the link in the Confirm CSI IP Address Statistics Reset Request email - and
the IP is still blocked and I haven't received anything else from CloudMark.

Perhaps this is normal.

I hate using mailops as a blacklisting soundboard but seems that it's the
only way to contact some of these blacklisting groups.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] STARTTLS - Constant Contact and yahoo.co.jp

[Scott Mutter via mailop]

Well, I really just wanted to see what the rest of the community was doing
in regards to this.  Seems the resounding answer is a "prefer TLS, but
don't disqualify if no TLS" or "opportunistic" TLS.

However, experience has also taught me, if you don't force people to make
changes then they're not going to change.  In regards to that, maybe this
never becomes an issue.  But if the point is to go all TLS all the time,
you're going to have to publicly shame those that are dragging their feet
or just cut off communication with them entirely.  Maybe some of the
administrators to these mail servers don't realize that their mail servers
aren't handling STARTTLS and bringing awareness to that (in the form of
their users not receiving all of their emails) is a way to light a fire
under them.

I just wanted to gauge what other mail server administrators were doing in
regards to this.  The response is kind of what i expected, but the shift in
wanting TLS and encryption on every connection, kind of made me question
what the response would be.

On Wed, Aug 26, 2020 at 3:02 PM Michael Orlitzky via mailop <
mailop@mailop.org> wrote:

> On 2020-08-26 12:50, Scott Mutter via mailop wrote:
> > I've been toying with the idea of forcing outbound SMTP connections to
> > use TLS, but thought I'd take a quick look and see who might miss mail
> > if this done.
>
> This sounds good at first but if you make a flow chart, all paths lead
> to either "nothing changes" or "shoot yourself in the foot." There's no
> scenario that I know of where forcing TLS (as opposed to "opportunistic"
> TLS) improves anything.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] STARTTLS - Constant Contact and yahoo.co.jp

[Scott Mutter via mailop]

How many mail operators out there are forcing outbound SMTP communications
to use TLS?  Is this a common practice now?  I know secure everything and
TLS everywhere is a popular movement at this moment.

I've noticed that Constant Contact (constantcontact.com - at least the mail
server at 205.207.104.108) and yahoo.co.jp (67.195.204.74) don't appear to
be accepting STARTTLS.  Is that strange?

yahoo.com appears to handle STARTTLS but yahoo.co.jp does not.  There may
be other country/region specific Yahoo domains that don't.

I'm just wondering if that is common.  Perhaps the administrators of these
mail servers are unaware of this?  Constant Contact - whose primary purpose
would seem to be to insure mail delivering - not accepting STARTTLS seems
extremely strange.

I've been toying with the idea of forcing outbound SMTP connections to use
TLS, but thought I'd take a quick look and see who might miss mail if this
done.  It looks like most mail servers handle TLS, I haven't extended this
test to a lot of servers yet so it may just be that the mail servers I have
enacted this on are small volume senders.

I should note, forcing TLS is different from preferring TLS.  I think a lot
of MTAs (at least Exim, I think?) prefer TLS and will attempt to negotiate
a STARTTLS session, but if that fails, then it will continue without TLS.
By forcing TLS, I'm telling my server to close the connection if a STARTTLS
session can't be started.  Are any other mail server admins doing this?  Or
is it still too early to require this?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Microsoft Block list (S3150)

[Scott Mutter via mailop]

Maybe the answer is that not enough other mail server administrators are
shining a light on just how poorly Microsoft (and any other big named
provider) does in regards to incidents like this.

In my particular case at the moment, Microsoft is blocking one of our mail
server IPs.

Microsoft has not provided any evidence that anything bad has ever come
from this IP address.  (Which the pros/cons of disclosing this have already
been discussed)

The IP is not listed on any other public spam blacklist.

The IP has a Senderscore of 99 - which I think still means something?

All-in-all I'm just not seeing why Microsoft is blocking the IP.  Show me
some proof and I'll believe you.

Outside of that, what am I suppose to do to resolve whatever that issue
might be?  Since you won't tell me what the issue is.  I guess you just
want us to lie on the ticket replies and say "We've resolved these issues"
even though I didn't do anything.  This is how the problem just keeps
snowballing into larger and larger problems.

Now is the IP blocked because of a larger class-C, class-B, or some subnet
block?  That'd be nice to know.  But even if it is, if you're not seeing
any activity from the specific IP address I'm referring to, why can't you
just whitelist that IP from the subnet block?

It's impossible to get a hold of anyone using Microsoft website contact
form links that knows a lick about how their own mail servers work.  If you
tell them that you're IP is blocked they try to figure out why you can't
access http://outlook.com

All the while, our users see us as being the bad guys.  They don't believe
that Microsoft/Hotmail/Outlook can be a bad guy because they're too big.  I
would be half a good mind to tell our users to sign up for this Mailops
mailing list, just so they can read all of the horror stories that happen
with Microsoft/Hotmail/Outlook mail server blocks.

On Mon, Jun 29, 2020 at 2:57 PM Hans-Martin Mosner via mailop <
mailop@mailop.org> wrote:

> Am 29.06.20 um 21:30 schrieb Michael Wise via mailop:
>
>
>
> A **VERY** strong economic argument.
>
>
>
> I know. I'm mainly venting my frustration, knowing too well that my
> activity won't flip a single bit in Redmond.
>
> Hoping that some organization would do the right thing because it's the
> right thing to do has become pretty futile (not saying that there ever was
> much hope...)
>
> Cheers,
> Hans-Martin
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Block list (S3150)

[Scott Mutter via mailop]

Might I also suggest that Microsoft needs a form or chat on their website
where other email server administrators can submit to
Microsoft/Hotmail/Outlook mail server administrators.

I keep getting on chat explaining that Microsoft/Hotmail/Outlook is
blocking one of our mail server IPs, and I keep getting responses "So,
you're using the outlook.com website, correct?"

The people that you get lucky enough to talk to at Microsoft have no clue
how Microsoft/Hotmail/Outlook's mail servers actually work.  They can help
you click buttons, but that's about it.



On Mon, Jun 29, 2020 at 11:13 AM Al Iverson via mailop 
wrote:

> SNDS and JMRP are not dead.
> We're receiving 35k-45k JMRP complaints daily.
> We've got many hundreds of clients signed up for and accessing the
> SNDS reputation data portal daily.
> SNDS is buggy in places, but it's not dead.
>
> Cheers,
> Al Iverson
>
>
> --
> Al Iverson // Wombatmail // Chicago
> Song a day! https://www.wombatmail.com
> Deliverability! https://spamresource.com
> And DNS Tools too! https://xnnd.com
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Block list (S3150)

[Scott Mutter via mailop]

> For weeks I haven't been able to submit the form to remove RBLs -- each
time it says (regardless of browser):
> "We're sorry, but something went wrong on our end. Please try again later"
> Anyone else experienced that?

Same here.  See my post to this list from June 10th - Subject: "Hotmail -
New Support Request form not working?"

On Mon, Jun 29, 2020 at 7:13 AM Sam Tuke via mailop 
wrote:

> On 27/06/2020 5:54 am, Tim Bray via mailop wrote:
> > On 24/06/2020 23:03, Al Iverson via mailop wrote:
> >> Yep, fill out this
> >> form:http://go.microsoft.com/fwlink/?LinkID=614866
>
> For weeks I haven't been able to submit the form to remove RBLs -- each
> time it says (regardless of browser):
>
> "We're sorry, but something went wrong on our end. Please try again later"
>
> Anyone else experienced that?
>
> Sam.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [External] Re: Microsoft Block list (S3150)

[Scott Mutter via mailop]

JMRP never reported anything for me.  Admittedly it has been several years
since I signed any of our IPs up for it.  But when I was signed up, we'd go
through stretches where the IP would be blocked but nothing ever came
through JMRP.  That's why I quit signing up IPs for it - didn't see much
reason to.  I mean, what good does it do to sign up for a reporting service
that is suppose to alert you to abuse, when IPs are blocked without any
reports?


On Mon, Jun 29, 2020 at 6:52 AM Kevin A. McGrail via mailop <
mailop@mailop.org> wrote:

> The SNDS/JMRP program used to.  Anecdotally, the feedback loop disappeared
> with the advent of GDRP and/or CCPA early this year.
>
> Regards,
> KAM
> On 6/29/2020 7:16 AM, Laura Atkins via mailop wrote:
>
> On the advice of their lawyers Microsoft doesn’t share that information
> with senders.
>
> laura
>
>
>
> On 29 Jun 2020, at 06:18, Esteban Fonseca via mailop 
> wrote:
>
> Hello all,
>
> Has anyone ever had success getting feedback from Microsoft ? Stuff like
> what caused the block, and when, things that may help you nail down the
> issue ? We've got new IPs assigned by our ISP and they were blocked since
> they were assigned to us, meaning that it was not us (my company)  who
> caused the block, but they still say the IPs don't qualify for mitigation.
>
> Thanks a lot,
> Esteban.
>
>
> On 27/06/2020 5:54 am, Tim Bray via mailop wrote:
>
>
> On 24/06/2020 23:03, Al Iverson via mailop wrote:
>
> Yep, fill out this form:http://go.microsoft.com/fwlink/?LinkID=614866
> Wait a few days for a reply.
> First reply might just be a "we're routing your ticket" response.
> Second reply might be useful, or it might be completely bonkers.
> You might have to calmly state your case repeatedly.
> They might say they see nothing wrong. Stick to your guns and show
> them the data.
> Eventually, after a number of replies, they'll say that the IP
> qualifies for mitigation and that the block will be rescinded within
> 48-72 hours.
>
>
>
> And this process does work.   Takes a few days and a few emails back and
> forwards.
>
> Our corporate email server IPv4 address got blocked at hotmail recently.
> Nothing received from the junk mail reporting system.
>
> It is slightly frustrating, because I'd like to know what we did wrong.
> I'd be the first to change something if we were.
>
> Maybe we did nothing wrong and just tripped a rate limit, filter or
> keyword or something.
>
> Tim Bray
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
>
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> --
> *Kevin A. McGrail*
> CEO Emeritus
>
> Peregrine Computer Consultants Corporation
> 10311 Cascade Lane
> Fairfax, VA 22032
>
> http://www.pccc.com/
>
> 703-359-9700 / 800-823-8402 (Toll-Free)
> 703-798-0171 (wireless)
> kmcgr...@pccc.com 
>
> https://www.linkedin.com/in/kmcgrail
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Block list (S3150)

[Scott Mutter via mailop]

> On the advice of their lawyers Microsoft doesn’t share that information
with senders.

And I understand the reasons for that.  But... can't you see how this turns
into a "he said / she said" argument?

Microsoft: "Your IP sent us spam, so we're blocking you."
Mail Server Admin: "I don't see any spam being sent, I don't see the IP on
any other blacklisting, can you prove it?"
Microsoft: "Uh... no... we can't detail that information - you just have to
trust us."
Microsoft: "Oh, and by the way, we're ignoring you now... so brownie points
for the whole trust thing!"

I guess if you block all incoming traffic on port 25 to your mail
servers... you're pretty much going to be guaranteed to stop all of your
users from receiving spam.

On Mon, Jun 29, 2020 at 6:16 AM Laura Atkins via mailop 
wrote:

> On the advice of their lawyers Microsoft doesn’t share that information
> with senders.
>
> laura
>
>
>
> On 29 Jun 2020, at 06:18, Esteban Fonseca via mailop 
> wrote:
>
> Hello all,
>
> Has anyone ever had success getting feedback from Microsoft ? Stuff like
> what caused the block, and when, things that may help you nail down the
> issue ? We've got new IPs assigned by our ISP and they were blocked since
> they were assigned to us, meaning that it was not us (my company)  who
> caused the block, but they still say the IPs don't qualify for mitigation.
>
> Thanks a lot,
> Esteban.
>
>
> On 27/06/2020 5:54 am, Tim Bray via mailop wrote:
>
>
> On 24/06/2020 23:03, Al Iverson via mailop wrote:
>
> Yep, fill out this form:http://go.microsoft.com/fwlink/?LinkID=614866
> Wait a few days for a reply.
> First reply might just be a "we're routing your ticket" response.
> Second reply might be useful, or it might be completely bonkers.
> You might have to calmly state your case repeatedly.
> They might say they see nothing wrong. Stick to your guns and show
> them the data.
> Eventually, after a number of replies, they'll say that the IP
> qualifies for mitigation and that the block will be rescinded within
> 48-72 hours.
>
>
>
> And this process does work.   Takes a few days and a few emails back and
> forwards.
>
> Our corporate email server IPv4 address got blocked at hotmail recently.
> Nothing received from the junk mail reporting system.
>
> It is slightly frustrating, because I'd like to know what we did wrong.
> I'd be the first to change something if we were.
>
> Maybe we did nothing wrong and just tripped a rate limit, filter or
> keyword or something.
>
> Tim Bray
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Block list (S3150)

[Scott Mutter via mailop]

I'm definitely agitated with Microsoft/Hotmail/Live/Outlook at the moment
regarding an IP block.  But I'll also agree that I can see their point and
reason for being strict with their blocks.  They don't really care if
they're blocking legitimate mail from small time email servers.

But the real sucky part is - we're the ones that get blamed by our
customers when Microsoft imposes such a strict block.  From our customers
point of view - Microsoft is too large of a company to do any wrong, it
can't be their fault.  I've really taken the step to just recommend folks
not to use Microsoft/Hotmail/Outlook for any of their email service because
of these strict measures and lack of communication from
Microsoft/Hotmail/Outlook.  Maybe that turns customers off, but at this
point I don't have a lot to lose - they're already pissed at us because
Microsoft is blocking our server's IP address.

On Thu, Jun 25, 2020 at 9:34 AM Adam Moffett via mailop 
wrote:

>
>
> -- Original Message --
> From: "Michael Rathbun via mailop" 
> To: mailop@mailop.org
> Sent: 6/24/2020 10:28:17 PM
> Subject: Re: [mailop] Microsoft Block list (S3150)
>
> >On 24 Jun 2020 21:50:13 -0400, John Levine via mailop 
> >wrote:
> >
> >>To point out the obvious, you're not their customer. Why should they
> >>care unless an actual customer complains?
> >
> >And the actual customers are the advertisers, not the persons using "free"
> >email services, and certainly not any entity sending email to those
> persons.
> >
> That's an excellent point.  It doesn't help with the blacklisting, but I
> think it drives to the point of why policy might be the way it is and
> why it might work for them as-is.  It doesn't hurt ad revenue if one of
> their users can't receive something from me, and it might help their ad
> revenue to keep the signal-to-noise ratio as high as possible.  So there
> may be an incentive on their end to be strict.
>
> I'm not saying I like it, but I think I can accept the reality of it.
>
> -Adam
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Block list (S3150)

[Scott Mutter via mailop]

That's true - I'm not a customer.  But who is a customer?  What is defined
as a customer?  Is a hotmail.com/live.com/outlook.com email user a
"customer"?  And if so... how do they contact a real live human being at
Microsoft to voice their concerns about Microsoft's unilateral IP blocking
of other mail servers?  The form referenced above is geared more towards
the administrators of those blocked servers who have to beg, plead, and
grovel for someone to remove their IP from being blocked by Microsoft.  Or
maybe you get the - "As previously stated, your IP(s) do not qualify for
mitigation at this time.  I do apologize, but I am unable to provide any
details about this situation since we do not have the liberty to discuss
the nature of the block." response even though the IP is not blocked any
where else (it has a 99 Sender Score) and wait out your time in SOL land.

Or is "customer" someone that pays for this service?

The joke has always been that hotmail.com/live.com/outlook.com/msn.com etc.
email addresses are the bottom feeders.  Because they either get inundated
with spam or Microsoft blocks the wrong IPs, holding them hostage
indefinitely and legitimate mail is not able to get sent through to these
email addresses.  When was the last time you got any correspondence from
an @hotmail.com address and thought "hey! that guy means business!"?

Just once, I'd love to get a response from Microsoft that explains why
they're the only ones blocking an IP address.  I mean, I've dealt with spam
incidents - probably much like the OP - for the past 20+ years and every
time, those spam messages go out to other mail servers, Yahoo, Gmail, any
of the ReturnPath users, Proofpoint, CBL - every where.  If a spam incident
is so unbelievably bad that it can never, ever be mitigated... it stands to
reason that the IP would show up in one of these other systems.  But if it
doesn't, and Microsoft is the only one blocking it... what does that tell
you?


On Wed, Jun 24, 2020 at 8:50 PM John Levine via mailop 
wrote:

> In article  glr4dc1zxleb6z6b+j2tjg+qzqpfmtcgji...@mail.gmail.com> you write:
> >
> >You would think a company like Microsoft would have a better solution to
> >all of this.
>
> To point out the obvious, you're not their customer. Why should they
> care unless an actual customer complains?
>
> R's,
> John
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Block list (S3150)

[Scott Mutter via mailop]

You would think a company like Microsoft would have a better solution to
all of this.

Once you get blocked by Microsoft it's a 6 week race (because they'll only
reply about once a week) to plow through all of the crud replies they send
you, to actually getting something accomplished.  Except, after 6 weeks all
of your clients have left you, so it's kind of pointless.

Factor in also that they tend to block IPs for no apparent reason.  I'd be
curious to know if your IP address is listed with any other major
blacklisting services, SpamHaus, Spamcop, etc.  Or did your abuse incident
only send spam out to Microsoft controlled email servers?

On Wed, Jun 24, 2020 at 5:03 PM Al Iverson via mailop 
wrote:

> Yep, fill out this form: http://go.microsoft.com/fwlink/?LinkID=614866
> Wait a few days for a reply.
> First reply might just be a "we're routing your ticket" response.
> Second reply might be useful, or it might be completely bonkers.
> You might have to calmly state your case repeatedly.
> They might say they see nothing wrong. Stick to your guns and show
> them the data.
> Eventually, after a number of replies, they'll say that the IP
> qualifies for mitigation and that the block will be rescinded within
> 48-72 hours.
> And that might even be true!
>
> Good luck.
>
> Cheers,
> Al Iverson
>
> On Wed, Jun 24, 2020 at 4:28 PM Adam Moffett via mailop
>  wrote:
> >
> > Does anyone have any insight into how we get onto (or off) a Microsoft
> block list?
> >
> > I started seeing these bounces around midnight on Tuesday:
> >
> > "550 5.7.1 Unfortunately, messages from [204.80.232.21] 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. "
> >
> > We don't have any current issues, but on Monday morning we did have a
> compromised customer account send 200 spam emails. 200 triggered a limit
> and they couldn't send any more.  Later in the morning we disabled the
> compromised account.  This would have been about 18 hours before we started
> seeing the bounces shown above.  I'm assuming this is related, but I don't
> know how I could have addressed the issue any faster, and I don't know why
> there would be such a delayed reaction from Microsoft's system.
> >
> > Does anyone know anything of interest about this?
> >
> >
> > -- Adam Moffett, Network Engineer
> > Plexicomm - Internet Solutions | www.plexicomm.net
> > Office: 1.866.759.4678 x104
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
> --
> Al Iverson // Wombatmail // Chicago
> Song a day! https://www.wombatmail.com
> Deliverability! https://spamresource.com
> And DNS Tools too! https://xnnd.com
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [EXTERNAL] Hotmail - New Support Request form not working?

[Scott Mutter via mailop]

Scott Mutter
4:20 PM (0 minutes ago)
to *mailop*
Well... What does Parked Domains mean in this context?

Why does that really matter?

How can I dictate what Talos puts on their website concerning this IP
address?

The Email reputation on Talos is Good.  All of the surrounding IPs are
either Good or Neutral.  I don't have any control over the surrounding IP's
either.

This IP address -  191.101.16.96 - is a shared hosting server.  Shared
Hosting, if you're not familiar with it, takes a server and hosts many
different websites across different VirtualHosts (with the glorification of
HTTP v1.1 and SNI).  And as a result we also have many different domain
names that send out mail from this IP.  Can I vouch for all of the accounts
on the server and say that they aren't sending out spam?  No, I really
can't.  But I can tell you that I'll do everything possible to identify and
remove any spam sources on the server.  We have spamming events on
different servers from time to time.  Most of these are tied almost
exclusively to people using really stupid passwords.  But typically if a
spamming event happens, it's going to show up through multiple blacklists
(SpamHaus, Spamcop, etc), Sender Score, Proofpoint, etc.  I'm not seeing
that with this IP address now.  Could something have slipped through the
cracks?  Sure... anything's possible.  That's why I need Hotmail's help...
tell me why you think this IP is sending you spam... then I can take
measures to identify that source and resolve it.  If I never know why
Hotmail (and thus far, only hotmail.com, live.com, outlook.com, and
msn.com email
addresses are having issues) then how am I suppose to identify the source
of the issue?  From my perspective this looks more like Hotmail being
overly aggressive with it's IP blockings.

On Wed, Jun 10, 2020 at 4:02 PM Michael Wise 
wrote:

>
>
> The issue is, in part, your, “Neighborhood”.
>
>
>
> https://talosintelligence.com/reputation_center/lookup?search=191.101.16.96
>
>
>
> There’s one phrase that probably helped start the problem, referenced on
> that page:
>
>
>
> [image: A screenshot of a cell phone Description automatically generated]
>
>
>
> Hopefully someone will be getting to that issue on our site soonest.
>
> Good luck.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Open a ticket for Hotmail <http://go.microsoft.com/fwlink/?LinkID=614866>
> ?
>
>
>
> *From:* mailop  *On Behalf Of *Scott Mutter
> via mailop
> *Sent:* Wednesday, June 10, 2020 1:32 PM
> *To:* mailop@mailop.org
> *Subject:* [EXTERNAL] [mailop] Hotmail - New Support Request form not
> working?
>
>
>
> I know there's a guy that frequents this mailing list from Microsoft.
> Apologies if this isn't really Mailops worthy... but Microsoft is one of
> those great companies that's just really, really, really hard to get a hold
> of a human.
>
>
>
> I'm not able to get the support request form at:
>
>
>
>
> https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fsupportrequestform%2F8ad563e3-288e-2a61-8122-3ba03d6b8d75=02%7C01%7Cmichael.wise%40microsoft.com%7C916f9264c7854b5ff74f08d80d7e06b6%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637274182650419670=mMJ%2F9yjGEdkcz%2FHqTUrksqfrRtz96psSk8tBNGWZrZA%3D=0>
>
>
>
> to work.  It keeps kicking back:
>
>
>
> We're sorry, but something went wrong on our end. Please try again later
>
>
>
> Now, I've always had trouble with the captcha on this form - it always
> takes a dozen or so attempts to get the captcha right (is that an O or a
> 0?  a k or K?  a  v or a V?).  But I'm thinking the error is different when
> it kicks it out because of captcha.  At any rate, I've tried filling out
> the captcha a couple of dozen times to no avail.
>
>
>
> Is there a better way to dispute a Hotmail IP block?  It would also be
> IMMENSELY helpful if they could ever tell me why Hotmail is blocking an
> IP.  The same song and dance of: submit form, wait 3 days, be told it
> doesn't qualify for remediation, reply back, wait 3 days, and then finally
> be told that it qualifies for conditional mitigation.
>
>
>
> The specific IP in question here is:
>
>
>
> 191.101.16.96
>
>
>
> I've checked everything I know to check - public blacklists, Symantic,
> Proofpoint, Senderbase, Senderscore - all show this IP being fine.  But
> Hotmail is blocking the IP:
>
>
>
> 550 5.7.1 Unfortunately, messages from [191.101.16.96] weren't sent.
> Please contact

[mailop] Hotmail - New Support Request form not working?

[Scott Mutter via mailop]

I know there's a guy that frequents this mailing list from Microsoft.
Apologies if this isn't really Mailops worthy... but Microsoft is one of
those great companies that's just really, really, really hard to get a hold
of a human.

I'm not able to get the support request form at:

https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75

to work.  It keeps kicking back:

We're sorry, but something went wrong on our end. Please try again later

Now, I've always had trouble with the captcha on this form - it always
takes a dozen or so attempts to get the captcha right (is that an O or a
0?  a k or K?  a  v or a V?).  But I'm thinking the error is different when
it kicks it out because of captcha.  At any rate, I've tried filling out
the captcha a couple of dozen times to no avail.

Is there a better way to dispute a Hotmail IP block?  It would also be
IMMENSELY helpful if they could ever tell me why Hotmail is blocking an
IP.  The same song and dance of: submit form, wait 3 days, be told it
doesn't qualify for remediation, reply back, wait 3 days, and then finally
be told that it qualifies for conditional mitigation.

The specific IP in question here is:

191.101.16.96

I've checked everything I know to check - public blacklists, Symantic,
Proofpoint, Senderbase, Senderscore - all show this IP being fine.  But
Hotmail is blocking the IP:

550 5.7.1 Unfortunately, messages from [191.101.16.96] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3140). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. [
VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com]
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AT Block - abuse_...@abuse-att.net still valid?

[Scott Mutter via mailop]

I really wouldn't think TTL would be a determining factor - at least if it
is I'd argue against it being such.  Do any DNS resolvers actually cache
data for the period stated in the TTL these days?  Too long of a TTL, I
think resolvers will flush it out before then anyway.  Maybe 900 is too
short, but I'd argue that looking at TTL isn't a good way to determine
spammyness.

If you look at gmail.com it's TTL is 300 seconds - now... granted that IP
address is not used to actually connect to mail server to send out mail,
it's just the IP address for the front facing gmail.com.

If you look at Yahoo, one of their sending IPs - 98.137.65.31 - resolves to
sonic315-55.consmr.mail.gq1.yahoo.com. and
sonic315-55.consmr.mail.gq1.yahoo.com. has a TTL of 1800 seconds.
Obviously, 1800 is larger than 900, but enough to worry about?

I definitely would subscribe to the notion that TTL should not matter for
this.  But should and does are two different things.

On Wed, Feb 26, 2020 at 3:53 PM Lyle Giese via mailop 
wrote:

> Don't know if ATT looks at this but I know they used to.  The TTL for the
> A record for server.divebums.com is 900 seconds.  If checking this
> parameter, it was recommended that this be at least 12 hrs or 43,200
> seconds.  The theory was that 900 seconds indicated it was on a dynamic ip
> address.
>
> Good luck!
>
> Lyle Giese
>
> LCR Computer Services, Inc.
> On 2020-02-26 15:25, Scott Mutter via mailop wrote:
>
> I know this will come as a complete and absolute shock to most everyone
> here.
>
> It's been 15 days since I originally posted this on this list.  I was told
> to wait about a week to let them "weed" out all of the clutter AT likely
> gets from this abuse address... so I waited 2 weeks.
>
> The shocking part... it's still blocked.  And I haven't received a peep
> from AT other than the canned response I got on February 10th (16 days
> ago).
>
> So basically all I've done is wasted 16 days waiting for a response or
> resolution.
>
> And yet people wonder why I have zero faith in the way any of these "big"
> mail providers address disputes to their clandestine blacklisting and
> blocking process.
>
> Am I suppose to wait another decade or two for a response or resolution
> from AT regarding this?
>
> For what it's worth - the IP address in this particular case
> is 192.158.224.5 - I would very much love for someone to tell me what is
> wrong with this IP address and why AT is blacklisting it.  What services
> do you all recommend to go to to check the reputation of a mail server's IP
> address?  I've been using Senderscore, Senderbase, Proofpoint, Symantec,
> Spamhaus, Spamcop - this IP address comes up clean at all of those places -
> but I guess those aren't good sources to double check with?
>
> I'm open to suggestions on how I'm suppose to handle this and what I need
> to do to resolve this.  Apparently checking the IP's reputation at those
> sites isn't good enough.  And apparently sending an email to
> abuse_...@abuse-att.net is not good enough.
>
>
>
> On Tue, Feb 11, 2020 at 9:50 AM Scott Mutter via mailop 
> wrote:
>
>> Anybody from AT able to check a couple of abuse tickets for me?
>>
>> AT is blocking one of our servers, I sent messages on February 8th and
>> February 10th to abuse_...@abuse-att.net but have not heard anything
>> back - other than the canned response - and the IP is still blocked.
>>
>> The rejection notice says to email abuse_...@abuse-att.net but I'm not
>> sure if that is still valid.
>>
>> Ticket numbers are:
>>
>> 020820-180048-39537-00
>> 021020-164333-46154-00
>>
>> I suppose it's possible that AT is just inundated with abuse requests -
>> but maybe there is a better way to weed out the valid requests from the
>> invalid requests.
>>
>> If abuse_...@abuse-att.net is no longer valid, then perhaps the
>> rejection notice needs to be updated.
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop