[mailop] Sophos appliance reject mails from specific domains with Administrative prohibition, confirmed spam in logs

[Stefan Bauer via mailop]

Thank you. Thats what i expected.



Unfortunately sophos requires one be a customer as it seems. Sophos answer:



"Please ask recipient to raise a ticket with us so we can submit emails to lab 
team.".



Stefan





-Ursprüngliche Nachricht-
Von: Olivier Depuydt via mailop 
Gesendet: Donnerstag 20 August 2020 11:13
An: Stefan Bauer 
CC: mailop 
Betreff: Re: [mailop] Sophos appliance reject mails from specific domains with 
Administrative prohibition, confirmed spam in logs

Hello.

You need to contact Sophos support (through) their website.
They are using an internal list on their equipment in addition to the regular 
public blacklists.


Best regards,

Olivier

Le jeu. 20 août 2020 à 10:58, Stefan Bauer via mailop  a 
écrit :
Hi,



since days, we try to find out why one of our customer domain is blocked, when 
sending mails to remote sites, where Sophos UTM-appliance (e.g. UTM-430) are in 
place.



All we see is at smtp level:



mailto:john@famo24.de> >: host 
mail3.famo24.de[80.155.146.58] said: 550
    Administrative prohibition (in reply to end of DATA command)



Recipients (admins) confirm, that according to local FW logs, they see 
'confirmed spam'.



All of our sending IPs are in no blacklist nor have been over the last years.



I checked all the known blacklists. Even cyrens own site. All is green and good.



One of our sending IPs is 116.203.31.6



Anyone with an idea?



Thank you.



Stefan

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


--
Olivier Depuydt

Site Reliability Engineer



Web  |  Blog    |  Linkedin  |  Twitter  |  
Facebook
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Just how does SendGrid fail this badly?

[Jesse Thompson via mailop]

Most ESPs allow forging of arbitrary domains (usually requiring just an email 
loop verification *to* any address in the domain).  It's good for business.  
Their customers don't understand SPF/DKIM/DMARC, in their defense.  

Plus, it's technically a misdeployment for any domain to publish DMARC if it 
houses users, so all bets are off.  But that's a topic for another list.

Jesse

On Aug 20, 2020 9:57 PM, Philip Paeps via mailop  wrote:


On 2020-08-21 00:26:37 (+0800), Brielle via mailop wrote:

> Oops, hit the send keybind by accident while trying to paste...  Lets 
> try this again.
>
>
> On 8/19/2020 11:06 PM, Philip Paeps via mailop wrote:
>> On 2020-08-18 20:23:37 (+0800), Atro Tossavainen via mailop wrote:
>>> The SendGrid account sending these yesterday is 13999362.
>>
>> The one I've seen most often is 12340469 with 9789821 a close second 
>> and 8512936 in third place.
>
> I just started seeing 2019535 this morning.  Luckily ClamAV's extra 
> rules seem to be snagging it.

This is clearly a structural problem rather than one rogue customer...

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

___
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] Just how does SendGrid fail this badly?

[Philip Paeps via mailop]

On 2020-08-21 00:26:37 (+0800), Brielle via mailop wrote:

Oops, hit the send keybind by accident while trying to paste...  Lets 
try this again.



On 8/19/2020 11:06 PM, Philip Paeps via mailop wrote:

On 2020-08-18 20:23:37 (+0800), Atro Tossavainen via mailop wrote:

The SendGrid account sending these yesterday is 13999362.


The one I've seen most often is 12340469 with 9789821 a close second 
and 8512936 in third place.


I just started seeing 2019535 this morning.  Luckily ClamAV's extra 
rules seem to be snagging it.


This is clearly a structural problem rather than one rogue customer...

Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

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

Re: [mailop] Mailman confirmation email denial of service

[Ángel via mailop]

On 2020-08-19 at 19:49 +0800, Philip Paeps via mailop wrote:
> On 2020-08-19 17:51:51 (+0800), Andy Smith via mailop wrote:
> > Since yesterday I've been seeing a large number of attempted 
> > subscriptions to all the public lists on one of my Mailman servers.  
> > There's so far been 160 attempted subscriptions for 69 unique email 
> > addresses.
> 
> I see some of this on FreeBSD.org as well.  Roughly the same magnitude 
> you're seeing.
> 
> > Therefore I think it is an attack on these addresses.
> 
> This has happened before...  We have a hack in our webserver from June 
> 2018 when one specific address was being subscribed over and over and 
> over again to every single Mailman list on the internet.
> 
> > All of the subscription requests are coming in with a UserAgent of 
> > "axios/0.19.2". I have for now blocked this in my web server:
> 
> Since we're only seeing a couple of hundred of these so far, I'll hold 
> off adding yet another hack to our configuration.
> 
> Thanks for the heads-up though.  It's worth keeping an eye on these 
> things.  We run an awful lot of mailing lists and it's not very 
> difficult for a script-kiddie to cause a flood of subscription 
> confirmations.
> 
> Philip

