Re: [mailop] Pretty convincing ICANN renewal notice making the rounds..

[Bill Cole via mailop]

On 2022-03-21 at 15:28:28 UTC-0400 (Mon, 21 Mar 2022 20:28:28 +0100)
Sebastian Nielsen via mailop 
is rumored to have said:

Im talking about matching MAIL FROM (which is hidden from user, but 
authenticated via SPF/DKIM)


DKIM does not authenticate the MAIL FROM (envelope sender) address. It 
provides proof that the message body and selected headers have not 
changed on the transport path between the identified signer and the 
recipient. DKIM is strictly about the message data NOT its transport.


to the MIME FROM ("From:" header in MIME data), thus guaranteeing that 
the address shown in From: is also a authenticated address.


See DMARC. DMARC is how DKIM can be used to authenticate a From header 
address. If the From header address domain aligns to the envelope sender 
domain, SPF can be used to authenticate both under DMARC.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Pretty convincing ICANN renewal notice making the rounds..

[Bill Cole via mailop]

On 2022-03-21 at 14:43:46 UTC-0400 (Mon, 21 Mar 2022 19:43:46 +0100)
Sebastian Nielsen via mailop 
is rumored to have said:

The best solution I would propose, is that Email should slowly 
transitition to a requirement that the address inside "MAIL FROM:" and 
"From:" header in mime data, *must* exactly match.


Ridiculous. Solves nothing, breaks much.

The SMTP envelope sender addressis where handling errors go. The From 
header address is where MUAs should usually send replies. They serve 
necessarily distinct functions.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Pretty convincing ICANN renewal notice making the rounds..

[Bill Cole via mailop]

Pretty convincing??? To whom ?

I cannot be the only one who is instantly de-convinced by English text 
that was clearly not written by a native English speaker.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Multi-Party Delivery Issues to Microsoft

[Michael Wise via mailop]

To discuss? No.

Recipient needs to open a bug with Customer Support.



But please keep in mind that voicemail to email gateways are a common 
smokescreen for phish and malware.

It's become somewhat of a nuisance.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Open a ticket for Hotmail ?



-Original Message-
From: mailop  On Behalf Of Rob Heilman via mailop
Sent: Monday, March 21, 2022 1:59 PM
To: Mailop List 
Subject: [EXTERNAL] [mailop] Multi-Party Delivery Issues to Microsoft



Is Michael or anyone else on the list from Microsoft available to discuss a 
delivery issue we are having to Microsoft hosted domains?  The short, short 
version is that users on Microsoft/Outlook/O365 services are not getting legit 
messages from Voicemail-to-Email mail flows.  The messages are accepted by MS, 
but the users are having issues finding them with varying symptoms: Junk 
Folder, Quarantine, unable to find at all, etc.



Thanks,

Rob Heilman





___

mailop mailing list

mailop@mailop.org

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailopdata=04%7C01%7Cmichael.wise%40microsoft.com%7C390e57d6a1aa4583523308da0b7e855d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637834935296733614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=kovNICGTh%2BFdDtKmsMchzL%2Buww1R4rxl3dEz3kje1s4%3Dreserved=0
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Multi-Party Delivery Issues to Microsoft

[Rob Heilman via mailop]

Is Michael or anyone else on the list from Microsoft available to discuss a 
delivery issue we are having to Microsoft hosted domains?  The short, short 
version is that users on Microsoft/Outlook/O365 services are not getting legit 
messages from Voicemail-to-Email mail flows.  The messages are accepted by MS, 
but the users are having issues finding them with varying symptoms: Junk 
Folder, Quarantine, unable to find at all, etc.

Thanks,
Rob Heilman


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

Re: [mailop] Pretty convincing ICANN renewal notice making the rounds..

[Sebastian Nielsen via mailop]

>>Seriously? Using Hotmail/Google is NOT FREE.. 

It is. They earn the money on ads, but the ad cost cannot swallow a fine. That 
would mean they would need some way to reimburse the fine from the end user, 
meaning you would need to have a credit rating as it would count as a loan 
agreement, requiring a valid credit check. (In the same way you need a credit 
check to hire a car, since a scratch or buckle in the exterior must be 
reimbursed).
So yes, it would actually kill the free email services. 

>>Accurate MAIL FROM (matching the actual authenticated user)

Im not talking about matching MAIL FROM to a authenticated login or password. 
That’s up to the service provider, as long as its not a open relay, its fine 
for me. If the mail provider wants to tie it to windows login, or even a 
building login or whatever, or allow any email that the company owns, its fine 
for me. That’s a responsibility the service provider has against its users, to 
make sure they cannot cross-phish (like us...@example.com sending as 
us...@example.com ) IF the users are untrusted. For employees in a normal 
company, they can usually be trusted and no MAIL FROM <--> AUTH checking is 
required.

Im talking about matching MAIL FROM (which is hidden from user, but 
authenticated via SPF/DKIM) to the MIME FROM ("From:" header in MIME data), 
thus guaranteeing that the address shown in From: is also a authenticated 
address.

>>But yes, small screen real estate, and 'user friendly' concepts have made it 
>>so that end users are more easily fooled

Yeah, but its stupid that those MUAs then choose to show the name more 
prominently than the email, so even local validation don't work and you can 
easily write:

From: customerserv...@mybank.tld 

And fool the user. The email address is whats authenticated, so show that?
However, if the email is in the user's contact book, it makes sense to show the 
contact name, not the written name in name field.
Like with phone numbers.

And if user manually adds the email as the contact, the name written in the 
name field can be a auto-suggestion.

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

Re: [mailop] Pretty convincing ICANN renewal notice making the rounds..

[Michael Peddemors via mailop]

On 2022-03-21 11:43, Sebastian Nielsen via mailop wrote:

  But if Microsoft got fined for every phishing email that escaped


This would QUICKLY kill every free email service, and every email service would 
become pay-only, to cope with the fines. Propably with obligation-to-pay 
contracts too, so they can forward the fine down to the user that sent the spam 
(Meaning you would need to have a credit rating to be able to use email, 
meaning those on social security without income wouldn't be able to get email, 
as you would need to be able to get a credit card, to get email).

The best solution I would propose, is that Email should slowly transitition to a requirement that 
the address inside "MAIL FROM:" and "From:" header in mime data, *must* exactly 
match.

And a standard that MUAs (including mobile MUAs) must clearly show the email 
address more prominently than the name of sender, UNLESS the user positively 
have added the sender into contact book. (In the same way that browsers now 
show the SLD and TLD in another highlighted color prominently to combat 
phishing in the form of mybank.tld.somephishingdomain.tld variant of phish)



Seriously? Using Hotmail/Google is NOT FREE.. (Havent' seen the number 
lately, but was somewhere around $2/3 dollars a mailbox Gmail claimed to 
be making I seem to recall)


They can afford to spend more money on outbound spam/threat detection.

Accurate MAIL FROM (matching the actual authenticated user) is always a 
good recommendation, but there are many reasons that can't work, as the 
From header represents an 'identity' and not the user..


What was Digital Ocean's recent market cap?

But yes, small screen real estate, and 'user friendly' concepts have 
made it so that end users are more easily fooled.. But the email 
providers have a role to play in ensuring those kinds of forgeries don't 
get in front of the users.


And Banks who use a 3rd party sender that doesn't clearly identify 
themselves, or an AWS instance that doesn't have reverse DNS, I mean 
really?  Are we THAT short of talented engineers?


In the end, it isn't the Bank that suffers, it is the end user.. "Well, 
that transfer occurred from your phone".








--
"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] Pretty convincing ICANN renewal notice making the rounds..

[Jarland Donnell via mailop]

Is this another one of those "research" things where someone does evil 
and then claims to have good motives? That website renam.md kind of 
seems like it.


On 2022-03-21 11:57, Michael Peddemors via mailop wrote:

Authenticated from FastHosts..

Source:

Received: from mail.renam.md (HELO mail.renam.md) (81.180.84.189)


___
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] Pretty convincing ICANN renewal notice making the rounds..

[Sebastian Nielsen via mailop]

Of course its important to check WHO is sending the email too, not just that 
its signed.

The email is obviously not from ICANN. Of course it authenticates correctly as 
the sender it claims to be, as that’s the truth.

 

Authentication – checking that something is true and not false.

For example, I claim who I am, and show ID to authenticate myself.

Lack of Authentication means I can falsely claim to be someone else.

 

But there is another important step:

Authorization – checking that the claimed identity have the authority to do 
whatever its asking for.

For example, Im authorized to pass the guard with my credentials.

Lack of Authorization means I can simply use my own identity to enter the 
building without permission to do so.

 

So a Authentication with lack of Authorization, means I can use my own real, 
validated and signed identity, to do something I should not do.

And Authorization with lack of Authentication, means I can falsely claim 
someone else’s identity to use someone’s elses Authorization.

 

Its important to combine them both. Both check that its Authenticated (someone 
hasn’t spoofed the email) but also Authorization (Make sure the email actually 
is sent by the person that you expect it to be from).

 

And Authorization is something only the receiver of the email can do, as only 
he knows if the content of the email is relevant for the sender of the email.

So it’s a fault of the receiver if he believes “ secri...@renam.md 
  “ is actually ICANN.

 

 

Från: Mark E. Jeftovic via mailop  
Skickat: den 21 mars 2022 18:21
Till: mailop@mailop.org
Ämne: Re: [mailop] Pretty convincing ICANN renewal notice making the rounds..

 

I said years ago, when these policies came out (WDRP and then WAP) that they 
would accomplish nothing other than to provide a gift-wrapped phishing 
mechanism.

- mark

On 2022-03-21 12:57 PM, Michael Peddemors via mailop wrote:

Authenticated from FastHosts.. 

Source: 

Received: from mail.renam.md (HELO mail.renam.md) (81.180.84.189) 






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

-- 
Mark E. Jeftovic   
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor 

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

Re: [mailop] expected bounces from Russia?

[Collider via mailop]

A Russian government agency tasked with implementing the block could run a 5xx 
responder on port 25 if it had the IPs directed at it.

On 10 March 2022 21:15:43 UTC, Jay Hennigan via mailop  
wrote:
>On 3/10/22 12:22, Autumn Tyr-Salvia via mailop wrote:
>> Hello,
>> 
>> Given world events at the moment, there are reports that Russia is going 
>> to "disconnect from the internet" - but I don't know what exactly that 
>> means in terms of our direct interactions online. If we are sending 
>> emails to Russian mailbox providers - what types of bounces or errors 
>> should we look for? 
>
>You would see a timeout or possible connection refused if the receiving 
>MTA is itself unreachable.
>
>If the MTA is reachable or there's a secondary that's reachable but the 
>end user is cut off you won't see a bounce at all. The mail will just 
>sit in the user's mailbox.
>
>I doubt if you'll see the typical 4xx or 5xx bounce from the receiving 
>system.
>
>-- 
>Jay Hennigan - j...@west.net
>Network Engineering - CCIE #7880
>503 897-8550 - WB6RDV
>___
>mailop mailing list
>mailop@mailop.org
>https://list.mailop.org/listinfo/mailop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Pretty convincing ICANN renewal notice making the rounds..

[Mark E. Jeftovic via mailop]

I said years ago, when these policies came out (WDRP and then WAP) that
they would accomplish nothing other than to provide a gift-wrapped
phishing mechanism.

- mark

On 2022-03-21 12:57 PM, Michael Peddemors via mailop wrote:
> Authenticated from FastHosts..
>
> Source:
>
> Received: from mail.renam.md (HELO mail.renam.md) (81.180.84.189)
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
-- 
Mark E. Jeftovic 
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Pretty convincing ICANN renewal notice making the rounds..

[Michael Peddemors via mailop]

Authenticated from FastHosts..

Source:

Received: from mail.renam.md (HELO mail.renam.md) (81.180.84.189)


--
"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] Bogon? 81.70.92.213

[Atro Tossavainen via mailop]

On Mon, Mar 21, 2022 at 07:35:59AM +0100, Hans-Martin Mosner via mailop wrote:
> Hi folks,
> 
> in a trustworthy Received: line of a spam I found the source IP
> 81.70.92.213. Strangely, this IP is pingable, and traceroute finds a
> way, but neither the IP whois nor the BGP looking glass show to whom
> it belongs. Not being really knowledgeable about the global routing
> mechanisms, this somehow looks like a bogon to me.
> 
> Did anyone else see IPs in that vicinity and has a better explanation?

The Koli-Lõks OÜ spamtraps have a couple of spams every day from this
range. It's enough to verify that they exist, but this level of messaging
in our low four figures of domain names receiving the stuff is otherwise
utterly insignificant. It's a Tencent cloud range.

$ whois -h whois.cymru.com 81.70.92.213
[Querying whois.cymru.com]
[whois.cymru.com]
AS  | IP   | AS Name
45090   | 81.70.92.213 | TENCENT-NET-AP Shenzhen Tencent Computer Systems 
Company Limited, CN

% [whois.apnic.net]
% Whois data copyright termshttp://www.apnic.net/db/dbcopyright.html

% Information related to '81.68.0.0 - 81.71.255.255'

% Abuse contact for '81.68.0.0 - 81.71.255.255' is 'qcloud_net_d...@tencent.com'

inetnum:81.68.0.0 - 81.71.255.255
netname:TENCENT-CN
descr:  Tencent Cloud Computing (Beijing) Co., Ltd
descr:  Floor 6, Yinke Building, 38 Haidian St, Haidian District
country:CN

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

Best regards,
-- 
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://list.mailop.org/listinfo/mailop

[mailop] Bogon? 81.70.92.213

[Hans-Martin Mosner via mailop]

Hi folks,

in a trustworthy Received: line of a spam I found the source IP 81.70.92.213. Strangely, this IP is pingable, and 
traceroute finds a way, but neither the IP whois nor the BGP looking glass show to whom it belongs. Not being really 
knowledgeable about the global routing mechanisms, this somehow looks like a bogon to me.


Did anyone else see IPs in that vicinity and has a better explanation?

Cheers,
Hans-Martin

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