Re: [mailop] Filter out emoji from email adresses

[Philip Paeps via mailop]

On 2024-03-05 05:40:46 (+0800), Sebastian Nielsen via mailop wrote:

Anyone that have a general algoritm to filter out emoji from sender
addresses?

How I do in regexp to identify emoji? (its such a stupid thing)..


Today's regular expression will not capture tomorrow's emoji.  The nice 
people who standardise Unicode keep allocating more code points to more 
characters.



A guy sent a email containing emoji in the name part of a email sender
address in MIME FROM (like: Name [EMOJI] ). This 
caused a
few email clients to crash completely and being unable to reopen until 
I had

deleted the offending email from the inbox manually in the server.

So now I need to construct a rule to delete all emoji from both From: 
header

and To: header.


You have constructed a textbook example of an "XY problem".

Im thinking to do same as I do when I filter emoji from subject lines, 
but
this will also filter out umlaits from people's names so "André 
Andersson"
becomes "Andr Andersson" and "Recep Tayyip Erdoğan" would become 
"Recep

Tayyip Erdoan".

Which isn't a good thing to do.


How do you deal with users who write in 漢字 or 
देवनागरी?


So I need a rule to filter it more specifically, just delete all emoji 
but

not other Unicode like characters and names from other countries.


That is not a sustainable solution.

Replacing the clients that crash seems much easier.

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

Re: [mailop] Recommended ciphers used for ESMTP connections

[Christer Mjellem Strand via mailop]

Hi,


Some users are reaching out to us telling they have issues connecting
to our service because of incompatibility between the set of ciphers
offered during the connection.

On our send, we decided to use the ciphers suggested by Mozilla on
their SSL Configuration Generator (https://ssl-config.mozilla.org/)
(level "Intermediate") but I'm aware it's more for the HTTPS
connections that ESMTP / TLS.

So maybe there is another set of ciphers recommended for creating
secured connections in email that I'm not aware of. Do you have any
recommendations for this or is the ones from Mozilla (Intermediate)
is good enough?

If you want to avoid loading the link, here are the ciphers suggested
by them:

Ciphers:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA
-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-P
OLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA
-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305

Cipher
suites:
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_S
HA256

And we only accept TLS at v1.2 and higher.


As far as TLS in general is concerned, Mozilla's recommendations are 
perfectly sound, and their guidelines are well worth following 
regardless of protocol. An excellent baseline, and normally this should 
be all you need.


That said, we still decided to deviate from them *only* for SMTP (and 
not for i.e. Submission). The reason for this decision comes down to 
the number of poorly configured servers out there, and the fact that 
TLS in SMTP is still opportunistic. While requiring sane crypto at 
Mozilla's level will no doubt weed out a fair bit of spammers, 
unfortunately it is (still) likely to also weed out stuff it shouldn't. 
And since you won't know before the other side initiates STARTTLS 
whether you'll be able to agree on a common handshake, and poor crypto 
is still better than no crypto at all (which SMTP generally will 
happily allow), this ended up being the compromise.


Regardless of your approach, you should absolutely ensure that ciphers 
are used in server-preferred order. This doesn't really matter for 
TLSv1.3 since all cipher suites there today are generally considered 
equally safe, but it very much does for ciphers in TLSv1.2 (and 
anything below).


Should you choose to go down this path, a (possibly limited) variant of 
Mozilla's Old level might be appropriate, with only the least insecure 
(highest listed) TLSv1.1 and/or TLSv1.0 ciphers allowed. Experiment 
until you get no more complaints, rather than adding the whole Old list 
of ciphers.


If the other end doesn't support the ciphers at Intermediate level, 
they likely don't support TLSv1.2 at all, so in my experience[1] this 
is a bit of an either or. If you do want to "fix" this it will have to 
be a compromise, but together with the aforementioned server-preferred 
order, this should ensure only the worst servers get these worst 
ciphers and TLS versions, while everyone else still get the most modern 
and safe crypto available to them.


YMMV, and I'm sure some will want to argue that what I'm describing 
should never be allowed, but not everyone will have the luxury of being 
in a position to discard incoming ham "just" because the sender's 
server isn't set up properly. So to be clear, I am not recommending 
this course of action, only saying that, based on what you're saying, 
this is likely to be the necessary compromise to get around the issue.



[1] Yes, there is the theoretical possibility of a sending server 
supporting TLSv1.2 but only with weak ciphers. Feel free to experiment 
with that instead, should that be preferable.


--
Christer Mjellem Strand
System Administrator
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Any Apple guys, with knowledge of their networks shed some light on this IP Space?

[Michael Peddemors via mailop]

Does anyone know what this IP space is assigned for in general? Tracking 
some new threats..


inetnum:144.178.0.0 - 144.178.63.255
descr:  Apple Inc
status: LEGACY
remarks:Cupertino
admin-c:JD9555-RIPE
tech-c: JD9555-RIPE
netname:Apple-144-178-0-0-18
country:GB
mnt-by: APPLE-MNT
mnt-routes: APPLE-MNT
created:2017-04-19T07:38:55Z
last-modified:  2019-02-16T16:04:54Z
source: RIPE




--
"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] Filter out emoji from email adresses

[Sebastian Nielsen via mailop]

Anyone that have a general algoritm to filter out emoji from sender
addresses?

How I do in regexp to identify emoji? (its such a stupid thing)..

A guy sent a email containing emoji in the name part of a email sender
address in MIME FROM (like: Name [EMOJI] ). This caused a
few email clients to crash completely and being unable to reopen until I had
deleted the offending email from the inbox manually in the server.

 

So now I need to construct a rule to delete all emoji from both From: header
and To: header.

 

Im thinking to do same as I do when I filter emoji from subject lines, but
this will also filter out umlaits from people's names so "André Andersson"
becomes "Andr Andersson" and "Recep Tayyip Erdoğan" would become "Recep
Tayyip Erdoan".

Which isn't a good thing to do.

 

So I need a rule to filter it more specifically, just delete all emoji but
not other Unicode like characters and names from other countries.

 

 

Best regards, Sebastian Nielsen

 

 

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

Re: [mailop] Recommended ciphers used for ESMTP connections

[Johann Klasek via mailop]

On Mon, Mar 04, 2024 at 09:30:25PM +, Slavko via mailop wrote:
> D??a 4. marca 2024 21:15:23 UTC používate?? John Levine via mailop 
>  napísal:
[..]
> >Agreed.  My MTA uses "NORMAL:-VERS-SSL3.0"
> 
> Then why you are disabled SSL3? And why you do not build own openssl
> with SSL2 support?

Why so sarcastic? I think, the goal was not to achieve full coverage,
but to allow a reasonable number of connections. Omitting a protocol
suite is still another level compared to allowing a certain cipher
collection.


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

Re: [mailop] Recommended ciphers used for ESMTP connections

[L. Mark Stone via mailop]

You can get a clear view of your ciphers etc. by running:

nmap --script ssl-enum-ciphers -p 25 mx.yourserver.tld

FWIW, on our Zimbra 10 system with the FIPS-compliant OpenSSL package 
installed, we get on each of our MTAs:

nmap --script ssl-enum-ciphers -p 25 my.missioncriticalemail.com
Starting Nmap 7.94 ( https://nmap.org ) at 2024-03-01 15:16 EST
Nmap scan report for my.missioncriticalemail.com (35.173.158.175)
Host is up (0.038s latency).

PORT   STATE SERVICE
25/tcp open  smtp
| ssl-enum-ciphers: 
|   TLSv1.2: 
| ciphers: 
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors: 
|   NULL
| cipher preference: client
|   TLSv1.3: 
| ciphers: 
|   TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|   TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| cipher preference: client
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 8.57 seconds

We have only a handful daily of negotiation failures on the first connect; some 
of those succeed on the second connection a few minutes later. No customers 
have complained that anyone they want to get email from hasn't been able to 
send to us.

Hop[e that helps,
Mark 
_ 
L. Mark Stone, Founder 
North America's Leading Zimbra VAR/BSP/Training Partner 
For Companies With Mission-Critical Email Needs

- Original Message -
From: "Slavko via mailop" 
To: "mailop" 
Sent: Monday, March 4, 2024 4:30:25 PM
Subject: Re: [mailop] Recommended ciphers used for ESMTP connections

Dňa 4. marca 2024 21:15:23 UTC používateľ John Levine via mailop 
 napísal:
>It appears that Ken O'Driscoll via mailop  said:
>>Transport encryption is not for confidentiality anyway.
>
>Agreed.  My MTA uses "NORMAL:-VERS-SSL3.0"

Then why you are disabled SSL3? And why you do not build own openssl
with SSL2 support?

regards


-- 
Slavko
https://www.slavino.sk/
___
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] Recommended ciphers used for ESMTP connections

[Slavko via mailop]

Dňa 4. marca 2024 21:15:23 UTC používateľ John Levine via mailop 
 napísal:
>It appears that Ken O'Driscoll via mailop  said:
>>Transport encryption is not for confidentiality anyway.
>
>Agreed.  My MTA uses "NORMAL:-VERS-SSL3.0"

Then why you are disabled SSL3? And why you do not build own openssl
with SSL2 support?

regards


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

Re: [mailop] Recommended ciphers used for ESMTP connections

[John Levine via mailop]

It appears that Ken O'Driscoll via mailop  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>I think you have to consider Postel's Law here. If your cipher choices are
>causing problems for your  clients, then... maybe relax them a bit?
>
>Transport encryption is not for confidentiality anyway.

Agreed.  My MTA uses "NORMAL:-VERS-SSL3.0"

R's,
John

>> Ciphers:
>ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
>>
>> Cipher
>> suites: 
>> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
>>
>> And we only accept TLS at v1.2 and higher.

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

Re: [mailop] Recommended ciphers used for ESMTP connections

[Ken O'Driscoll via mailop]

I think you have to consider Postel's Law here. If your cipher choices are
causing problems for your  clients, then... maybe relax them a bit?

Transport encryption is not for confidentially anyway.


Ken.

On Mon, Mar 4, 2024, 16:34 Cyril - ImprovMX via mailop 
wrote:

> Hi everyone,
>
> Some users are reaching out to us telling they have issues connecting to
> our service because of incompatibility between the set of ciphers offered
> during the connection.
>
> On our send, we decided to use the ciphers suggested by Mozilla on their
> SSL Configuration Generator (https://ssl-config.mozilla.org/) (level
> "Intermediate") but I'm aware it's more for the HTTPS connections that
> ESMTP / TLS.
>
> So maybe there is another set of ciphers recommended for creating secured
> connections in email that I'm not aware of. Do you have any recommendations
> for this or is the ones from Mozilla (Intermediate) is good enough?
>
> If you want to avoid loading the link, here are the ciphers suggested by
> them:
>
>
> Ciphers: 
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
>
> Cipher
> suites: 
> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
>
> And we only accept TLS at v1.2 and higher.
>
> Thank you in advance.
> ___
> 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] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Gellner, Oliver via mailop]

> On 04.03.2024 at 11:42 Slavko via mailop:
>
> And what does aiosmtpd with message after it receive it? I guess, that it is 
> sending it out (to gmail), thus it acts as client... Does it quote (double) 
> that dot when message goes out?

Just a little nitpick: aiosmtpd is a Python library to receive emails. It does 
not send out anything. But if this is a self developed email stack, chances are 
that your assumptions are correct and the message gets understuffed with dots 
somewhere during processing.

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] PTR check mechanism / gmail

[Bill Sommerfeld via mailop]

On 3/4/24 11:23, John Levine via mailop wrote:

As you have seen, you can sometimes get away with less, but if you
want people to accept your mail, you want to look like a real mail
server in control of the names it uses.

This page suggests that if you simply ask Comcast to set your rDNS, they will 
do so:

https://forums.businesshelp.comcast.com/conversations/domain-namesstatic-ip/reverse-dns-request/5fe0a607c5375f08cd9153db


I can confirm - I am a Comcast business customer with their static 
address service and they set it for me on request (for both IPv4 and 
IPv6).   When I did it, I had to talk to a person to do it, once over 
the phone and once via their support chat through business.comcast.com; 
I haven't tried via the forum linked above.



- Bill


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

Re: [mailop] PTR check mechanism / gmail

[John Levine via mailop]

It appears that Matus UHLAR - fantomas via mailop  said:
>>Received: from atlas.bondproducts.com (unknown [23.24.6.165])
>>  by mx6.messagingengine.com (Postfix) with ESMTP id ...
>
>Here, atlas is the HELO/EHLO name the IP 23.24.6.165 introduced itself as.
>The fcrdns lookup was unsuccessful, hence the "unknown"

It is a very good idea for the HELO name to match the IP you're
sending from, and for the rDNS to resolve back to the same name. It is
not a great idea to send from a host with generic rDNS.

As you have seen, you can sometimes get away with less, but if you
want people to accept your mail, you want to look like a real mail
server in control of the names it uses.

This page suggests that if you simply ask Comcast to set your rDNS, they will 
do so:

https://forums.businesshelp.comcast.com/conversations/domain-namesstatic-ip/reverse-dns-request/5fe0a607c5375f08cd9153db

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] PTR check mechanism / gmail

[Bill Cole via mailop]

On 2024-03-03 at 14:36:25 UTC-0500 (Sun, 3 Mar 2024 20:36:25 +0100)
Marco Moock via mailop 
is rumored to have said:


Most server require that the PTR points to a domain name like
mail.example.org and that has the corresponding A/ records that
point to the IP address.


"Most" is probably an overstatement. Requiring that the PTR result 
resolves back to the client IP will lose you a small subset of mail from 
the Microsoft outbounds (a chronically small proportion of which are 
just wrong) and a whole lot of smaller sources of wanted email.


A common alternative configuration is requiring that an IP have a PTR 
(equivalent to Postfix's "reject_unknown_reverse_client_hostname") and 
sometimes people figure out ways to require more (e.g. that the name 
resolve to something.)



--
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] Mailop "best practices" - clarifications please

[Dave Crocker via mailop]

On 3/4/2024 4:50 AM, Andy Smith via mailop wrote:

but I don't relish trying to navigate inevitable issues
of disagreement between us all on what is actually best practice


Perhaps when there are significant constituencies for competing choices, 
merely add a comment about it, explaining the nature of the choices, the 
tradeoffs they have, and why there are preferences for each.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Recommended ciphers used for ESMTP connections

[Cyril - ImprovMX via mailop]

Hi everyone,

Some users are reaching out to us telling they have issues connecting to
our service because of incompatibility between the set of ciphers offered
during the connection.

On our send, we decided to use the ciphers suggested by Mozilla on their
SSL Configuration Generator (https://ssl-config.mozilla.org/) (level
"Intermediate") but I'm aware it's more for the HTTPS connections that
ESMTP / TLS.

So maybe there is another set of ciphers recommended for creating secured
connections in email that I'm not aware of. Do you have any recommendations
for this or is the ones from Mozilla (Intermediate) is good enough?

If you want to avoid loading the link, here are the ciphers suggested by
them:

Ciphers: 
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305

Cipher
suites: 
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

And we only accept TLS at v1.2 and higher.

Thank you in advance.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailop "best practices" - clarifications please

[Gareth Evans via mailop]

On Mon 04/03/2024 at 12:50, Andy Smith via mailop  wrote:
> This best practices document is going to get out of date and be hard
> to maintain. Maybe we should make it a wiki? I am happy to help
> technically but I don't relish trying to navigate inevitable issues
> of disagreement between us all on what is actually best practice.

I imagine such a resource would be excellent.  I would certainly welcome 
justified alternative views on or of "good" practice where "best" is debatable. 
 

>> > "... as is filtering on them"

> I'm not sure what the mailop best practices article is trying to
> say about "filtering on SPF" here, so I wouldn't seize upon what
> ionos is doing as related to it.

I had initially taken the mailop quote to mean "filtering on domains" rather 
than on SPF, so was looking for examples of domain-based filtering.  I think 
the ionos article is just a general KB-type article about DNSBLs rather than 
particularly re their own practice, but point taken :)  

Courtesy of Yahoo's sender best practices [1], I discovered 

https://www.m3aawg.org/

Are there any other such organisations or working groups etc worth knowing 
about/following?  

Thanks,
Gareth

[1] https://senders.yahooinc.com/best-practices/?guccounter=1

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

Re: [mailop] Mailop "best practices" - clarifications please

[Andy Smith via mailop]

Hello,

On Mon, Mar 04, 2024 at 09:12:43AM +0100, Marco Moock via mailop wrote:
> Am 04.03.2024 um 02:25:08 Uhr schrieb Gareth Evans via mailop:
> > From
> > 
> > https://www.mailop.org/best-practices
> > 
> > "Having SPF for your own domains is usually considered a weak signal
> > ..." 
> > 
> > Eh?
> 
> That sounds completely wrong. SPF makes forging the MAIL FROM: address
> much harder. Some server actually require it.

In context, that statement is in a section about forwarding email,
e.g. operating a mailing list. It was also apparently written in
2020 going by the copyright notice. I think it's just trying to say
that the list operator's use of SPF will help, but only a bit.

In 2024 I think we'd have to say that you really need SPF and
possibly DKIM as well to help get your mail delivered to the large
mailbox providers.

This best practices document is going to get out of date and be hard
to maintain. Maybe we should make it a wiki? I am happy to help
technically but I don't relish trying to navigate inevitable issues
of disagreement between us all on what is actually best practice.

> > "... as is filtering on them"
> > 
> > Such as DNS filtering per
> > https://www.ionos.co.uk/digitalguide/server/security/dns-filtering ?
> > 
> > Can anyone add a little more background/meaning/context to this
> > advice?
> 
> That sounds like a security nightmare.
> Attackers can use any public resolver from Google, Cloudflare or the
> ISP and query anything, so they get the information.

I'm not sure what the mailop best practices article is trying to
say about "filtering on SPF" here, so I wouldn't seize upon what
ionos is doing as related to it.

I think the mailop page could just be saying that making filtering
decisions on SPF alone isn't a good idea. Though again, that's 2020
advice; in 2024 as we know, lack of SPF+DKIM can lead to a filtering
decision. I don't know if "we" consider that as "not best practice"
but it *is* obviously an extremely common actual practice by now.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] PTR check mechanism / gmail

[Matus UHLAR - fantomas via mailop]

On Sun, Mar 03, 2024 at 05:23:22PM +, Gareth Evans via mailop wrote:
(Error NOERROR looking up 23.24.6.165 PTR,Error Error NXDOMAIN 
looking up 23-24-6-165-static.hfc.comcastbusiness.net.  A looking up 
23-24-6-165-static.hfc.comcastbusiness.net.  A,Error Error NXDOMAIN 
looking up 23-24-6-165-static.hfc.comcastbusiness.net.   looking up 
23-24-6-165-static.hfc.comcastbusiness.net.  );



On Sun 03/03/2024 at 18:55, Andy Smith via mailop  wrote:

Like it says, 23-24-6-165-static.hfc.comcastbusiness.net is an
NXDOMAIn for both A and , so that's not going to get very far.


On 04.03.24 00:17, Gareth Evans via mailop wrote:

Thanks, I understand that.

Given:

Received: from atlas.bondproducts.com (unknown [23.24.6.165])
by mx6.messagingengine.com (Postfix) with ESMTP id ...


Here, atlas is the HELO/EHLO name the IP 23.24.6.165 introduced itself as.
The fcrdns lookup was unsuccessful, hence the "unknown"


Received: from users.shellworld.net (users.shellworld.net [50.116.47.71])
by atlas.bondproducts.com (Postfix) with ESMTP id ...

atlas is (I think) a relay in this context.


yes, it put its name into Received: header.


$ dig -x 23.24.6.165
;; ANSWER SECTION:
165.6.24.23.in-addr.arpa. 3600  IN  PTR 
23-24-6-165-static.hfc.comcastbusiness.net.

What I am really asking is, if

23-24-6-165-static.hfc.comcastbusiness.net

actually resolved to 23.24.6.165 (same IP as atlas...), would delivery be 
expected to succeed, or does the host in the PTR also have to be 
atlas.bondproducts.com?


There are servers that refuse IP addresses without proper fcrdns, they 
would probably accept the e-mail.


There are also servers (and iirc even dnsbl) that refuse IP addresses with 
generic-looking DNS name. This looks like generic, so they would reject it:


23-24-6-165-static.hfc.comcastbusiness.net.

If the rdns would be atlas.bondproducts.com, the IP 23.24.6.165 would 
apparently have much less delivery issues.
 

I think the latter is what Marco meant by "proper PTR", and there may indeed be 
no convention.

The servers involved are not mine.  I bumped into this issue after 
discovering an invalid SPF record at shellworld.net.  I've never dealt 
with relays, or PTR records that don't correspond directly to sending 
hosts, so wondered what should happen in those circumstances if the IP 
actually resolved.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Slavko via mailop]

Dňa 4. 3. o 11:09 Cyril - ImprovMX via mailop napísal(a):


Pointing out the fact that the dot-stuffing works on the two sides (adding
then removing) shows that in the current scenario, the issue is either
caused by the sender or by us, and not between us and Gmail.


And what does aiosmtpd with message after it receive it? I guess, that 
it is sending it out (to gmail), thus it acts as client... Does it quote 
(double) that dot when message goes out?


regards

--
Slavko
https://www.slavino.sk/

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

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Cyril - ImprovMX via mailop]

Thanks everyone for your responses. I responded during the weekend but my
email was too big and got rejected. It's not relevant anymore.

Pointing out the fact that the dot-stuffing works on the two sides (adding
then removing) shows that in the current scenario, the issue is either
caused by the sender or by us, and not between us and Gmail.

I still don't have the root cause of this as we are investigating it. The
sender claims they are adding an extra dot when needed, and the aiosmtpd
library on which we relies does remove them. I'm starting to wonder if the
issue isn't related to something else.
I'm discussing with the sender on ways to get a raw email from them and
check where the email starts breaking the DKIM signature.

I'll keep you updated once we get to the root of the issue for those who
are interested to find out.

Have a nice week!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailop "best practices" - clarifications please

[Marco Moock via mailop]

Am 04.03.2024 um 02:25:08 Uhr schrieb Gareth Evans via mailop:

> From
> 
> https://www.mailop.org/best-practices
> 
> "Having SPF for your own domains is usually considered a weak signal
> ..." 
> 
> Eh?

That sounds completely wrong. SPF makes forging the MAIL FROM: address
much harder. Some server actually require it.

> "... as is filtering on them"
> 
> Such as DNS filtering per
> https://www.ionos.co.uk/digitalguide/server/security/dns-filtering ?
> 
> Can anyone add a little more background/meaning/context to this
> advice?

That sounds like a security nightmare.
Attackers can use any public resolver from Google, Cloudflare or the
ISP and query anything, so they get the information.

-- 
Gruß
Marco

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