I was going to enable the 2018 mitigations... and it turns out it they
were already active.

Quite similar as reported, around here.

It started subscribing lywlo...@gmail.com and lywlo...@gmail.com, then
mmc49...@eoopy.com on multiple lists... a total of 221 emails so far,
from 595 ip addresses... out of 601 attempts. Unlike in 2018, here each
IP is doing a single subscription, the 6 cases with two subscriptions
may have been errors... or the botnet is just so big that it is hard to
be hit twice by the same IP.

All of them with User-Agent axios/0.19.2, and password 123456789.

$   while read email; do printf "%s" "$email" | md5sum; done < 
bademails.txt | cut -d\  -f 1 | sort
002e30ac2ab27d71e1537732bf5ec06a
01869f4f35ce0169312f3773497a29a4
02d759ac00b28334a5a27c7d4966fa0c
02edcda251d2bef9ff972d37e1b1a470
05ece2f3adfc85a71b784026e3ba5ef6
05f6395601d880499c8d074cb905e488
06ed53c37ed98e38c0e876e86eade551
0936c0d3b570f0845537de1eb9789a37
0fdfc7478c5ac8e6635b6eac845c86ec
10e07e9a1678d5d6a0cea12734bc2823
10ed518cc851aef9196a566d916961b6
1183d56764138d6dc62cc74eec9a571c
1339e82134c0da41a0d4e47e09ccfa11
150a67ba3a5e7a6a12ef70c45a24d189
166fcf0be322450a6431697b8824051e
1c9b9e0119c5ef975b69e9d13a63f6c9
1cfd2b74651e1c46b3d13cb38f11de30
1e37bafb524d678656f593b59240d9a4
2011f3d0d441fa7534126c5e6edd8e14
21345e3154d27a2b642410c6b85289ad
2286806547c7582aac75e037d564227e
23dccee843269d1dac84efe85d62e214
258ac25d939fc72cf35634b2773ff411
25ced9c6e47f90a2bd2d9ae4181f533f
2612d28cc89294aae069f3bdf4ae0bc7
2715a83b40bcf10d387c1add8bdb619f
27365a99b33910fed10d4304699b71aa
273b30472e9e7b0b59efb2573d9fb727
2751f0387dc5a6d75eacf544a075bfcb
285b450cc4d8eb088076eebb187ef915
28c418777878725215d280932f41ed47
2d57169596ea4ea49cbffb8dc8c91223
2dbafdfd2ea79d3ac3697daebda904b8
2e7d2f439f0d1ec2f1d9cc3ced65cf93
2f2017437f26632e41e0925a9b706b26
3030407a3a897cb79e2ed350866cc4f0
32568053ec7363187f4ec2dce9b2eecb
33e8f72c55972a3abd99ed6bbb275908
345cdc708b26d9c8f249e74384da
34b96e820067c0cfa56844279da3346b
34f2db2fbae6c6382102dd73444b4be6
3620b93fdf92223edaf36ee0d3dd7f79
373e1389bade3ef9bde30af1a2e4cd9e
3883f3370a534d9f51a4ad31c1b2fdf6
3adf1219508b9a69ef105624fb4a5d55
3afc3fa87ed45ced11359875d973ec30
3b8ff7c3f576f70adeedc38bb6570647
3c0cdcd022b28fae5a28f2c4ad799809
3c66cbd60de11f908732c7f095ee1b2a
3cb5d22552452b0148e87a3cb7c431f3
3daf65621edfa550913ba9f303bea6fc
3f329e034df78e15f13584e15255bb7a
3fbd6905b994a8b1908b2962afcd6a30
3ff6cc239738381c27a6f9cea546e779
40fdb2046825752098c490b0eecdf555
41470b171265f99895c6685b11047293
42cdb74a12513003d21e4f3411353f32
4412e075e9c3fd688456d4434418cadf
446364bc5884447e8b8aea233f7ae0bc
46939f2aaa3180a3c4d542d79f1ff828
47989c863bd591b7a8194eded00b0640
483030240284df5f3738a5375476182c
4a83ba5393ed329c6f3488cf8d872e61
4b1706c92ff7efb75fddbbccc1f20072
4c9778d8aa5bb9aaddcd6460d659a33a
4d0824627a77acfcf40cecbf90c66b2f
4d7fae798d142bef3b4d2ebb8df9e9b5
4f52792917af2ba8067344b275187ae3
4f88b267e125087b131a974de25eb39e
4fd4978b6fe1532e15c6065639f250f9
50629cf1e4bc58633f4f3448628819eb
510c89c867efa31d55354e7b4027c27f
5154726cd05db33ada39c0abbeec0103
51a4191cb35015b438325f64bd4b1d24
52c6674d6210a7fcb358a3369adb95f1
5402c9a8bcc42efa2667d3a43bd67078
54d12876511dcf424a55ba881b69cfa2
565afdcca629c972dbdb8a9e2198f4d6
56874f5e5aeb1b2c30987e0673cc4b28
56e4686325fd036bee6b088269d2ab8a
589e059fb25db3ecda9bfe76e08b3957
5aab3f1589ed4de4378c0d1782896f89
5ab5cec75772fb57216430e7af21f7f7
5d5689280c01513535af513a91414e57
5d8bb463bb35d5128c745f2a0c6be1ea
607cd521764bba22f60490c70a3e7d86
60ea5da2b15b5a6aa841daa02748c707
61ad1a9fa444ef82f3b69176a3ab
621ddceaf6597852c759972182c4f2b0
624d5a603eb66d76983c5a142141d13e
63315dede090d0a8b5d81f00fd706a2b
636e733b271e235f93ce7d6ccb884c5d
63fa3f8f27ea3071ece02172ba18ccf3
645ae31ebe6ee116

Re: [mailop] Just how does SendGrid fail this badly?

[Ángel via mailop]

On 2020-08-20 at 09:35 +0200, Hans-Martin Mosner via mailop wrote:
> Am 20.08.20 um 09:10 schrieb Benoit Panizzon via mailop:
> >
> > Return-Path: 
> >
> > Does the c581 part also belong to the account id?
> No, it's a short hash to verify that bounces were indeed caused by
> mails actually sent from sendgrid. For example,
>  and  +6019856-0d96-@sg.e.doodle.com> are doodle notifications
> sent to two different mail addresses. I don't know whether the time
> also takes part in the hash computation (as in SRS).

I see the same later part when the destination is the same recipient,
hours and even months later, so the time isn't computed there.
I thought that it might be an index of the "subscriber" into the
customer list.

The same account, spammed by different sendgrid accounts, has different
suffixes, but that's not surprising.

I don't get much sendgrid spam when compared with other people, but
today it was quite prolific:

17045745 - "you have been gifted $5 MILLION USD From Mr. Bill Gates" +
"CONGRATULATION TO YOU" (20 Italian billionaries donating money)
9364509 - "To prevent your email from closing, please verify your account 
details below"
13001617 - This is a plain-spam account. Today it was for
recharge-mobile.co spam, which mixes with a shop of earrings, bracelets, etc. 


Best regards


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

Re: [mailop] Just how does SendGrid fail this badly?

[Alan Hodgson via mailop]

On Tue, 2020-08-18 at 14:34 -0700, Carl Byington via mailop wrote:
> 
> dhl is asking folks to reject that mail, but sendgrid tries to send it
> anyway.
> 

Sendgrid doesn't seem to do any From: address authentication. They're sending
email pretending to be from all kinds of random domains.

I know they probably have customers that depend on being able to forge
addresses, but come on guys, it's 2020, you can't do that anymore.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail.tld DMARC record issue

[David Yost via mailop]

On 8/20/2020 5:24 AM, Bressier Simon via mailop wrote:

;; ANSWER SECTION:

_dmarc.hotmail.com .300INTXT"v=DMARC1;
p=none; rua=mailto:d...@rua.agari.com
;ruf=mailto:d...@ruf.agari.com
;fo=1:s:d"

_dmarc.hotmail.com .300INTXT"v=DMARC1;
p=reject; pct=100; rua=mailto:d...@rua.agari.com
; ruf=mailto:d...@ruf.agari.com
; fo=1"


This is being fixed right now.

Thanks,

David


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

Re: [mailop] Just how does SendGrid fail this badly?

[Brielle via mailop]

Oops, hit the send keybind by accident while trying to paste...  Lets 
try this again.



On 8/19/2020 11:06 PM, Philip Paeps via mailop wrote:

On 2020-08-18 20:23:37 (+0800), Atro Tossavainen via mailop wrote:

The SendGrid account sending these yesterday is 13999362.


The one I've seen most often is 12340469 with 9789821 a close second and 
8512936 in third place.


I just started seeing 2019535 this morning.  Luckily ClamAV's extra 
rules seem to be snagging it.



2020-08-20 10:18:57 1k8nHE-000881-PC 
H=wrqvprhc.outbound-mail.sendgrid.net [149.72.53.12] 
X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no 
F= rejected 
after DATA: This message contains a virus, trojan, phish, or banned 
attachment (Sanesecurity.Phishing.Fake.27094.UNOFFICIAL).



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

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

Re: [mailop] Just how does SendGrid fail this badly?

[Brielle via mailop]

On 8/19/2020 11:06 PM, Philip Paeps via mailop wrote:

On 2020-08-18 20:23:37 (+0800), Atro Tossavainen via mailop wrote:

The SendGrid account sending these yesterday is 13999362.


The one I've seen most often is 12340469 with 9789821 a close second and 
8512936 in third place.


I just started seeing




--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

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

[mailop] VERIZON Heads Up, SendGrid Phishing targetting your users

[Michael Peddemors via mailop]

Return-Path: 
Received: from wrqvcdpk.outbound-mail.sendgrid.net (HELO 
wrqvcdpk.outbound-mail.sendgrid.net) (149.72.205.49)


Subject: Your attention is urgently required.
From: Verizon 


--
"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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail.tld DMARC record issue

[Bressier Simon via mailop]

at least icloud and Verizon destinations are bouncing, there's always
a difference between RFC & reality

Le jeu. 20 août 2020 à 15:33, Ken O'Driscoll via mailop
 a écrit :
>
> Well, whoever’s responsible for the change control process that allowed that 
> CR through should probably care. And whoever who is responsible for a 
> codebase that evaluates multiple records as anything other than no record 
> should also probably care. But the RFC clearly states that multiple records 
> are not to be evaluated so this shouldn’t cause much drama, but who really 
> knows…
>
>
>
> Ken.
>
>
>
> From: Bressier Simon 
> Sent: Thursday 20 August 2020 14:18
> To: Ken O'Driscoll 
> Cc: Mailop 
> Subject: Re: [mailop] Hotmail.tld DMARC record issue
>
>
>
> so, you mean nothing wrong and nobody should care ?
>
>
>
> Le jeu. 20 août 2020 à 15:12, Ken O'Driscoll via mailop  a 
> écrit :
>
> More than one DMARC record is functionally equivalent to having no DMARC 
> record so this isn’t going to cause problems outside of incompetently written 
> code.
>
>
>
> Ken.
>
>
>
> From: mailop  On Behalf Of Bressier Simon via 
> mailop
> Sent: Thursday 20 August 2020 13:24
> To: mailop 
> Subject: [mailop] Hotmail.tld DMARC record issue
>
>
>
> Hi folks, just forwarding an email received on DMARC ML here, to see if 
> someone from Microsoft could fix quickly:
>
>
>
> Anyone from Microsoft in the list?
>
>
>
> Our monitoring system reported last night that Hotmail changed its DMARC 
> record and in the process a duplicate entry was created which might cause 
> unpredictable behaviour.
>
>
>
> ; <<>> DiG 9.10.6 <<>> txt _dmarc.hotmail.com
>
> ;; global options: +cmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23075
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
>
>
>
> ;; QUESTION SECTION:
>
> ;_dmarc.hotmail.com. IN TXT
>
>
>
> ;; ANSWER SECTION:
>
> _dmarc.hotmail.com. 300 IN TXT "v=DMARC1; p=none; 
> rua=mailto:d...@rua.agari.com;ruf=mailto:d...@ruf.agari.com;fo=1:s:d";
>
> _dmarc.hotmail.com. 300 IN TXT "v=DMARC1; p=reject; pct=100; 
> rua=mailto:d...@rua.agari.com; ruf=mailto:d...@ruf.agari.com; fo=1"
>
>
>
> This is the case for .com and all other TLDs.
>
>
>
> As I still have my 20-year-old Hotmail account I am an interested party :)
>
>
>
> Best,
>
> Randal
>
>
>
> --
>
> Randal Pinto
>
> Founder & COO
>
> +447703108205
>
> @randalpinto
>
>
>
> Red Sift is the power behind OnDMARC and OnINBOX.
>
> You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.
>
>
>
> Red Sift is a limited company registered in England and Wales. Registered 
> number: 09240956. Registered office: Kemp House, 152 City Road, London, EC1V 
> 2NX.
>
> ___
> 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] Hotmail.tld DMARC record issue

[Ken O'Driscoll via mailop]

Well, whoever’s responsible for the change control process that allowed that CR 
through should probably care. And whoever who is responsible for a codebase 
that evaluates multiple records as anything other than no record should also 
probably care. But the RFC clearly states that multiple records are not to be 
evaluated so this shouldn’t cause much drama, but who really knows…

 

Ken.

 

From: Bressier Simon  
Sent: Thursday 20 August 2020 14:18
To: Ken O'Driscoll 
Cc: Mailop 
Subject: Re: [mailop] Hotmail.tld DMARC record issue

 

so, you mean nothing wrong and nobody should care ?

 

Le jeu. 20 août 2020 à 15:12, Ken O'Driscoll via mailop mailto:mailop@mailop.org> > a écrit :

More than one DMARC record is functionally equivalent to having no DMARC record 
so this isn’t going to cause problems outside of incompetently written code.

 

Ken.

 

From: mailop mailto:mailop-boun...@mailop.org> > On 
Behalf Of Bressier Simon via mailop
Sent: Thursday 20 August 2020 13:24
To: mailop mailto:mailop@mailop.org> >
Subject: [mailop] Hotmail.tld DMARC record issue

 

Hi folks, just forwarding an email received on DMARC ML here, to see if someone 
from Microsoft could fix quickly:

 

Anyone from Microsoft in the list?

 

Our monitoring system reported last night that Hotmail changed its DMARC record 
and in the process a duplicate entry was created which might cause 
unpredictable behaviour.

 

; <<>> DiG 9.10.6 <<>> txt _dmarc.hotmail.com  

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23075

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;_dmarc.hotmail.com  . IN TXT

 

;; ANSWER SECTION:

_dmarc.hotmail.com  . 300 IN TXT "v=DMARC1; p=none; 
rua=mailto:d...@rua.agari.com  
;ruf=mailto:d...@ruf.agari.com  ;fo=1:s:d"

_dmarc.hotmail.com  . 300 IN TXT "v=DMARC1; 
p=reject; pct=100; rua=mailto:d...@rua.agari.com  ; 
ruf=mailto:d...@ruf.agari.com  ; fo=1"

 

This is the case for .com and all other TLDs.

 

As I still have my 20-year-old Hotmail account I am an interested party :) 

 

Best,

Randal

 

--

Randal Pinto

Founder & COO

+447703108205  

@randalpinto  

 

Red Sift is the power behind OnDMARC and OnINBOX.

You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.

 

Red Sift is a limited company registered in England and Wales. Registered 
number: 09240956. Registered office: Kemp House, 152 City Road, London, EC1V 
2NX.

___
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] Hotmail.tld DMARC record issue

[Bressier Simon via mailop]

so, you mean nothing wrong and nobody should care ?

Le jeu. 20 août 2020 à 15:12, Ken O'Driscoll via mailop 
a écrit :

> More than one DMARC record is functionally equivalent to having no DMARC
> record so this isn’t going to cause problems outside of incompetently
> written code.
>
>
>
> Ken.
>
>
>
> *From:* mailop  *On Behalf Of *Bressier Simon
> via mailop
> *Sent:* Thursday 20 August 2020 13:24
> *To:* mailop 
> *Subject:* [mailop] Hotmail.tld DMARC record issue
>
>
>
> Hi folks, just forwarding an email received on DMARC ML here, to see if
> someone from Microsoft could fix quickly:
>
>
>
> Anyone from Microsoft in the list?
>
>
>
> Our monitoring system reported last night that Hotmail changed its DMARC
> record and in the process a duplicate entry was created which might cause
> unpredictable behaviour.
>
>
>
> ; <<>> DiG 9.10.6 <<>> txt _dmarc.hotmail.com
>
> ;; global options: +cmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23075
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
>
>
>
> ;; QUESTION SECTION:
>
> ;_dmarc.hotmail.com. IN TXT
>
>
>
> ;; ANSWER SECTION:
>
> _dmarc.hotmail.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:
> d...@rua.agari.com;ruf=mailto:d...@ruf.agari.com;fo=1:s:d";
>
> _dmarc.hotmail.com. 300 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:
> d...@rua.agari.com; ruf=mailto:d...@ruf.agari.com; fo=1"
>
>
>
> This is the case for .com and all other TLDs.
>
>
>
> As I still have my 20-year-old Hotmail account I am an interested party :)
>
>
>
> Best,
>
> Randal
>
>
>
> --
>
> Randal Pinto
>
> Founder & COO
>
> +447703108205
>
> @randalpinto 
>
>
>
> Red Sift is the power behind OnDMARC and OnINBOX.
>
> You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.
>
>
>
> Red Sift is a limited company registered in England and Wales. Registered
> number: 09240956. Registered office: Kemp House, 152 City Road, London,
> EC1V 2NX.
>
> ___
> 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] Hotmail.tld DMARC record issue

[Ken O'Driscoll via mailop]

More than one DMARC record is functionally equivalent to having no DMARC record 
so this isn’t going to cause problems outside of incompetently written code.

 

Ken.

 

From: mailop  On Behalf Of Bressier Simon via mailop
Sent: Thursday 20 August 2020 13:24
To: mailop 
Subject: [mailop] Hotmail.tld DMARC record issue

 

Hi folks, just forwarding an email received on DMARC ML here, to see if someone 
from Microsoft could fix quickly:

 

Anyone from Microsoft in the list?

 

Our monitoring system reported last night that Hotmail changed its DMARC record 
and in the process a duplicate entry was created which might cause 
unpredictable behaviour.

 

; <<>> DiG 9.10.6 <<>> txt _dmarc.hotmail.com  

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23075

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;_dmarc.hotmail.com  . IN TXT

 

;; ANSWER SECTION:

_dmarc.hotmail.com  . 300 IN TXT "v=DMARC1; p=none; 
rua=mailto:d...@rua.agari.com  
;ruf=mailto:d...@ruf.agari.com  ;fo=1:s:d"

_dmarc.hotmail.com  . 300 IN TXT "v=DMARC1; 
p=reject; pct=100; rua=mailto:d...@rua.agari.com  ; 
ruf=mailto:d...@ruf.agari.com  ; fo=1"

 

This is the case for .com and all other TLDs.

 

As I still have my 20-year-old Hotmail account I am an interested party :) 

 

Best,

Randal

 

--

Randal Pinto

Founder & COO

+447703108205  

@randalpinto  

 

Red Sift is the power behind OnDMARC and OnINBOX.

You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.

 

Red Sift is a limited company registered in England and Wales. Registered 
number: 09240956. Registered office: Kemp House, 152 City Road, London, EC1V 
2NX.

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

[mailop] Hotmail.tld DMARC record issue

[Bressier Simon via mailop]

Hi folks, just forwarding an email received on DMARC ML here, to see if
someone from Microsoft could fix quickly:

Anyone from Microsoft in the list?
>
> Our monitoring system reported last night that Hotmail changed its DMARC
> record and in the process a duplicate entry was created which might cause
> unpredictable behaviour.
>
> ; <<>> DiG 9.10.6 <<>> txt _dmarc.hotmail.com
>
> ;; global options: +cmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23075
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
>
>
> ;; QUESTION SECTION:
>
> ;_dmarc.hotmail.com. IN TXT
>
>
> ;; ANSWER SECTION:
>
> _dmarc.hotmail.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:
> d...@rua.agari.com;ruf=mailto:d...@ruf.agari.com;fo=1:s:d";
>
> _dmarc.hotmail.com. 300 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:
> d...@rua.agari.com; ruf=mailto:d...@ruf.agari.com; fo=1"
>
> This is the case for .com and all other TLDs.
>
> As I still have my 20-year-old Hotmail account I am an interested party :)
>
> Best,
> Randal
>
> --
> Randal Pinto
> Founder & COO
> +447703108205
> @randalpinto 
>
> Red Sift is the power behind OnDMARC and OnINBOX.
>
> You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.
>
>
> Red Sift is a limited company registered in England and Wales. Registered
> number: 09240956. Registered office: Kemp House, 152 City Road, London,
> EC1V 2NX.
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sophos appliance reject mails from specific domains with Administrative prohibition, confirmed spam in logs

[Olivier Depuydt via mailop]

Hello.

You need to contact Sophos support (through) their website.
They are using an internal list on their equipment in addition to the
regular public blacklists.


Best regards,

Olivier

Le jeu. 20 août 2020 à 10:58, Stefan Bauer via mailop  a
écrit :

> Hi,
>
>
> since days, we try to find out why one of our customer domain is blocked,
> when sending mails to remote sites, where Sophos UTM-appliance (e.g.
> UTM-430) are in place.
>
>
> All we see is at smtp level:
>
>
> : host mail3.famo24.de[80.155.146.58] said: 550
> Administrative prohibition (in reply to end of DATA command)
>
>
> Recipients (admins) confirm, that according to local FW logs, they see
> 'confirmed spam'.
>
>
> All of our sending IPs are in no blacklist nor have been over the last
> years.
>
>
> I checked all the known blacklists. Even cyrens own site. All is green and
> good.
>
>
> One of our sending IPs is 116.203.31.6
>
>
> Anyone with an idea?
>
>
> Thank you.
>
>
> Stefan
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 

Olivier Depuydt

Site Reliability Engineer


Web   |  Blog 
  |  Linkedin   |  Twitter
  |  Facebook











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

Re: [mailop] Mailman confirmation email denial of service

[Marlen Caemmerer via mailop]

Hey,

my initial check was
Aug 18 09:50:53 2020 (7596) berlin: pending lywlo...@gmail.com  202.211.87.136

The IP comes from Japan with the same user agent.

These were the next requests on my host:

Aug 18 10:36:56 2020 (14780) kamikaze: pending fislisrb...@outlook.com  
182.30.40.234
Aug 18 12:33:57 2020 (32629) kamikaze: pending mmc49...@eoopy.com  45.73.162.51
Aug 18 12:33:58 2020 (32634) kamikaze: pending mmc49...@eoopy.com  216.155.42.95
Aug 18 12:33:59 2020 (32635) kamikaze: pending mmc49...@eoopy.com  45.73.166.236
Aug 18 12:42:51 2020 (1734) kamikaze: pending mmc49...@eoopy.com  155.254.54.66
Aug 18 12:43:00 2020 (1748) berlin: pending mmc49...@eoopy.com  67.207.184.189
Aug 18 12:43:20 2020 (1749) berlin: pending mmc49...@eoopy.com  67.219.20.59
Aug 18 12:48:09 2020 (2497) kamikaze: pending mmc49...@eoopy.com  204.52.99.88
Aug 18 12:48:13 2020 (2505) kamikaze: pending mmc49...@eoopy.com  66.78.4.230
Aug 18 12:48:23 2020 (2513) kamikaze: pending mmc49...@eoopy.com  67.227.40.39
Aug 18 12:48:34 2020 (2517) science: pending mmc49...@eoopy.com  173.46.93.106

I looked up the user agent and it seems there is a javascript library Axios 
that can do HTTP requests und may be used with nodejs or from a browser.
I am quite impressed by the many different IP addresses that are used and I 
wonder if something like this could be catched with XBL.
Probably next time I will consider monitoring the number of pending 
subscription requests by the mailman log file and take down the mailman web 
interface until I could figure out what else to do.


Cheers
nosy



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

Re: [mailop] [EXTERNAL] Re: Mailman confirmation email denial of service

[Jim Popovitch via mailop]

On Thu, 2020-08-20 at 09:43 +0800, Philip Paeps via mailop wrote:
> On 2020-08-20 05:17:09 (+0800), Michael Wise via mailop wrote:
> > BotNet?
> > Were they listed in the SpamHaus XBL as being compromised?
> 
> The problem is that the subscriptions come in through the Mailman web 
> interface, not through email.
> 
> Arguably, this is a variant of the old "send an email greeting card" 
> spam.
> 
> I don't know of anyone who checks the XBL (or other blocklists) on the 
> web server.  Or if that would even be effective.  Does the XBL list 
> botnets that abuse web services that lead to email being sent too?  This 
> may actually be an interesting hack to perpetrate. :)

You should probably also know about these 2 additional MM settings:

BLOCK_SPAMHAUS_LISTED_IP_SUBSCRIBE = Yes
BLOCK_SPAMHAUS_LISTED_DBL_SUBSCRIBE = Yes


-Jim P.



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

[mailop] Sophos appliance reject mails from specific domains with Administrative prohibition, confirmed spam in logs

[Stefan Bauer via mailop]

Hi,



since days, we try to find out why one of our customer domain is blocked, when 
sending mails to remote sites, where Sophos UTM-appliance (e.g. UTM-430) are in 
place.



All we see is at smtp level:



: host mail3.famo24.de[80.155.146.58] said: 550
    Administrative prohibition (in reply to end of DATA command)



Recipients (admins) confirm, that according to local FW logs, they see 
'confirmed spam'.



All of our sending IPs are in no blacklist nor have been over the last years.



I checked all the known blacklists. Even cyrens own site. All is green and good.



One of our sending IPs is 116.203.31.6



Anyone with an idea?



Thank you.



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

Re: [mailop] Just how does SendGrid fail this badly?

[Atro Tossavainen via mailop]

> Does the c581 part also belong to the account id?

I think it does.

> I might consider trying to extract this on my spamtrap and collect them
> to see if there are accounts that keep sending phishing emails for long
> times.

Top senders in Koli-Lõks traps yesterday (n>7000):

8512936 (5%) - multiple types of phishing
9711754 (3%) - multiple types of phishing
4468541 (3%) - Uber
8807282 (2%) - multiple types of phishing
1365613 (2%) - Jockey Comfort

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/

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

Re: [mailop] Just how does SendGrid fail this badly?

[Hans-Martin Mosner via mailop]

Am 20.08.20 um 09:10 schrieb Benoit Panizzon via mailop:
>
> Return-Path: 
>
> Does the c581 part also belong to the account id?
No, it's a short hash to verify that bounces were indeed caused by mails 
actually sent from sendgrid. For example,
 and 
 are doodle notifications
sent to two different mail addresses. I don't know whether the time also takes 
part in the hash computation (as in SRS).
>
> I might consider trying to extract this on my spamtrap and collect them
> to see if there are accounts that keep sending phishing emails for long
> times.

Probably not. Most that I've seen lately seem to be web form submission 
auto-responses, and it looks like customers get
a notice to fix that and maybe even do it.

Cheers,
Hans-Martin



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

Re: [mailop] Mailman confirmation email denial of service

[Hans-Martin Mosner via mailop]

After having thwarted additional attacks (thanks for the hint about 
SUBSCRIBE_FORM_SECRET!) I looked at our mailman logs
to see if everything is quiet now, and to find patterns.

Apparently the initial check was from a serbian IP address:

Aug 18 10:01:55 2020 (8184) : pending mmc49...@eoopy.com  
37.221.182.184

The mail address has md5sum 8161d22688eab8dd557aec1fd32192b7, so it's the same 
that you (Andy) saw 14 times, so it's
likely that this address was the one used by the spammer to confirm that his 
scheme works.

After that check, the other stupidly publicly advertised lists at our small 
site were tested with the same address, one
was tested with another address at the same domain, and then a few minutes 
later the bot started to "register" victims.

eoopy.com seems to be a domain used by 10minutemail.net to provide time-limited 
e-mail addresses. I don't think they
would be willing or able to share information on who registered this mail 
address (it's all automated and like most
anonymizing services they won't keep logs so LE can't force them to hand them 
over).

Thinking up a specialized defense against this attack (just as keeping a list 
of such domains) is probably overkill, so
this analysis is just here to possibly help understand what spammers do to 
circumvent anti-spam measures. We can't
foresee what they come up with next, but we can react and harden our systems 
quickly.

Cheers,
Hans-Martin



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

Re: [mailop] Just how does SendGrid fail this badly?

[Benoit Panizzon via mailop]

Am Tue, 18 Aug 2020 11:01:19 -0700
schrieb Luke via mailop :

> In the Return-Path. "bounces+1234567" the number following bounces+ is the
> SendGrid account ID.

Return-Path: 

Does the c581 part also belong to the account id?

I might consider trying to extract this on my spamtrap and collect them
to see if there are accounts that keep sending phishing emails for long
times.

What I also wonder: How is a customer required to identify himself
@sendgrid before he can start sending emails?

Did they start providing 'testing' accounts which don't require any
kind of identification and which can be automatically mass created via
an API or similar.

(Yes, they just could go on a run an open smtp relay then :-) )

I know Mailchimp ran into a similar issue some time ago, but it looks
like they managed to solve that problem.

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop