Re: [mailop] AT&T blocking IP addresses

[Carl Byington via mailop]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2022-03-30 at 10:55 -0700, Michael Peddemors via mailop wrote:
> Imagine the day where you can't use email unless you use Gmail or
> o356.

If that happens, there will be two mail systems (gmail/o365) and
(everyone else). If the (gmail/o365) folks will only accept mail from
each other, then there is no reason for (everyone else) to accept mail
from them.

So folks that want to apply to a college won't be able to do it from a
gmail account. So everyone will have at least two addreses, one in each
side of the partition.



-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYkUjrRUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsFj1gCfSMketrxUOin+zderNpZQUJZR69QA
n1BtQf8Udr66MTYLYoEEjpL2rnqW
=ZbkV
-END PGP SIGNATURE-


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

Re: [mailop] Can someone from google/gmail contact me offlist?

[Carl Byington via mailop]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2022-03-30 at 09:56 -0500, Al Iverson via mailop wrote:
> Since this specifically refers to domain reputation I'd make sure all
> mail is properly signing with DKIM. Domain rep can also fall back to
> the return-path domain, so if that's different from your visible from
> domain, that could be the domain with a poor rep. And domain in this
> context can also mean subdomain.

The bind-users list arriving here via lists.isc.org is similar to this
list (mailop), in that outgoing list mail is not DKIM signed by
respectively isc.org or mailop.org.

Both lists have the dmarc workaround. Perhaps it has nothing to do with
the list email.


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYkThNhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsGspgCfeOvNyD8Vjd2Iw3OTNCPLf1O51ukA
nRfWjXKDixLIORnLtWetiUllIhh8
=a378
-END PGP SIGNATURE-


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

Re: [mailop] Amazon, what every happened to trace headers?

[David Conrad via mailop]

Well, there is a new guy at Amazon that might be a bit more amenable to 
anti-spam efforts… :)

https://www.linkedin.com/in/paulvixie/ 

Regards,
-drc


> On Mar 30, 2022, at 12:04 PM, Rob McEwen via mailop  wrote:
> 
> On 3/30/2022 2:42 PM, Michael Peddemors via mailop wrote:
>> Since I am on a rant about transparency, Amazon spammers continue to 
>> increase.. and now there is NO trace headers at all.. makes it look like an 
>> OS generated (compromised server?) email.
> 
> I've had conversations with Amazon - some all the way back in 2015 - another 
> conversation this past year or so - asking them to please consider putting 
> more information in the header which would help to better identify (a) the 
> unique sender/customer of Amazon who is doing the sending, and (b) in cases 
> where they've outsourced their service to an ESP, having a means for that ESP 
> to have an email header identifying Amazon's customer's customer.
> 
> In all cases, they essentially rolled their eyes at me - and in the most 
> recently conversation - they basically said that this wasn't worth their time.
> 
> Some DNSBLs like invaluement - are moving towards alternative types of 
> anti-spam data that surgically targets the "bad apple" customers of ESPs - 
> thus trying to minimize the collateral damage of listing shared IPs and 
> listing ESP redirect/tracking domains that so many ESP customers use, good 
> and bad (which which then helps them keep their own domain out of the body of 
> the message). But in the case of Amazon, they're making this task more 
> difficult, for the reasons that Michael Peddemors mentioned.
> 
> Which brings up an interesting question - is it not UNFAIR for ESPs that are 
> more transparent and who provide these headers - to get their spammers booted 
> - while ESPs like Amazon get "off the hook" and "laugh all the way to the 
> bank" as their spammy customers don't get listed as easily, and then continue 
> to be paying customers? The answer is - absolutely - that's extremely unfair. 
> The responsible ESPs shouldn't feel "punished" for being more transparent!
> 
> At invaluement - as we complete our work this next generation of anti-spam 
> data that we're working on (have been for a few years - but this should be 
> released before too long) - we're paying close attention to this truth - and 
> are going to try hard to make sure we don't facilitate any such unfair 
> inequities - and we're going to try to be harder on the ESPs who refuse to be 
> transparent, yet without such efforts causing any other types of false 
> positives or collateral damage.
> 
> --
> Rob McEwen, invaluement
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict

[Marcel Becker via mailop]

On Wed, Mar 30, 2022 at 8:29 AM Mike Hammett  wrote:

> https://en.wikipedia.org/wiki/Cyberwarfare
> 
>

Thanks. I am aware of why he asked the questions. Maybe I should have
phrased this differently. Along the lines of: What specifically makes him
believe that the volume actually increased and that spam filters actually
changed.

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

Re: [mailop] Amazon, what every happened to trace headers?

[Rob McEwen via mailop]

On 3/30/2022 3:43 PM, David Conrad wrote:
Well, there is a new guy at Amazon that might be a bit more amenable 
to anti-spam efforts… :)

https://www.linkedin.com/in/paulvixie/



WOW! That's very interesting/promising. Sometime in the next few months, 
I'll be sure to discuss this with him when our focus shifts back to that 
part of our upcoming new anti-spam data.


Thanks for mentioning this exciting info!

-- Rob McEwen, invaluement
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone from BNETZA.DE ?

[Bernardo Reino via mailop]

On Tue, 29 Mar 2022, Glowfish Domainadministrator via mailop wrote:

Even when I try to telnet the servers from a totally different network I get a 
connection refused:


telnet 194.156.223.27 25
Trying 194.156.223.27...
Connected to 194.156.223.27.
Escape character is '^]'.
554 5.7.1 SMTP connection rejected
Connection closed by foreign host.

However I can send mail to bnetza.de from Google Mail just fine.

Is there a mailadmin of the “Bundesnetzagentur / bnetza.de” around here ? Or 
if the error is clearly on our side – I would appreciate a hint or help with 
that 😊


I just tried from my home IP address (Deutsche Telekom) and the connection was 
rejected, but from my root server @Hetzner I could connect.


So they seem to have a very restrictive whitelist?

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

Re: [mailop] Amazon, what every happened to trace headers?

[Rob McEwen via mailop]

On 3/30/2022 2:42 PM, Michael Peddemors via mailop wrote:
Since I am on a rant about transparency, Amazon spammers continue to 
increase.. and now there is NO trace headers at all.. makes it look 
like an OS generated (compromised server?) email. 



I've had conversations with Amazon - some all the way back in 2015 - 
another conversation this past year or so - asking them to please 
consider putting more information in the header which would help to 
better identify (a) the unique sender/customer of Amazon who is doing 
the sending, and (b) in cases where they've outsourced their service to 
an ESP, having a means for that ESP to have an email header identifying 
Amazon's customer's customer.


In all cases, they essentially rolled their eyes at me - and in the most 
recently conversation - they basically said that this wasn't worth their 
time.


Some DNSBLs like invaluement - are moving towards alternative types of 
anti-spam data that surgically targets the "bad apple" customers of ESPs 
- thus trying to minimize the collateral damage of listing shared IPs 
and listing ESP redirect/tracking domains that so many ESP customers 
use, good and bad (which which then helps them keep their own domain out 
of the body of the message). But in the case of Amazon, they're making 
this task more difficult, for the reasons that Michael Peddemors mentioned.


Which brings up an interesting question - is it not UNFAIR for ESPs that 
are more transparent and who provide these headers - to get their 
spammers booted - while ESPs like Amazon get "off the hook" and "laugh 
all the way to the bank" as their spammy customers don't get listed as 
easily, and then continue to be paying customers? The answer is - 
absolutely - that's extremely unfair. The responsible ESPs shouldn't 
feel "punished" for being more transparent!


At invaluement - as we complete our work this next generation of 
anti-spam data that we're working on (have been for a few years - but 
this should be released before too long) - we're paying close attention 
to this truth - and are going to try hard to make sure we don't 
facilitate any such unfair inequities - and we're going to try to be 
/harder/ on the ESPs who refuse to be transparent, yet without such 
efforts causing any other types of false positives or collateral damage.


-- Rob McEwen, invaluement
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Amazon, what every happened to trace headers?

[Michael Peddemors via mailop]

Since I am on a rant about transparency, Amazon spammers continue to 
increase.. and now there is NO trace headers at all.. makes it look like 
an OS generated (compromised server?) email.


A 'sendy.co' generated mailing list, it MUST have come from somewhere 
correct? No Message-ID generated, no trace headers.. and anoynmized MAIL 
FROM


This doesn't help others identify the good vs the bad, does it?

Comments from the public?



Return-Path: 
<0102017fdc16a1e5-557d8518-534e-48b1-b572-d885442c4447-000...@eu-west-1.amazonses.com>

Delivered-To: 
Received: (qmail 1152124 invoked from network); 30 Mar 2022 18:29:07 -
Received: from a6-163.smtp-out.eu-west-1.amazonses.com (HELO 
a6-163.smtp-out.eu-west-1.amazonses.com) (54.240.6.163)

by  with (ECDHE-RSA-AES128-SHA256 encrypted) SMTP
(48214506-b057-11ec-a38f-6fa1ac6fe550); Wed, 30 Mar 2022 11:29:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=lt4d4pbddkdpos5pqfcys5g6yrgfoxiy; d=buzzevents.ma; t=1648664945;

h=Date:To:From:Reply-To:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type;
bh=kBXj0jeO/6t6XQJnwHI8Vsfodg//NJLS2+v7q8W/Afo=;
b=dWvno2iizi4wIygK3SjnzDTfEaOg+xZtZpTfQlQrHL5WpnaVkigbS+qFAFiNbsGf
onH5maahdkgkELJ3tx4L4Jcwp+ep2g5SEo5Dha4hTiY+q7kFwAjRIftP7dKzaXaiTPM
OeG2rQgadkTu17IFrjZnz2ji/xzhuwaEjVeW1kVA=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1648664945;

h=Date:To:From:Reply-To:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type:Feedback-ID;
bh=kBXj0jeO/6t6XQJnwHI8Vsfodg//NJLS2+v7q8W/Afo=;
b=Lci+UNfVAM4CDf9hI7RqlMhJPM4YdZgFYKNjBAiQ0iueIBj9xuOCBz4svnfSk8KU
dTX2l/lBQYsm/Ijcgb+J1zWv467aQN9jexsvwPd66Witb2vk0ynLluJAgHfsKR2PlvH
eV/La67nexTt+2mIicQN+Tpq4Qy5yknSlZdYSRT8=
Date: Wed, 30 Mar 2022 18:29:05 +
To: no name 
From: Emecexpo 
Reply-To: Emecexpo 
Subject: EMEC EXPO | 18 & 19 Mai 2022 : Confirmez votre participation
Message-ID: 
<0102017fdc16a1e5-557d8518-534e-48b1-b572-d885442c4447-000...@eu-west-1.amazonses.com>

X-Mailer: Sendy (https://sendy.co)
List-Unsubscribe: 


MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Feedback-ID: 
1.eu-west-1.rQ9Gga2KPv8Z/9kXExQk+T/e8s9dv2uWeZImS1SoDAI=:AmazonSES

X-SES-Outgoing: 2022.03.30-54.240.6.163
X-MagicMail-OS: Linux 2.2.x-3.x
X-MagicMail-UUID: 48214506-b057-11ec-a38f-6fa1ac6fe550
X-MagicMail-SourceIP: 54.240.6.163
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: 
<0102017fdc16a1e5-557d8518-534e-48b1-b572-d885442c4447-000...@eu-west-1.amazonses.com>

X-MagicMail-Quarantine: Yes

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

Re: [mailop] AT&T blocking IP addresses

[Michael Peddemors via mailop]

Just because that big cloud providers are ignoring best practices, 
doesn't stop them from being best practices.


This is really a topic for MAAWG to address and have a conversation 
about.  However, this trend towards allowing anonymized services and 
internet space is NOT good for the future of the internet, and/or security.


And there does seem to be an actual intentional strategic business 
decision amongst the large cloud providers to simply ignore best 
practices and interoperability agreements, whether it be RFC's, ARIN 
guidelines, or simply quiet business practice changes.


I have help talks with many in the industry over the last few months, 
and one quote stands out.. "We are not competing against each other, we 
are competing against the big cloud providers".


At a certain size, the 'too big to block'(TBTB), it seems that 
accountability goes out the window.


The path we are on, it isn't inconceivable that TBTB simply decides not 
to allow others to even communicate.  The internet was founded on 
transparency, responsibility, and co-operation, but this appears to be 
changing, and we do have to step up and have a voice.


Using 'Data Privacy' as an excuse for anonymity which helps their 
business practices make more money, or an avoidance of responsibility is 
a threat to all users of the internet.


Tin foil hat wearing people may even suggest that they don't mind 
threats emerging from their networks, as long as it doesn't affect their 
customers, and is a tool to bring more business.


Imagine the day where you can't use email unless you use Gmail or o356.

Yes, we have to disagree on this point.. the move to the cloud does NOT 
mean that it absolves company(s) of transparency, responsibility, or 
interoperability.


The thousands of cloud IP(s) seen every day involved in hacking attempts 
from the TBTB companies hurt real human beings, and we should get back 
to the principles that at at the root of the concepts of a World Wide Web.






On 2022-03-28 20:49, Graeme Slogrove via mailop wrote:

SWIP
-> Neither Microsoft nor Amazon do SWIP. And they never will. I've escalated to 
their product managers and it's not happening. BYOIP is coming for Azure which we 
will likely pursue.
-> We've run the same service in EU and AU for 2+ years. Never had a problem 
nor needed SWIP.
-> As to the approach of operators that choose to block entries with no SWIP, 
the world is moving to cloud. It may not be the best overall strategy going 
forward to block spam. Maybe it blocks some spam, but likely interferes with other 
large corporates in cloud from communicating with a higher than acceptable false 
positive rate

"Website"
Easy to provide plenty of large players that don't have websites (or broken 
ones) for the domain they use in the mail server FQDN. Either way, if you 
believe it makes a huge difference, it's an easy task. rsapps.net, anyone?

I think we may have to agree to disagree on the requirements to run/operate a 
mail server. YMMV.

-Original Message-
From: mailop  On Behalf Of Michael Peddemors via 
mailop
Sent: Tuesday, 29 March 2022 12:00 PM
To: mailop@mailop.org
Subject: Re: [mailop] AT&T blocking IP addresses


-
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
-

And once again..

NetRange:   52.145.0.0 - 52.191.255.255
CIDR:   52.152.0.0/13, 52.146.0.0/15, 52.145.0.0/16,
52.148.0.0/14, 52.160.0.0/11
NetName:MSFT
NetHandle:  NET-52-145-0-0-1
Parent: NET52 (NET-52-0-0-0-0)
NetType:Direct Allocation
OriginAS:
Organization:   Microsoft Corporation (MSFT)
RegDate:2015-11-24
Updated:2021-12-14
Ref:https://rdap.arin.net/registry/ip/52.145.0.0



OrgName:Microsoft Corporation

Every organization choosing to use this IP space SHOULD insist that MS give 
them SWIP or 'rwhois'.

Otherwise you may look like the many spammers using their IP Space.

As well.. *sigh* (Time to put that 'Operating an Email Server 101'
course back on line)

http://twsegcloud.com/

If you saw connections from an IP with no SWIP and no website, would YOU allow 
traffic from it?

On 2022-03-28 15:30, Graeme Slogrove via mailop wrote:

We are actively using the new IP ranges as published a few weeks ago,
everything seemed fine until this morning

Server refused mail at MAIL FROM - 553 5.3.0 flpd577 DNSBL:RBL 521<
52.165.84.32 >_is_blocked.For assistance forward this error to
abuse_...@abuse-att.net 

The ranges again are

52.165.84.32/28

52.165.84.16/28

20.81.235.112/28

20.81.235.96/28

Anyone from AT&T that I can co

Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict

[Mike Hammett via mailop]

https://en.wikipedia.org/wiki/Cyberwarfare 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Marcel Becker via mailop"  
To: "Luis E. Muñoz"  
Cc: "mailop"  
Sent: Wednesday, March 30, 2022 10:03:48 AM 
Subject: Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict 



On Wed, Mar 30, 2022 at 7:29 AM Luis E. Muñoz via mailop < mailop@mailop.org > 
wrote: 




I am looking at some data showing substantial email traffic increase (2x 
baseline) along with a visible change in the spam filtering statistics, 
centered at or near 2022-02-28. Are you guys aware of any publicly available 
source that would be discussing a similar observation? 





Why do you think both of these (increase and spam filter changes) happened at 
all? 


- Marcel 

___ 
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] Traffic patterns related to Russian-Ukranian conflict

[Michael Peddemors via mailop]

Can always be discussed here..

Some small observations..

* Detected Malware Spam from Ukranian servers (minor)
* Detected Pro Ukraine Mailings (legit and people taking advantage)
* Increase in BotNet traffic, Brazil is REALLY bad.
* Increase in compromised email phishing
* Increase in Cloud Phishing actors (Azure/AWS/Google et al)
* Increase in use of VPN to obscure attacks
* AUTH bot traffic approximately doubled
* Increase in SendGrid/Mailgun phishing attacks

So, which ones do we discuss ;)

However, most of the attacks/spam are stopped/detected, so I think we 
are most concerned with anything new that hasn't been previously detected.


Miria Botnet seems to be the most active for auth attacks.  Some Emotet 
increases are being reported on other channels but not yet seeing it 
pass many filters.  The trickiest one is the email replay attacks, from 
compromised accounts.. that has been the biggest new increase.





On 2022-03-30 08:03, Marcel Becker via mailop wrote:
On Wed, Mar 30, 2022 at 7:29 AM Luis E. Muñoz via mailop 
mailto:mailop@mailop.org>> wrote:



I am looking at some data showing substantial email traffic increase
(2x baseline) along with a visible change in the spam filtering
statistics, centered at or near 2022-02-28. Are you guys aware of
any publicly available source that would be discussing a similar
observation?


Why do you think both of these (increase and spam filter changes) 
happened at all?


- Marcel




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

Re: [mailop] Can someone from google/gmail contact me offlist?

[Al Iverson via mailop]

On Wed, Mar 30, 2022 at 2:53 AM Dan Mahoney via mailop
 wrote:
>
> Day Job (ISC.org) is having delivery issues to gmail due to our “very low” 
> reputation.  I call shenanigans.
>
> Mar 30 07:21:58 post postfix/smtp[75122]: D7B673AB008: 
> to=, 
> relay=gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b]:25, delay=1.7, 
> delays=0.31/0/0.85/0.52, dsn=5.7.1, status=bounced (host 
> gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b] said: 550-5.7.1 
> [2001:4f8:0:2::2b  19] Our system has detected that this message 
> 550-5.7.1 is likely suspicious due to the very low reputation of the sending 
> 550-5.7.1 domain. To best protect our users from spam, the message has been 
> 550-5.7.1 blocked. Please visit 550 5.7.1  
> https://support.google.com/mail/answer/188131 for more information. 
> c8-20020a056102318800b003255333019bsi4904938vsh.501 - gsmtp (in reply to end 
> of DATA command))

I would suggest a submission here as well:
https://support.google.com/mail/contact/bulk_send_new

Since this specifically refers to domain reputation I'd make sure all
mail is properly signing with DKIM. Domain rep can also fall back to
the return-path domain, so if that's different from your visible from
domain, that could be the domain with a poor rep. And domain in this
context can also mean subdomain.

Cheers,
Al Iverson
-- 
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Traffic patterns related to Russian-Ukranian conflict

[Peter N. M. Hansteen via mailop]

On Wed, Mar 30, 2022 at 10:20:47AM -0400, Luis E. Muñoz via mailop wrote:
> 
> Dear colleagues,
> 
> I am looking at some data showing substantial email traffic increase (2x 
> baseline) along with a visible change in the spam filtering statistics, 
> centered at or near 2022-02-28. Are you guys aware of any publicly available 
> source that would be discussing a similar observation?
> 

I can only speak for bsdly.net and friends, we did not see any significant 
variations
in email traffic of either the desired or not-so-desired kind during that time 
frame.

On the other hand, we did see a significant uptick in the number of failed ssh 
logons
of the typical password guessing kind. The article I wrote in late February is 
up at 
https://bsdly.blogspot.com/2022/02/predicting-developments-in-real-world.html 
and there
is also the trackerless version with somewhat simpler formatting 
https://www.bsdly.net/~peter/Predicting_developments_in_real_world_conflict_from_patterns_of_failed_logins.html

Links to data and some other references in both.

All the best,
Peter N. M. Hansteen

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict

[Marcel Becker via mailop]

On Wed, Mar 30, 2022 at 7:29 AM Luis E. Muñoz via mailop 
wrote:

>
> I am looking at some data showing substantial email traffic increase (2x
> baseline) along with a visible change in the spam filtering statistics,
> centered at or near 2022-02-28. Are you guys aware of any publicly
> available source that would be discussing a similar observation?
>

Why do you think both of these (increase and spam filter changes) happened
at all?

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

[mailop] Traffic patterns related to Russian-Ukranian conflict

[Luis E . Muñoz via mailop]

Dear colleagues,

I am looking at some data showing substantial email traffic increase (2x 
baseline) along with a visible change in the spam filtering statistics, 
centered at or near 2022-02-28. Are you guys aware of any publicly available 
source that would be discussing a similar observation?

Thanks in advance.

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

[mailop] Can someone from google/gmail contact me offlist?

[Dan Mahoney via mailop]

Day Job (ISC.org) is having delivery issues to gmail due to our “very low” 
reputation.  I call shenanigans.

Mar 30 07:21:58 post postfix/smtp[75122]: D7B673AB008: 
to=, 
relay=gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b]:25, delay=1.7, 
delays=0.31/0/0.85/0.52, dsn=5.7.1, status=bounced (host 
gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b] said: 550-5.7.1 
[2001:4f8:0:2::2b  19] Our system has detected that this message 550-5.7.1 
is likely suspicious due to the very low reputation of the sending 550-5.7.1 
domain. To best protect our users from spam, the message has been 550-5.7.1 
blocked. Please visit 550 5.7.1  https://support.google.com/mail/answer/188131 
for more information. c8-20020a056102318800b003255333019bsi4904938vsh.501 - 
gsmtp (in reply to end of DATA command))
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop