[mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Andrew C Aitchison via mailop]

https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890#tls-10-11-and-dtls-10-are-forcefully-disabled-13
(which is mostly a template) suggests that TLS 1.0, 1.1 and DTLS 1.0 are 
"forcefully disabled" in the upcoming Ubuntu release

(due next month at a guess).
Apparently this is not new for openssl, but it is for gnutls.

Given that the advice for SMTP is often to allow tls 1.0 and 1.1,
rather than have it revert to unencrypted, this will is something to
watch out for.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailbox Filling w. Opt-In/Sign-Up mails

[Michael Peddemors via mailop]

Tobias,

This does sound like a typical 'mail bomb', and there are even services 
you can rent to mail bomb an enemy..


Used to only see it in the gamer community, kid stuff.. but it is more 
rare than you think.. sometimes it can go on for several days..


Usually, someone has p**'ed off someone..

Lot's of single sign on mailing lists, and poorly written contact forms 
are abused in a script kiddie style run..


Have to look at examples to be sure.. (feel free to share off list)..

Like I said, a lot more rare than you think, but a pain when it happens.

On 2024-03-12 11:19, Tobias Fiebig via mailop wrote:

Moin,

over the past 2-3 weeks, I saw a slightly more filled queue for email-
security-scans.org; A lot of users seemed to start tests, but never
received the corresponding test mails; In most cases, the ESP hat
shutdown delivery to these inboxes due to a sudden high volume of
inbound messages, with most addresses hosted being under @gmail.com
(and some outlook.com/yahoo.com as well).

A bit of digging found several end-user reports of the following MO:

- Get phished
- Something expensive is bought
- Mailbox is overflown right when the notification of the transaction
comes, likely in a bid to hide the illicit purchase

Naturally, there now have been some 'adjustments' to the service to
make sure it no longer contributes to that... and maybe finds some
insight into what is happening there... *loglog*

However, I'd be interested in hearing whether I had just missed some
very common spam reason here; So:

- Did somebody else stumble over this in the past and/or did i simply
miss this being a thing?
- How is this handled for, e.g., all the other tools that allow
generating "a lot" of mail only needing a request (signups in general,
ticket systems, [...])? I never saw something like this (on my own or
others systems), even when dealing with services equally easy to
motivate into mailsending.

With best regards,
Tobias

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



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

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

[mailop] Mailbox Filling w. Opt-In/Sign-Up mails

[Tobias Fiebig via mailop]

Moin,

over the past 2-3 weeks, I saw a slightly more filled queue for email-
security-scans.org; A lot of users seemed to start tests, but never
received the corresponding test mails; In most cases, the ESP hat
shutdown delivery to these inboxes due to a sudden high volume of
inbound messages, with most addresses hosted being under @gmail.com
(and some outlook.com/yahoo.com as well).

A bit of digging found several end-user reports of the following MO:

- Get phished
- Something expensive is bought
- Mailbox is overflown right when the notification of the transaction
comes, likely in a bid to hide the illicit purchase

Naturally, there now have been some 'adjustments' to the service to
make sure it no longer contributes to that... and maybe finds some
insight into what is happening there... *loglog*

However, I'd be interested in hearing whether I had just missed some
very common spam reason here; So:

- Did somebody else stumble over this in the past and/or did i simply
miss this being a thing?
- How is this handled for, e.g., all the other tools that allow
generating "a lot" of mail only needing a request (signups in general,
ticket systems, [...])? I never saw something like this (on my own or
others systems), even when dealing with services equally easy to
motivate into mailsending.

With best regards,
Tobias

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

Re: [mailop] Microsoft heads-up - Outlook Deliverability Support not working

[Fernando MM via mailop]

Hello,

On Tue, Mar 12, 2024 at 1:16 PM Allen Kevorkov via mailop 
wrote:

> Hey folks,
>
> I don't know if it's just us, but I've been getting "we're experiencing
> technical difficulties" response for a number of tickets submitted to
> Outlook.com deliverability support. We're unable to get any issues
> resolved. If someone could *please *help, it would be greatly
> appreciated. This has been going on for a week now (since about 3/6).
>

I'm also experiencing this.

Replying to the "we're experiencing technical difficulties" email seems to
create the ticket as usual and I receive a reply after a few hours.

Regards,

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

Re: [mailop] Microsoft heads-up - Outlook Deliverability Support not working

[Florian Effenberger via mailop]

Hello,

Allen Kevorkov via mailop wrote on 12.03.24 at 16:41:
I don't know if it's just us, but I've been getting "we're experiencing 
technical difficulties" response for a number of tickets submitted to 
Outlook.com deliverability support. We're unable to get any issues 
resolved. If someone could /please /help, it would be greatly 
appreciated. This has been going on for a week now (since about 3/6).


I've filed a ticket just last Friday that was acted on over the weekend, 
so it doesn't seem a general issue at least.


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

[mailop] Microsoft heads-up - Outlook Deliverability Support not working

[Allen Kevorkov via mailop]

Hey folks,
I don't know if it's just us, but I've been getting "we're experiencing 
technical difficulties" response for a number of tickets submitted to 
Outlook.com deliverability support. We're unable to get any issues resolved. If 
someone could please help, it would be greatly appreciated. This has been going 
on for a week now (since about 3/6).
Critical ticket numbers are 7036876013, 7036875823, and 7036893290
Thank you.
~Allen K



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

Re: [mailop] Love how people use SPF records.. Just for a chuckle..

[Jan Schaumann via mailop]

Michael Peddemors via mailop  wrote:
> host -t TXT save.ca
> 
> save.ca descriptive text "v=spf1 ip4:70.33.236.0/25  mx a
> include:sendgrid.net include:thestar.ca include:thestar.com
> include:spf.google.com include:spf.protection.outlook.com
> include:spf.yahoo.com include:spf.aol.com include:amazonses.com -all"
> 
> ... so.. basically hard block everything except 1/2 the internet..

If you're into that sort of thing, I wrote about all
the weird aspects of SPF here:

https://www.netmeister.org/blog/spf.html

I also have a tool that sums all the findings of a
domain's SPF record:

https://github.com/jschauma/spf/

---
Sample output:

$ spf save.ca
save.ca:
  policy:
ip4:70.33.236.0/25 mx a include:sendgrid.net include:thestar.ca 
include:thestar.com
[...]

  invalid
Warning: SPF record for "_ssf2f3yot2.sdmarc.net" too long (491 > 450).
Warning: No MX record for domain 'ironport2.thestar.ca' found.
[...]

  pass:
include (8 domains):
  amazonses.com
  sendgrid.net
  [...]

[...]

Total counts:
  Total # of DNS lookups: 32

  pass:
Total # of 'a' directives   : 2
Total # of 'exists' directives  : 2
Total # of 'include' directives : 23
Total # of 'mx' directives  : 6
Total # of 'redirect' directives: 1
Total # of ip4 directives   : 167
Total # of ip4 addresses: 962,349
Total # of ip6 directives   : 15
Total # of ip6 addresses: 11,862,603,051,712,622,486,355,973

All others: fail

---

(Sorry for the self-promotion here, but it seemed of
relevance to the discussion.)

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

Re: [mailop] Rejected by bounce verification

[Slavko via mailop]

Dňa 12. marca 2024 11:53:39 UTC používateľ Marco Moock via mailop 
 napísal:

>Is it ok that Listserv behaves like that?

I don't use fortinet at all, but all bounces (empty MAIL FROM:)
will be rejected here, if they fail BATV (prvs=) verification.

AFAIK, bounces have go to Return-Path:, not to From: address.

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Rejected by bounce verification

[Marco Moock via mailop]

Hello!

We had the situation that we got mail that wasn't RFC-compliant and our
listserv rejected it.

MAIL From: 

Listserv replies to the From: header and not to the Return-Path.
It doesn't see MAIL FROM because the mail is being piped to the
application, but it could use Return-Path.
MAIL FROM: <> is being used, so it is being detected as a bounce.

Is my guess right that this is the FortiNet bounce verification system?
https://help.fortinet.com/fmail/archives/3_0/fortimail-admin/wwhelp/wwhimpl/common/html/wwhelp.htm?context=FortiMail_Online_Help=FortiMail_Online_Help-12-38.html

Is it ok that Listserv behaves like that?

-- 
kind regards
Marco

Send spam to 1710243634mu...@cartoonies.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Love how people use SPF records.. Just for a chuckle..

[Benny Pedersen via mailop]

Michael Peddemors via mailop skrev den 2024-03-11 23:54:

host -t TXT save.ca



... so.. basically hard block everything except 1/2 the internet..


the other half is "v=spf1 +all" ? :)

if one likes no maintained ranges

225 netblocks are authorized
2,583,457 individual IPv4 addresses

i did not count ipv6

34 / 10
DNS-querying mechanisms / modifiers to resolve the record

Duplicate netblock authorization

The following netblocks have been authorized more than once. Duplicates 
usually indicate inefficient records or redundant "include" mechanisms, 
and should be removed.

NetblockOccurrences
170.10.146.242/32   4
170.10.144.242/32   4
40.92.0.0/154
40.107.0.0/16   4
52.100.0.0/14   4
104.47.0.0/17   4
199.255.192.0/223
199.127.232.0/223
69.169.224.0/20 3
23.249.208.0/20 3
23.251.224.0/19 3
76.223.176.0/20 3
52.82.172.0/22  3
76.223.128.0/19 3
216.221.160.0/193
142.250.141.27/32   2
192.206.144.0/212
74.205.174.24/322
76.74.201.32/27 2
54.240.0.0/18   2
54.240.64.0/19  2
54.240.96.0/19  2
205.139.104.0/222
216.235.196.0/222
216.235.200.0/212

oh well :)

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

Re: [mailop] Love how people use SPF records.. Just for a chuckle..

[Stefano Bagnara via mailop]

On Tue, 12 Mar 2024 at 00:01, Michael Peddemors via mailop
 wrote:
> save.ca descriptive text "v=spf1 ip4:70.33.236.0/25  mx a
> include:sendgrid.net include:thestar.ca include:thestar.com
> include:spf.google.com include:spf.protection.outlook.com
> include:spf.yahoo.com include:spf.aol.com include:amazonses.com -all"
> [...]
> I assume someone that likes spamming set THAT one up.. there is a good
> reason that SPF have a maximum DNS amount of queries..

Their record requires 35 DNS lookups to be completely evaluated :-)

The "include:thestar.ca" alone uses 15 DNS lookups (I wonder if they
suggest anyone to use this include or if this is a mistake from
save.ca).

Anything after include:thestar.ca (and also part of this included
record) will be ignored and result in permerror, so their record
equals to "v=spf1 ip4:70.33.236.0/25  mx a include:sendgrid.net
include:thestar.ca -all".

Maybe the RFC could have defined to return *fail* instead of permerror
when you can detect the record will need more than 10 DNS lookups just
looking at it (like this one: you don't even need to recurse into the
includes to know this record requires more than 10 lookups).

I don't think this is an indicator of a spammy sender: spammer are
usually good at understanding how to propertly authenticate their
emails. I saw similar SPF records with too many lookup and invalid
hosts in many domains where the sysadmin probably saw a couple of SPF
records and thinks he master SPF and fixes any deliverability issues
by adding new include there, as it worked the first time.

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

Re: [mailop] Love how people use SPF records.. Just for a chuckle..

[Alessandro Vesely via mailop]

Further than trimming, they should consider using neutral qualifiers for 
generic mail sites.  "include:spf.protection.outlook.com" can allow 
office users to fully impersonate the save.ca domain.  Setting 
"?include:spf.protection.outlook.com" provides for not rejecting due to 
-all, while not granting "pass".


Best
Ale

On 12/03/2024 03:01, Suresh Ramasubramanian wrote:
This looks more like they’ve been testing several providers and ended up 
with a large spf record that they might want to consider trimming.


--srs

*From:* mailop  on behalf of Michael 
Peddemors via mailop 

*Sent:* Tuesday, March 12, 2024 4:24:03 AM
*To:* mailop@mailop.org 
*Subject:* [mailop] Love how people use SPF records.. Just for a chuckle..
host -t TXT save.ca

save.ca descriptive text "v=spf1 ip4:70.33.236.0/25  mx a
include:sendgrid.net include:thestar.ca include:thestar.com
include:spf.google.com include:spf.protection.outlook.com
include:spf.yahoo.com include:spf.aol.com include:amazonses.com -all"

... so.. basically hard block everything except 1/2 the internet..

I assume someone that likes spamming set THAT one up.. there is a good
reason that SPF have a maximum DNS amount of queries..

#   69.39.224.72   2   serviciodeestudios.bbva.com
#   69.39.224.73   2
materialsresearchinstitute.northwestern.edu
#   69.39.224.75   3   serviciodeestudios.bbva.com
#   69.39.224.77   2   email.save.ca
#   69.39.224.78   2   libetwitt.liberation.fr
#   69.39.224.79   1   producteursdici.intermarche.com
69.39.224.72/29

No need to comment more of course..



--
"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 Reg. TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop 



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

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