[mailop] verifier.port25.com

[Blake Hudson via mailop]

Looks like the email verification application at verifier.port25.com 
described in this 
(https://postmarkapp.com/blog/port25s-authentication-and-spam-assassin-tool) 
article may have been shut down.


Anyone have any insight into this or alternative tools for testing DKIM, 
SPF, and similar in one go?


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

Re: [mailop] Interesting fallout from the FaceBook outage?

[Blake Hudson via mailop]

Matt, I would bet good money that you are correct. FB and instragram 
logos (and tracking) are widespread across a number of websites that 
otherwise have nothing to do with FB, other than that they want visitors 
to "follow" or "like" them. I'm sure there's a lot of DNS/Web traffic 
looking for FB even when a human isn't directly browsing FB's website or 
app.



On 10/8/2021 9:13 AM, Matt Gilbert via mailop wrote:

I wonder if the jump in DNS traffic was due to all the websites out there that 
have Facebook analytics tracking or other Facebook widgets installed. Then 
add-in all the mobile devices that have the Facebook app and other apps that 
include Facebook tracking. All that combined would be a lot of clients trying 
to resolve Facebook.com.


Regards,

Matt Gilbert
Deliverability Engineer - Mailchimp
matthew.gilb...@mailchimp.com




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

Re: [mailop] Interesting fallout from the FaceBook outage?

[Blake Hudson via mailop]

On 10/7/2021 1:39 PM, Bill Cole via mailop wrote:

On 2021-10-07 at 14:13:33 UTC-0400 (Thu, 07 Oct 2021 13:13:33 -0500)
Jarland Donnell via mailop 
is rumored to have said:

It seems quite plausible. I still had a couple of small servers only 
running 8.8.8.8/8.8.4.4 and during the event I had trouble 
consistently performing SPF/DKIM verifications on those systems. The 
ones running several different resolvers were fine. Cloudflare seems 
to have hit the nail on the head with the increased DNS traffic 
causing intermittent timeouts with the most popular resolvers, which 
went as far as having my home internet nearly down until I figured 
out the cause.


Honestly, I wasn't expecting that impact. The far reaching fallout of 
a single domain no longer resolving was something more than a few of 
us weren't prepared for.


It is also the consequence of the risky pattern of increasing 
concentration of DNS resolution. The only reason the big free public 
resolvers had this sort of problem is that they are big, free, and 
public. The only end users that had problems with DNS beyond FB's 
domains were users of resolvers that attempt to serve very large 
audiences, i.e. mostly just the big free public resolvers.


To add another datapoint, I admin a number of resolvers for eyeball 
networks. These resolvers receive a few hundred queries per second up to 
a few thousand queries per second. And while they all saw increases in 
query (and recursion) volume while FB was down, that increase wasn't 
concerning (some see more total query volume during their nightly peaks 
or other regular usage than during the FB outage). None of our resolvers 
had issues answering clients.


I agree with Bill that what we saw with DNS resolution outside of FB 
properties was probably a consequence of DNS concentration to fewer 
entities (and the robustness of the service provided by those entities). 
I take issue with the Op's wordings like "global DNS instability", 
"global DNS issues", and "the widespread DNS issue" when it seems DNS 
resolution issues (beyond FB's properties) were limited to a few 
providers, namely CloudFlare's 1.1.1.1 DNS service and Google Public DNS 
service (but not ruling out other isolated DNS resolvers). Yes they are 
big, and an outage of their services can/does generate a lot of noise, 
but Google does not own and operate the entire DNS (just a large chunk 
of it). If Google were to leave the DNS, it would not make the DNS unstable.


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

Re: [mailop] SPF prevents enabling IPv4+IPv6?

[Blake Hudson via mailop]

Just my own data point, but I've never been a fan of hostnames in my SPF 
records. The majority of my SPF records list a single ip4: range and a 
single ip6: range; this covers dual stack servers just fine. A handful 
of the SPF records I manage may have a couple v4 or v6 ranges. Very few 
of my SPF records list hostnames or use the include: function. These are 
usually added at the request of customers that make use of a third party 
advertising or mailing list service or similar and I try to throw these 
in at the end of the SPF record.


As others have mentioned, IPv6 is a different animal for email 
deliverability. My experience is that you'll want to implement SPF 
and/or DKIM before attempting to use IPv6 to deliver email. Even then, 
you're likely to see the majority of email on a dual stack server still 
being delivered over v4 - even for major destinations - so adding v6 
does add complexity and doesn't gain you much (if anything) as far as 
outbound email goes.


--Blake

On 3/1/2021 7:45 AM, Otto J. Makela via mailop wrote:

...

I believe in practical terms this means, no sensible service provider
would ever switch over to using a dual-protocol IPv4+IPv6 email hosts,
since your emails might not go through in tricky-to-debug ways.

I doubt SPF was intended to cause this side effect.
I guess wiser minds than me already figured all this out?



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

Re: [mailop] When RBLs go bad

[Blake Hudson via mailop]

On 2/14/2021 10:00 AM, Chris via mailop wrote:

On 2021-02-14 01:42, André Peters via mailop wrote:
...

2) Securi.net used mxtoolbox.  It has problems of its own of 
synthesizing it's own queries, and jumping to conclusions and 
misleading you.  For example, if you do a domain lookup, you can end 
up with assertions you're listed in IP-only DNSBLs which have nothing 
to do with you.


I personally prefer to use this for straight and 
uncomplicated/non-misleading results:



http://multirbl.valli.org/lookup/192.124.249.6.html


Which lists some 9 listings for the IP.  Now of course most of the 
DNSBLs listing it are trivial, not used much, or largely ignored (like 
RFC Ignorant), there are at least two that do seem indicate that they 
HAVE seen email traffic from that specific IP. So something seems to 
be awry with their assertion it can't make outbound connections.


- If I had a nickel for everyone who insisted that their IP can't send 
email, when I have spam sample in my hand proving otherwise, I'd have 
retired long ago, or at least be a few dozen cases of beer richer.


Even tho it's Securi.net, I'd prefer to see them at least expending 
the effort to see if anything *is* emitting from that IP rather than 
just asserting it.  It wouldn't the first time that network hardware 
got infected, or a network operator got outsmarted.


This was my first thought. The article's author states that his server 
doesn't accept [incoming] connections on port 25 and somehow interprets 
this as though the server therefore could not possibly send [outbound] 
mail on port 25. This is obviously false. A form on a website, a command 
line script, a malicious binary, etc could all certainly send email 
messages on a system that's not listening on port 25 (or has incoming 
connections to port 25 blocked). While remote, there's also a 
possibility of IP hijacking or spoofing - more likely when you're just 
talking about port scanning logs, less likely when you're talking about 
fully functional TCP connections.


I'm surprised the author didn't try to do any self-verification (or 
state as such) before writing an article defaming another party.

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

Re: [mailop] [EXTERNAL] Blocked from hotmail/live/outlook but ticket response says not blocked

[Blake Hudson via mailop]

On 1/6/2021 6:49 PM, Seth Mattinen via mailop wrote:

On 1/6/21 16:38, Michael Wise via mailop wrote:


Can you please share at the very least, the IP in question and the 
full error message?




Well, now I just got an email that says "Not qualified for mitigation
208.79.240.5
Our investigation has determined that the above IP(s) do not qualify 
for mitigation."


And then a bunch of crap about joining JMRP and SNDS, of which I have 
been registered on for at least a decade. JMRP sent me a grand total 
of 5 reports on this issue: only 2 on the 28th, the rest after I'd 
already shut the customer off. First goddam time I've ever been 
blocked and "not qualified for mitigation".


I've suggested that my customers start opening tickets and telling 
their recipients to also open tickets from the customer side. Maybe if 
the recipients complain they can't get mail someone will listen more 
than being pigeonholed as "not qualified".



Hi Seth, I'd take the description within those 550 error messages with a 
grain of salt. My experience has been that they can be 
inaccurate/misleading. Similarly, take the initial response you received 
on a ticket with a grain of salt given that you've already joined the 
JMRP, SNDS, and appear to be receiving and responding to any reports of 
abuse. If you're still seeing 550 errors, I'd recommend you reply back 
to your original ticket and let the tech know you are already registered 
with the JMRP + SNDS and have taken action on any reports. Sometimes it 
takes a couple attempts to get these issues in front of someone that 
understands what's going on and wants to pursue resolving delivery 
issues affecting customers.

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

Re: [mailop] IP rental

[Blake Hudson via mailop]

I've been receiving (and ignoring) these requests for years. I pity the 
folks that fall victim.



On 8/28/2020 6:38 AM, micah anderson via mailop wrote:

I don't know about you, but we get contacted by these companies who want
to buy/rent our unused IP resources, fairly regularly. They claim to be
'providers of proxy and email marketing resources', 'SEO Proxy, e-mail
marketing, Hosting, VPS', etc (see below for an example).

They are very persistent, and if you try you can find they typically
will offer something around 100-150$ USD/month to rent your /24, and
will also pay $1/IP. They usually want to know what the address space is
in advance, because they are looking for 'clean' addresses.

This can't be anything other than a pipeline for spammers, and it must
work. I'm wondering if this can be shut down somehow, does it require
policy changes at RIRs?


example:

Hey there,

I am Natasha Green and I’m a Procurement Specialist at Signature
Consulting, a UK based company, one of the leading providers of proxy and
email marketing resources.

We are on the market to find new and diverse IP owners that can help us in
our daily business for a monthly revenue. We aspire to find as many
companies and organizations that have access to IP’s and are not currently
using them. The upside is that you’ll get some extra monthly income for
something you were not using.

As requirements, we target every RIR and number of IP’s, so get back to me
when you have the time so we can discuss some more and find a common ground
on this.

Have a great day!

end example




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

Re: [mailop] cox.com CXCNCT

[Blake Hudson via mailop]

Christian, I found myself in a similar boat needing to contact Cox. We 
emailed the official address for our issue (unblock.requ...@cox.net & 
postmas...@cox.net) on Feb 26th and did not get a response until March 
21st. The response said that there were no issues seen in the last 7 
days and asked us to provide a better example (we had provided the 
postfix log lines that clearly displayed our issue at the time). This is 
beyond frustrating that Cox took nearly a month to respond and then had 
the gall to ask us to send a fresh example due to their delay.


Thankfully, after reaching out on this list (as you have just done) we 
received a response from a third party that was able to direct our 
concern to a knowledgeable individual at Cox (or their email provider). 
If you do not hear back from someone within 24 hrs let me know and I 
will dig up the contact and point them in your direction.


--Blake

On 5/6/2020 8:11 AM, Annex Ian via mailop wrote:

hello there!

Referring to the cox.com posts: we also see repetitive CXCNCT errors 
for our mx-servers.


Can anyone help us out please, maybe with a contact-address? None of 
our attempts to contact in the last weeks got us a reply or fix.


Thanks in advance!

Best regards,

christian

___
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] SendGrid Abuse unresponsive

[Blake Hudson via mailop]

Been getting a variety of Amex scams for several weeks via SendGrid. 
Wish they had a better reporting mechanism.


Received: from wrqvfvsw.outbound-mail.sendgrid.net 
(wrqvfvsw.outbound-mail.sendgrid.net [149.72.248.105])

    (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by mail.ispn.net (Postfix) with ESMTPS id 65FE3800E4E
    for ; Tue, 28 Apr 2020 12:04:22 -0500 (CDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispn.net 65FE3800E4E
Authentication-Results: mail.ispn.net;
    dkim=pass (1024-bit key) header.d=mytuner.mobi 
header.i=@mytuner.mobi header.b="e2+SR0dP"

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mytuner.mobi;
    h=content-type:mime-version:subject:to:from:list-unsubscribe;
    s=s1; bh=hTbLWa0rB3Wwo49o0xU2xD9v4bjCR41krW7VkpSSxzw=; b=e2+SR0d
    P7ePRapdg8cLSi5DcN4zltCNr7B0hOOVYEuW4uM4Wjml3DlKmym1U8iZxogOAbit
    RYVNhmHtTrKG2ykVesUyZpOZZk6xvjyUSbqepBPMMh++2xiEhWVZrKtquE8gwqGh
    wt0tQamfhNOT/BlnS4cnr8U8FW2RrnKobwtM=
Received: by filter1430p1mdw1.sendgrid.net with SMTP id 
filter1430p1mdw1-2514-5EA8620E-32

    2020-04-28 17:04:14.507763321 + UTC m=+1091412.289296934
Received: from WIN-KM74NPGSU4J.us-west-2.compute.internal (unknown)
    by ismtpd0035p1las1.sendgrid.net (SG) with ESMTP id 
oDjUdUZhRYO-Wd8jQmosYw

    Tue, 28 Apr 2020 17:04:14.270 + (UTC)
Content-Type: multipart/alternative; boundary="===1274991544=="
MIME-Version: 1.0
Subject: Security Notification on your Card
To: Customers 
From: "American Express" 
Date: Tue, 28 Apr 2020 17:04:14 + (UTC)
Message-ID: 
List-Unsubscribe: 

X-SG-EID: 
eLF1XdoUgtODrTnreYcGkW29+W8SlXhMCPQICHWXv4c4UPqo4BYpwT6WdoB1GFSwuwd6mNC9sCJf1r

 5PzIFZRABSj7gKeokjHm7Lnl8QkLAKEXf2JojGJnXeyze4NC/w39UhwzU/ki7FK6ScIgZx+gfhUQEe
 W/8/g7BcHCE1Lc+BnEOTTL+ZjLy6xWcHvoTOvSwKTV5H7YXMjUPnsbijhXY/GG1vgjjAfJT228fgF5
 JgGA5Yu0hMI46ZfVGtVOMh




On 5/5/2020 9:48 AM, Michael Peddemors via mailop wrote:

Since on the topic of SendGrid..

Received: from dhl.com (unknown)
by geopod-ismtpd-2-1 (SG) with ESMTP
id yXjQUIVNTmWUp86G27YZTw
for ;
Tue, 05 May 2020 10:02:57.886 + (UTC)
From: DHL Express 
Subject: Shipment Arrival Notice.
Date: Tue, 05 May 2020 10:02:57 + (UTC)
Message-ID: <20200505100257.58c63efbca795...@dhl.com>
MIME-Version: 1.0
X-SG-EID:

=?us-ascii?Q?Fty1fbakBjfkMnPdNSS4UpmkoEOMkDriB8B3kSQUjCzRogyCEiG1y0V8I5N3J4?= 


 =?us-ascii?Q?Y=2FMd=2F0SFVzCTWMExjNhU9h6pIlyK51PQJ=2FVJLye?=
 =?us-ascii?Q?RmHv4lJals+LEOvb4dhaYhRi0UPG27bJ=2FJA5mqh?=
 =?us-ascii?Q?VL0Nx9J=2FyaWQ+bIzekwAAGSkhnpeyO+imjI0Cgh?=
 =?us-ascii?Q?r7cfzn2kmMSVsOUIPudnngC0yrk3M=2F80HBjUiIy?=
 =?us-ascii?Q?Wl1Av6MSMteTs=2FjUoR3TVyk006pkGBREAMe4gdV?=
 =?us-ascii?Q?7+1=2F+mc9MUFtHbXdptHbg=3D=3D?=

I don't even think they are trying to stop outbound phishing any more..

This is a little too obvious, and while historically SendGrid ran a 
tight ship, and got a little lee way from spam auditors.. it's getting 
very bad, and going on for too long.. risking loosing any preferential 
treatment..


Overnite..

149.72.1.84 (M)   5 wrqvhkrq.outbound-mail.sendgrid.net
149.72.24.42  2 wrqvkvnx.outbound-mail.sendgrid.net
   149.72.24.51   1 wrqvkvpp.outbound-mail.sendgrid.net
149.72.25.142 7 wrqvkwvz.outbound-mail.sendgrid.net
149.72.43.171 9 wrqvnbxb.outbound-email.sendgrid.net
149.72.58.101 3 wrqvpxsr.outbound-email.sendgrid.net
149.72.63.131   (RS)  3 wrqvpfvp.outbound-email.sendgrid.net
   149.72.63.135 50 wrqvpfvt.outbound-email.sendgrid.net
   149.72.63.193  6 wrqvpfck.outbound-email.sendgrid.net
149.72.134.56   (M)   1 o2.ptr4806.marketing.sg.getweave.com
149.72.146.9    (M)   1 wrqvwnhw.outbound-mail.sendgrid.net
149.72.163.111    4 wrqvxpsf.outbound-mail.sendgrid.net
149.72.185.201    1 wrqvbwcw.outbound-mail.sendgrid.net
149.72.194.224    3   o1.sg.intherooms.com
149.72.219.45 6 wrqvdbnd.outbound-mail.sendgrid.net
149.72.224.183  (RS)  2 wrqvzhbt.outbound-mail.sendgrid.net
149.72.226.67 5 wrqvznqp.outbound-mail.sendgrid.net
149.72.227.4 50 wrqvzphq.outbound-mail.sendgrid.net
149.72.243.74 5 wrqvfpqx.outbound-mail.sendgrid.net
   149.72.243.152 1 wrqvfpwv.outbound-mail.sendgrid.net





On 2020-05-05 6:31 a.m., Jaroslaw Rafa via mailop wrote:

Dnia  5.05.2020 o godz. 08:32:43 Michael Orlitzky via mailop pisze:


That message w

Re: [mailop] Abusix Potentially Compromised Account Report

[Blake Hudson via mailop]

On 3/24/2020 11:19 AM, Steve Freegard via mailop wrote:

Hi Micah,

On 24/03/2020 16:10, micah anderson wrote:


FWIW, we got a couple of these Abusix reports, checked them out and
determined they were all false positives. Every single one of them was
either an account that hasn't existed for years, or wasn't even a valid
account (like mailing list -subscribe addresses).

I appreciate what you guys are trying to do, but after making us jump
for a bunch of false positives, this makes us consider this a 'cry wolf'
service that we'll probably ignore very quickly. I'm sure you have
actual legit data in there and if you had sent me things that were
legit, it would have been helpful to know about it.


Thanks for the feedback, as I posted earlier - I found some data that 
wasn't being excluded that should have been, so this made the initial 
reports noisier than they normally would be.


Hopefully if you get any more, they'll be more useful.


Just to add another point of perspective, we received our second report 
today:

"cou...@x.com","b7c99","77.120.228.177",1585784605,"2020-04-01T23:43:25.000Z"

This is a domain we provide MX for, but this is not a valid user. This 
has been the case for most of the information that has been reported. As 
others have stated, we have no relation to the IP address in the report 
- I'm not sure why it's included or for who's benefit. Rather than 
sending folks a list of email addresses that never existed on their 
systems, perhaps it would be reasonable to try and vet these usernames 
to see if they currently exist. Or just let folks go to the Abuseix 
website themselves and perform a search of their domains or IP space. I 
assume your intent was noble, but in their current form these reports 
have been unhelpful and unsolicited.


Thank you for your time,
--B

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

[mailop] Anyone from Cox on the list?

[Blake Hudson via mailop]

Subject says it all... I'm having trouble reaching a live body at Cox. 
Messages to postmas...@cox.net and unblock.requ...@cox.net go unanswered 
and I would like some assistance resolving an email issue between our 
mutual customers.


Thanks!

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

Re: [mailop] These guys are doing it right!

[Blake Hudson via mailop]

On 3/11/2020 7:47 AM, Jaroslaw Rafa via mailop wrote:

Dnia 10.03.2020 o godz. 13:47:44 Andris Reinman via mailop pisze:

This behaviour is pretty common, not just Mail.ru – instead of building
actual IMAP and MIME capability into a phone app, client developers push
all IMAP connection handling and MIME processing to their servers and
expose HTTP based API to the mobile client.

It's strange how in the old days of "dumb" mobile phones, email applications
(Java midlets) runing on those phones used actual POP/IMAP and nobody ever
thought about setting up an intermediate server converting this to HTTP
requests, and now programmers who have much more computing power and much
better programming tools at their disposal (compare any smartphone to eg.
Siemens C60 - which I used for many years - in terms of available resources)
are using such lame solution. Strange, indeed...


Blackberries did this back in the day. Personally I don't like it due to 
the security concerns of another entity having the credentials and 
contents to a mailbox that they don't have anything to do with. I 
suppose it adds another layer of abstraction for troubleshooting as well 
- something I've ran into with the Mobile Outlook App where it wasn't 
clear to the user if the App was prompting for the credentials for a 
mailbox I provide or credentials for an account MS provides.


--Blake

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

Re: [mailop] Anyone from HughesNet ISP here

[Blake Hudson via mailop]

Lili, I thought you might be interested to know that our logs indicate 
this issue may have cleared up on or around March 3rd. And we have 
confirmation that a HughesNet user that previously reported issues is 
now working.


On 3/4/2020 10:32 AM, Lili Crowley via mailop wrote:

Hey  -

Our users who are also Hughes users are unable  to log into out site. 
Still trying to resolve this.


thanks!
Lil.  Crowley
Postmaster
Verizon Media


On Wed, Mar 4, 2020 at 11:25 AM Blake Hudson via mailop 
mailto:mailop@mailop.org>> wrote:


Lili, would you be willing to spread a little light on what
prompted this message to the list?

Near the end of February we started receiving reports of SMTP
timeouts from customers using HughesNet and I would love to know
if you're seeing something similar.

--Blake

On 2/26/2020 12:13 PM, Lili Crowley via mailop wrote:

Please contact me off list.

Thanks!
Lili


Lili Crowley
Postmaster
Verizon Media


___
mailop mailing list
mailop@mailop.org <mailto: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 mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from HughesNet ISP here

[Blake Hudson via mailop]

Lili, would you be willing to spread a little light on what prompted 
this message to the list?


Near the end of February we started receiving reports of SMTP timeouts 
from customers using HughesNet and I would love to know if you're seeing 
something similar.


--Blake

On 2/26/2020 12:13 PM, Lili Crowley via mailop wrote:

Please contact me off list.

Thanks!
Lili


Lili Crowley
Postmaster
Verizon Media


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

Re: [mailop] Deferred Email to Yahoo Servers

[Blake Hudson via mailop]

Stephen, we've noticed similar behavior. You might reach out to another 
member of this list, Lili Crowley , if 
she has not reached out to you directly yet. Hopefully she can help 
speed resolution of this issue for you.


--Blake

Stephen Brown x419 via mailop wrote on 12/5/2019 7:14 PM:


I hope everyone is having a great day today.

I am writing for assistance with sending to yahoo, AOL, Verizon, etc. 
email servers. Around Sept/Oct of 2019 we started seeing some of our 
emails get deferred for about 4 hours or so to yahoo and company 
servers. We have implemented DKIM/Dmarc and Yahoo feedback loop. Since 
then we have had 3 emails come to us from that program. We immediately 
blocked outbound emails to these email address. However, we continue 
to have issues. Well, this past Monday, we noticed that we can no 
longer send to yahoo servers. However, the error messages are still 
the same.


Yahoo error message:

Deferred: host mta6.am0.yahoodns.net[67.195.204.77] said: 421 4.7.0 
[TSS04] Messages from x.x.x.x temporarily deferred due to user 
complaints - 4.16.55.1; see 
https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL 
FROM command)


I am not sure what to do. We have tried several times to contact yahoo 
postmaster and it always comes back with links to their best 
practices. We are a nonprofit religious group and a school district. 
We often communicate with parents and volunteers who have yahoo accounts.


Any assistance is greatly appreciated.

Stephen Brown

Diocese of San Bernardino



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

Re: [mailop] Low-Volume Domains\Servers

[Blake Hudson via mailop]

I manage some similar volume domains and haven't seen that personally. 
Detecting the compromised account quickly (before you land on an RBL) is 
imperative. Allowing a compromised account to send 10's of thousands of 
messages over a period of several days is going to land you on a number 
of naughty lists (public and private RBLs) and you should expect it will 
take days for removal.


If you can limit these events to a few hundred messages you can probably 
evade any naughty lists other than maybe a temp rate limit by 
Yahoo/AOL/Verizon or similar. I would recommend that you limit the 
damage one customer can do by limiting the rate of messages one user can 
send (may be a few hundred per hour) as well as the total number of 
messages allowed per day from any given user (whatever works for your 
users, whether that be 100, 1000, or 10k). NOC alerts for users that 
exceed those limits will help you catch these events before you receive 
feedback via other mechanisms (queue size, feedback loops, user 
complaints, etc).


--Blake

Mike Hammett via mailop wrote on 10/25/2019 2:02 PM:

20 - 30 messages a day? I'm just guessing.

Now that's 20 - 30 messages a day hitting that particular service.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Ken O'Driscoll via mailop" 
*To: *mailop@mailop.org
*Sent: *Friday, October 25, 2019 12:08:29 PM
*Subject: *Re: [mailop] Low-Volume Domains\Servers

On Fri, 2019-10-25 at 11:34 -0500, Mike Hammett via mailop wrote:
> One time one of them told me that because my normal volume was so low,
> they didn't have much to go on for validating the problem had been
> corrected.

Exactly how low is low?

I work with some smallish ISPs and they don't have this issue so hence why
I ask.

Ken.


___
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 mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Does sending HTML only email affect delivery?

[Blake Hudson via mailop]

Sending HTML only messages or messages where the HTML and the plain text 
parts vary significantly is a SpamAssassin rule that will help push your 
message into the junk folder. These rules are weakly weighted, and 
unlikely to land your message in the spam folder by themselves, but 
should be taken as a sign that legitimate email messages have both HTML 
and plain text and that they are often similar (at least in the eyes of 
the SpamAssassin authors). AFAIK, SpamAssasin is the mechanism for 
nearly all content based scanning tools.


--Blake

Marc Goldman via mailop wrote on 10/25/2019 2:04 PM:
In the past, it was always better to send MIME compliant emails but as 
more and more developers come on with a “who uses Text anymore anyway” 
mentality I wonder if this is changing.


Please dont shoot the messenger as I know there are folks on here who 
most probably do use TEXT only but most likely you would not be the 
target recipient for such messages.


But my question is: will one get spanked in the delivery department 
for sending HTML only emails?


Thanks!

Marc Goldman



___
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] Resolving issues for several yahoo domains?

[Blake Hudson via mailop]

For what it's worth, Oath is the only email service provider I've ever 
had to rate limit outgoing email to. All other email service providers 
seem to work fine when one uses the (seemingly sensible) Postfix defaults.


Laura Atkins via mailop wrote on 9/6/2019 2:49 PM:

Gmail has never suggested they care.

Laura

Sent from my iPhone

On Sep 6, 2019, at 8:38 PM, Brandon Long > wrote:


Now people have made me curious what they set those values to for 
Gmail.  We don't have simple limits like those (a quick check shows 
the max number of messages sent on a single connection in the past 
week is 414k, and I know I've seen total number of connections from a 
single source over 10k), the throttling is on a more esoteric 
collections of signals ...


Brandon


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

Re: [mailop] Return Path / Sender Score

[Blake Hudson via mailop]

Steve Atkins via mailop wrote on 8/21/2019 3:30 AM:


On 21/08/2019 09:16, Michael Hallager via mailop wrote:
A well known Australian electronics retailer has recently started 
spamming me. It's plainly obvious where they - or someone who 
provided it to them - got the email address from the WHOIS because 
that is the only place that address is published.


Unfortunately, I have also noticed this sender is certified by Return 
Path, and getting 3 points off our anti-spam because of this. I have 
contacted Return Path and their response would suggest they basically 
don't care.


Has anyone else had this experience with Return Path?


Return Path was bought out recently by https://www.validity.com/, with 
much of the staff being fired and many offices closed.


If you find that Return Path certification doesn't correlate with 
senders being a source of wanted email you should probably configure 
your spam filtering rules to match.


Cheers,


That would explain why I just received a sales call today from an 
employee of Validity after I updated our FBL and SenderScore settings 
with Return Path yesterday (even though I opted not to receive marketing 
communication). I assumed they sold a sales lead, but it sounds like 
just internal sharing and not necessarily honoring the opt-in settings 
chosen by users of their free services.




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