Re: [mailop] No MX but A: broken MTA(s)

[ml+mailop--- via mailop]

On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:

> I have seen a-record fallback work, as in legitimate email flow, for others
> within the last two years.

> I have not been able to get it to work in my testing.

Maybe you can explain how you tested it and which software (MTA?)
was used?

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 20:58:19 UTC-0400 (11 Jul 2023 20:58:19 -0400)
John Levine via mailop 
is rumored to have said:

It appears that Grant Taylor via mailop  
said:

On 7/11/23 2:48 PM, John Levine via mailop wrote:

If your From: domain has neither an A nor an MX, I don't think
you're going to get much mail of any sort delivered.

I believe it's possible for two entities to configure their email
servers to exchange email with each other without the use of DNS.


Well, sure, you can do anything by private arrangement.

But if you want to exchance mail with other mail servers over the
public Internet, an A will do but you really want an MX.


Primarily because if you don't, it may confuse and distract people who 
should know better, and generate LONG mailing list threads.



--
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] rating DNSBLs not Isn't SpamEatingMonkey's

[John Levine via mailop]

It appears that John Levine via mailop  said:
>Virus Bulletin does a periodic test of spam filters.  In the most recent
>tests they tried Abusix and Spamhaus BLs along with regular filtering
>services.  The two BLs did quite well.  I don't see why you'd want to
>use any others for spam filtering.  If you want to catch malware, you
>also need something else:
>
>https://www.virusbulletin.com/testing/results/latest/vbspam-email-security

As someone pointed out there are useful DNSBLs that VB didn't test.  I
use invaluement but I would not waste time on spameatingmonkey and
most of the others.

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

Re: [mailop] Guide for setting up a mail server ?

[John Levine via mailop]

It appears that Grant Taylor via mailop  said:
>On 7/11/23 2:48 PM, John Levine via mailop wrote:
>> If your From: domain has neither an A nor an MX, I don't think 
>> you're going to get much mail of any sort delivered.
>I believe it's possible for two entities to configure their email 
>servers to exchange email with each other without the use of DNS.

Well, sure, you can do anything by private arrangement.

But if you want to exchance mail with other mail servers over the
public Internet, an A will do but you really want an MX.

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

Re: [mailop] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/11/23 4:20 PM, Jaroslaw Rafa via mailop wrote:

For start, I suggest to implement SPF, DKIM and DMARC only for
outgoing mail, and in fact only to satisfy Google's requirement that
these should be in place. Don't bother checking them on incoming
mail. (It's actually how I do it).


I am extremely surprised to see that recommendation, especially here on 
the mailop mailing list.


That seems very much like "checklist compliance" and not actual security 
that said checklist is evaluating.


My opinion is what your suggestion of only using SPF, DKIM, and DMARC on 
out bound email and not checking on in bound email is very questionable.


That being said, your servers, your rules.


RBLs and content filtering are enough to protect from spam. I see
close to zero improvement if I would check SPF and/or DMARC. Of
course YMMV.


I'm actually more worried about phishing than I am spam.  Spam is an 
annoyance but much less dangerous than phishing.  Phishing can cost 
people a LOT.



Send, maybe yes. Having it delivered is the other way. Consider my
case: FCrDNS, and not a "generic" one, SPF, DKIM and DMARC in place,
domain used for a long time. Yet still Google puts messages from me
to Spam folder of the recipients and there seems nothing can be done
about it. They simply so strongly dislike my parent domain :(.


Maybe I'm lucky.  But I think I've had remarkably good luck delivering 
to Gmail recipients.



But we are talking about BCP here, not about a RFC that defines a
protocol. I think BCP can be a proper place for clarifying the
roles.


The problem is that mentioned email oligarchs understand "reputation"
as something completely untransparent and internal to their mail
systems, not anything related to the community consensus.


So.

Every single organization running email is free to run it however they 
want to.  Your server, your rules.  My server, my rules.  Oligarch's 
server, Oligarch's rules.


Community consensus may be a client user base agreeing that something is 
spam.


Nothing guarantees that people outside of the community have visibility 
into the community consensus.


And you can't know in advance what is a "reputation" of a given 
domain for a given email oligarch (see my problems with Google 
mentioned above, which are clearly related to reputation, or rather 
what Google understands as reputation).

You can't know for sure.  But I suspect that you can have an idea.



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

Re: [mailop] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/11/23 4:31 PM, Jaroslaw Rafa via mailop wrote:

Hm... does this smell a bit X.400 or is it only my impression?


I believe the idea is protocol agnostic.

But I used to see it more in the '90s back when X.400 / OSI was much 
more of a thing.


I am quite certain that I've seen this type of B2B networking 
independent of the Internet done multiple times in the last two decades.




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

Re: [mailop] Guide for setting up a mail server ?

[Taavi Eomäe via mailop]

On 12/07/2023 00:20, Jaroslaw Rafa via mailop wrote:

For start, I suggest to implement SPF, DKIM and DMARC only for outgoing
mail, and in fact only to satisfy Google's requirement that these should be
in place. Don't bother checking them on incoming mail. (It's actually how I
do it).
RBLs and content filtering are enough to protect from spam. I see close to
zero improvement if I would check SPF and/or DMARC. Of course YMMV.


This is a terrible thing to suggest to someone. There's very little 
merit to accepting letters just like that.


More likely you'd be accepting phish, malware and other junk that 
would've gotten rejected if you respected DMARC as requested by 
respective owners of those domains.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] key exchange parameters: ECDHE, DHE, RFC 7919

[Taavi Eomäe via mailop]

On 11/07/2023 20:43, Bastian Blank via mailop wrote:

Given that this host only reacts on port 25 but not on port 587, I
assume this is MX.


Ideally one would offer implicit TLS on port 465 as well (RFC8314).


You are talking about MX, which is unauthenticated in the absence of DANE.


There's also MTA-STS, which doesn't rely on DNSSEC and introduce 
operational complexity.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No MX but A: broken MTA(s)

[Michael Orlitzky via mailop]

On Tue, 2023-07-11 at 15:00 -0500, Jarland Donnell via mailop wrote:
> 
> Does anyone actually receive mail by their A record in 2023? I'd just 
> assume break the RFC and save the resources for retrying and eventually 
> bouncing every email that ends up attempting delivery to an A record.
> 

The MX record for a domain name is usually a necessary level of
indirection, because the domain name itself usually points to a web
server and not a mail server.

But if I set up a mailing-list server on lists.orlitzky.com, then the
hostname already points to the right address. Why also create an MX
record and copy/paste?

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

Re: [mailop] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 16:14:17 Grant Taylor via mailop pisze:
>  - IBM configures their email servers to send all @lotus.example
> email to lotusmail which resolves via /etc/hosts to 192.0.2.1
>  - Lotus configures their email servers to send all @ibm.example
> email to ibmmail which resolves via /etc/hosts to 198.51.100.5
> 
> Ergo IBM and Lotus can exchange @ibm.example and @lotus.example
> email with each other without the use of DNS.
> 
> This would most likely be done in a business-to-business partner
> type configuration where companies wanted to make sure that such B2B
> communication did NOT traverse the public Internet.
> 
> Presuming of course that IBM and Lotus had some sort of private
> connection and routing between each other.

Hm... does this smell a bit X.400 or is it only my impression?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 13:23:45 Grant Taylor via mailop pisze:
> 
> I think SPF itself is relatively straightforward.
> 
> 1)  A domain owner publishes where they will send email from and
> what they would like recipients to do with email that does not match
> said publication.
> 2)  A receiving email server uses that published data to influence
> their local filtering algorithms.
> 
> IMHO DKIM is slightly more complex:
> 
> 1)  A sending server applies a cryptographic attestation of (part
> of) the message that it is sending.
> 2)  A receiving email server uses that cryptographic attestation to
> influence their local filtering algorithms.
> 
> DMARC is more complicated yet in what it checks.
> 
> 1)  A domain owner publishes filtering criteria that they would like
> applied to their domain.
> 2)  A receiving email server uses that published data to influence
> their local filtering algorithms.

For start, I suggest to implement SPF, DKIM and DMARC only for outgoing
mail, and in fact only to satisfy Google's requirement that these should be
in place. Don't bother checking them on incoming mail. (It's actually how I
do it).
RBLs and content filtering are enough to protect from spam. I see close to
zero improvement if I would check SPF and/or DMARC. Of course YMMV.

> I'll wager a cup of coffee that you could even use such a hostname /
> IP address to send email to one of the email oligarchs if you adhere
> to their other requirements.

Send, maybe yes. Having it delivered is the other way. Consider my case:
FCrDNS, and not a "generic" one, SPF, DKIM and DMARC in place, domain used
for a long time. Yet still Google puts messages from me to Spam folder of
the recipients and there seems nothing can be done about it. They simply
so strongly dislike my parent domain :(.

> >+ define/clarify MTA roles
> 
> In many ways the roles are outside of and independent of the
> protocol. RFCs are defining the protocol.

But we are talking about BCP here, not about a RFC that defines a protocol.
I think BCP can be a proper place for clarifying the roles.

> >"Good reputation" is bad wording into best practices.
> 
> I don't agree.  I believe that reputation can be quantified in some
> ways and I think that quantization can be compared to others.  Ergo
> it's possible to determine reputation and if it's good or bad.
> 
> In many ways "reputation" is a single word for what may be described
> as "community consensus".

The problem is that mentioned email oligarchs understand "reputation" as
something completely untransparent and internal to their mail systems, not
anything related to the community consensus. And you can't know in advance
what is a "reputation" of a given domain for a given email oligarch (see my
problems with Google mentioned above, which are clearly related to
reputation, or rather what Google understands as reputation).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No MX but A: broken MTA(s)

[Grant Taylor via mailop]

On 7/11/23 3:00 PM, Jarland Donnell via mailop wrote:
Does anyone actually receive mail by their A record in 2023? I'd just 
assume break the RFC and save the resources for retrying and eventually 
bouncing every email that ends up attempting delivery to an A record.


I have seen a-record fallback work, as in legitimate email flow, for 
others within the last two years.


I have not been able to get it to work in my testing.



Grant. . . .

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

Re: [mailop] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/11/23 2:48 PM, John Levine via mailop wrote:
If your From: domain has neither an A nor an MX, I don't think 
you're going to get much mail of any sort delivered.
I believe it's possible for two entities to configure their email 
servers to exchange email with each other without the use of DNS.


E.g.:

 - IBM configures their email servers to send all @lotus.example email 
to lotusmail which resolves via /etc/hosts to 192.0.2.1
 - Lotus configures their email servers to send all @ibm.example email 
to ibmmail which resolves via /etc/hosts to 198.51.100.5


Ergo IBM and Lotus can exchange @ibm.example and @lotus.example email 
with each other without the use of DNS.


This would most likely be done in a business-to-business partner type 
configuration where companies wanted to make sure that such B2B 
communication did NOT traverse the public Internet.


Presuming of course that IBM and Lotus had some sort of private 
connection and routing between each other.


I know that this is very far off the beaten path.  But I believe it's 
germane to discussions about what is and is not possible with email as 
well as what are the minimum requirements.


I believe truly understanding these fringe cases help elaborate and 
foster a better understanding of what is more common.




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

Re: [mailop] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 12:00:27 Grant Taylor via mailop pisze:
> The few times that I've tried to use A-record fallback -- testing
> for science / discussions like this one -- have resulted in failure.

For several years I didn't have a MX record for rafa.eu.org at all, only an
A record. Had absolutely no deliverability problems in any direction.

I added MX (as well as SPF, DKIM, DMARC) only after Google started putting
mesasages from me to recipients' Spam folder. (BTW. it was over three years
ago and the problem is still unsolved, over and over my messages get to spam
on Gmail even when marked by recipients as non-spam).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF +all considered harmful

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 14:29:26 Bill Cole via mailop pisze:
> 
> If that were anything close to grammatically correct I might understand it.

That guy is since quite a long time writing messages to this list that are
written in such a way that they couldn't be understood... :(
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Outlook/o365 having DNS Troubles?

[Michael Wise via mailop]

It's Azure, not EOP.

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 Michael Peddemors via 
mailop
Sent: Tuesday, July 11, 2023 11:02 AM
To: mailop@mailop.org
Subject: [EXTERNAL] [mailop] Outlook/o365 having DNS Troubles?



Jul 11 08:20:04 be msd[1974542]: CONN: 52.96.233.45 -> 587 GeoIP = [US]

PTR = NXDOMAIN OS = Windows NT kernel

Jul 11 08:20:04 be msd[1974542]: EHLO command received, args:

SJ1PR84MB3115.NAMPRD84.PROD.OUTLOOK.COM



The fingerprint looks funky too.. trying to see if this is an actual

cloud outlook, or a forgery..



Sure be nice if Microsoft properly SWIP'ed those segments of it's IP

space dedicate to o365, instead of making people guess if this is an

Azure abuse or not..



I am sure not ALL of this range is cloud outlook..



NetRange:   52.96.0.0 - 52.115.255.255

CIDR:   52.112.0.0/14, 52.96.0.0/12

NetName:MSFT

NetHandle:  NET-52-96-0-0-1

Parent: NET52 (NET-52-0-0-0-0)

NetType:Direct Allocation

OriginAS:

Organization:   Microsoft Corporation (MSFT)

RegDate:2015-11-24

Updated:2021-12-14

Ref:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frdap.arin.net%2Fregistry%2Fip%2F52.96.0.0&data=05%7C01%7Cmichael.wise%40microsoft.com%7C2fa34f7a30104521059708db823a4ccb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638246959179279554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=I6Lp9OAdVButkiCmbiiYSVGflJHUPMprFjqPgYpsdF8%3D&reserved=0







OrgName:Microsoft Corporation







--

"Catch the Magic of Linux..."



Michael Peddemors, President/CEO LinuxMagic Inc.

Visit us at 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linuxmagic.com%2F&data=05%7C01%7Cmichael.wise%40microsoft.com%7C2fa34f7a30104521059708db823a4ccb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638246959179279554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7CWmf5Z9jncaoCdzcVbgHjNmz%2BYYsdfzrg9%2B87c0xYQ%3D&reserved=0
 @linuxmagic

A Wizard IT Company - For More Info 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wizard.ca%2F&data=05%7C01%7Cmichael.wise%40microsoft.com%7C2fa34f7a30104521059708db823a4ccb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638246959179279554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2Cbd%2FhpTSZs8misRymb%2BAkWzyKBXsLpC0DIMdOL81RQ%3D&reserved=0

"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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop&data=05%7C01%7Cmichael.wise%40microsoft.com%7C2fa34f7a30104521059708db823a4ccb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638246959179279554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lZ4qY5O2DVrwHhafzEnB7MM8MhbE9E1Yfu6mjHYsAJU%3D&reserved=0
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No MX but A: broken MTA(s)

[Jarland Donnell via mailop]

Does anyone actually receive mail by their A record in 2023? I'd just 
assume break the RFC and save the resources for retrying and eventually 
bouncing every email that ends up attempting delivery to an A record.


On 2023-07-11 14:45, Michael Orlitzky via mailop wrote:


On Tue, 2023-07-11 at 13:36 -0500, Grant Taylor via mailop wrote:


However, I don't see any mention of a-record fallback in RFC 5321.  --
I didn't chase any updates.  --  I do see four occurances of "fall" in
the document, three of which are fall( )back and all three have to do
with something other than MX records vs a-records.

As such, I'd question the veracity of current SMTP needing to support
a-record fallback.


5.1.  Locating the Target Host

Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in Sections 2.3.5 and 3.6),
a DNS lookup MUST be performed to resolve the domain name... The lookup
first attempts to locate an MX record associated with the name... If an
empty list of MXs is returned, the address is treated as if it was
associated with an implicit MX RR, with a preference of 0, pointing to
that host.

___
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] rating DNSBLs not Isn't SpamEatingMonkey's

[John Levine via mailop]

It appears that Grant Taylor via mailop  said:
>I found myself wondering if there was anything like the Better Business 
>Bureau or some sort of accreditation that RBL operators can apply for 
>wherein they need to:

The short answer is no. As I found with the failed Spamhaus whitelist,
these sort of things are subject to adverse selection. The ones who
would get a good reputation already have a good reputation, so the
only ones you hear from are the lousy ones desperately saying "what do
we have to do to get a good score?" "Accurately identify mail people
want to receive?"  "NO NOT THAT."

Virus Bulletin does a periodic test of spam filters.  In the most recent
tests they tried Abusix and Spamhaus BLs along with regular filtering
services.  The two BLs did quite well.  I don't see why you'd want to
use any others for spam filtering.  If you want to catch malware, you
also need something else:

https://www.virusbulletin.com/testing/results/latest/vbspam-email-security

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

Re: [mailop] SPF +all considered harmful

[Sebastian Nielsen via mailop]

>> Outbound MSA re-sends the 
>> Inbound spam filter re-sends the message
>> Outbound compliance filter re-sends the message out to the world 

Those I consider internal processing of email, which don't really count as 
"forwarding" of a email.

I consider a email forwarded, when its being received by a server's MX, and 
then resent to a "foreign" MX using another recipient address than the one the 
email originally was sent to.
Then the envelope sender address should ALWAYS be changed, and in some cases, 
also MIME FROM.
In more extreme cases, I think the original email should be encapsulated in a 
new RFC822 block, which bears these header changes:

From: "(To: in original email)"
To: "(The address the email is forwarded to)"
Reply-To: "(From: in original email, unless Reply-To exists in original email)"
Subject: "Fwd: (Original subject)"
Content-Type: message/rfc822

[original message, untouched]


That’s to preserve as much as possible of the original email, but still ensure 
to not trip SPF, DKIM or DMARC security.

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

Re: [mailop] No MX but A: broken MTA(s)

[Grant Taylor via mailop]

On 7/11/23 2:45 PM, Michael Orlitzky via mailop wrote:

5.1.  Locating the Target Host


Thank you for the pointer Michael.

Today I Learned  :-)



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

Re: [mailop] No MX but A: broken MTA(s)

[Slavko via mailop]

Dňa 11. júla 2023 18:36:55 UTC používateľ Grant Taylor via mailop 
 napísal:
>On 7/11/23 12:35 PM, Michael Orlitzky via mailop wrote:

>However, I don't see any mention of a-record fallback in RFC 5321.  -- I 
>didn't chase any updates.  --  I do see four occurances of "fall" in the 
>document, three of which are fall( )back and all three have to do with 
>something other than MX records vs a-records.

I was curious, as i consider A/ targeting as part of SMTP,
thus i search that RFC too, but not for "fallback", i search "record"
word and i found this:

If an empty list of MXs is returned, the address is treated as if
it was associated with an implicit MX RR, with a preference of
0, pointing to that host.

Then i search "implicit", but without succes, thus i asume, that this
is only definition of behaviour when domain name has not MX
record. The behavior is to use:

MX 0 that_host

But, what is "that host"? Then i search the "host" word, and found:

Hosts are known by names (see the next section);

And in next section (domain names) is:

Only resolvable, fully-qualified domain names (FQDNs) are
permitted when domain names are used in SMTP. In other
words, names that can be resolved to MX RRs or address
(i.e., A or ) RRs.

Thus when host is known by its name, then "that host" means
"that domain", and "that domain" defines email target by its
MX, A or  records.

My understanding is, that A/ targetting is not fallback,
it is the same mechanism as MX, except that MX can "redirect"
target to another name and A/ cannot that.

Or is my research/understanding wrong?

regards


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

Re: [mailop] No MX but A: broken MTA(s)

[John Levine via mailop]

It appears that Grant Taylor via mailop  said:
>However, I don't see any mention of a-record fallback in RFC 5321.  -- 

You might want to read section 5.1 more carefully:

   The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found, the resulting name is processed as
   if it were the initial name.  If a non-existent domain error is
   returned, this situation MUST be reported as an error.  If a
   temporary error is returned, the message MUST be queued and retried
   later (see Section 4.5.4.1).  If an empty list of MXs is returned,
   the address is treated as if it was associated with an implicit MX
   RR, with a preference of 0, pointing to that host.  If MX records are
   present, but none of them are usable, or the implicit MX is unusable,
   this situation MUST be reported as an error.

   If one or more MX RRs are found for a given name, SMTP systems MUST
   NOT utilize any address RRs associated with that name unless they are
   located using the MX RRs; the "implicit MX" rule above applies only
   if there are no MX records present.  If MX records are present, but
   none of them are usable, this situation MUST be reported as an error.

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

Re: [mailop] Guide for setting up a mail server ?

[John Levine via mailop]

It appears that Grant Taylor via mailop  said:
>On 7/11/23 4:26 AM, Jaroslaw Rafa via mailop wrote:
>> TECHNICALLY, any email (there is no technical difference if it is B2B 
>> or not) requires only a machine that has an A record and a running 
>> MTA.
>
>I'll wager a lunch that A records aren't even required.  Maybe not any 
>name resolution at all.  Things like /etc/hosts and NIS(+) for 
>resolution aside.

If your From: domain has neither an A nor an MX, I don't think you're
going to get much mail of any sort delivered.

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

Re: [mailop] No MX but A: broken MTA(s)

[ml+mailop--- via mailop]

On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:

> However, I don't see any mention of a-record fallback in RFC 5321.  -- I
> didn't chase any updates.  --  I do see four occurances of "fall" in the

Maybe you should have looked for "MX" instead of "fall"?

   ...   If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.

> As such, I'd question the veracity of current SMTP needing to support
> a-record fallback.

"Wer lesen kann ist klar im Vorteil."

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[John Levine via mailop]

It appears that Andy Smith via mailop  said:
>I imagine if you want to set up a technically correct RFC-compliant
>mail server that can't deliver a lot of the email that real people
>want sent then there is probably a mailing list and guide for that
>somewhere, but I imagine that the OP was seeking real world
>practical advice.

Right.  The guy in question wrote some of the RFCs so he's in OK
shape there.

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

Re: [mailop] No MX but A: broken MTA(s)

[Michael Orlitzky via mailop]

On Tue, 2023-07-11 at 13:36 -0500, Grant Taylor via mailop wrote:
> 
> However, I don't see any mention of a-record fallback in RFC 5321.  -- 
> I didn't chase any updates.  --  I do see four occurances of "fall" in 
> the document, three of which are fall( )back and all three have to do 
> with something other than MX records vs a-records.
> 
> As such, I'd question the veracity of current SMTP needing to support 
> a-record fallback.


5.1.  Locating the Target Host

Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in Sections 2.3.5 and 3.6),
a DNS lookup MUST be performed to resolve the domain name... The lookup
first attempts to locate an MX record associated with the name... If an
empty list of MXs is returned, the address is treated as if it was
associated with an implicit MX RR, with a preference of 0, pointing to
that host.

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

Re: [mailop] SPF +all considered harmful

[Grant Taylor via mailop]

On 7/11/23 2:09 PM, Sebastian Nielsen via mailop wrote:

I think sender adress should be changed.


I think that /forwarding/, as in altering the envelope recipient 
address(es), probably should have the envelope sender address changed.


I say /probably/ because I'm sure there are some situations where it 
should not be done.  I just can't think of them now.


The reason is, you didn't compose the email, you shouldn't use the 
sender's identity.


Arguably none of the following composed the message:

 - Outbound MSA re-sends the message it receives from the submitter 
ostensibly using the submitted envelope from address.


 - Inbound spam filter re-sends the message on to the ultimate mailbox 
server re-using the inbound envelope from address.


 - Outbound compliance filter re-sends the message out to the world 
re-using the inbound envelope from address.


I think that the envelope from address SHOULD NOT be changed in any of 
these scenarios.


Fortunately, none of these scenarios are email terminal points even 
though they are SMTP terminal points.


When forwarding a email, you overtake the spam responsibility for 
that email in any case, so you ought to ensure your server isn't used 
for spam.


I mostly agree.

On the other hand, you have the responsibility to ensure a forwarding 
user doesn't set up anyones else's address as forward, by for example 
using double-opt-in verification or where you really know they hold 
that email adress (even when authorized users are using the forward 
system, for example employees of a company).


Agreed.

Couple these 2 together and you don't risk up ending up on blacklists 
because a user forwards a spam through your forward, because spam is 
both filtered AND forward is confirmed only.


Confirmation is completely independent of spam.

Spam filters can fail open or email can be quite above board but 
unwanted by the ultimate recipient.  Ergo spam can slip through a forwarder.


I have always tought it’s a ugly practice to forward the email as-is, 
as its same as forging someone's signature.


I don't know if I would consider it proper or what I would choose to do 
in a vacuum.  However I didn't make the choice in a vacuum.  I had prior 
art both with physical postal mail being forwarded and years of eMail / 
SMTP before me that I started by matching behavior.


At some point I switched to SRS when forwarding.  I think I did that as 
part of supporting and advocating for SPF.


You use someone elses identity, because you CLAIM to have received a 
email from their server.


I've said similar using slightly different words.  E.g. a mailing list 
generates a new email that is substantively based on the message that it 
received, purportedly from a given sender.



The receiving server on the other end cannot know this.


Agreed.

This is why sender address should ALWAYS be rewritten when forwarding 
an email.

I can't agree with the absolute nature of this.

There is also the question of what is forwarding.  Do the MSA, ESP, and 
compliance relays listed above count as forwarding?  Does me creating a 
script to receive messages from the LDA and attach them to a new 
outbound message to a different recipient count as forwarding?


Aside:  The last bit about attachments is what I want to end up doing 
for my personal accounts on the various systems I have accounts on. 
Originate and send a new email from my account on a remote system to an 
email address of my choosing elsewhere in a way that does not run afoul 
of SPF / DKIM / DMARC filtering.




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

Re: [mailop] Guide for setting up a mail server ?

[Dave Crocker via mailop]

On 7/11/2023 2:54 AM, Slavko via mailop wrote:

Setup and get it working is not different than other services,
not more easy nor more hard, just different. It requires to learn
how to setup particular SW as in other services. What i see as
more hard with email is:

+ it is not one protocol (SMTP and IMAP/POP)
+ it is not one SMTP purpose (MTA/Submission)
+ terminology is not clear (how many terms eg. for return-path, relay, etc)
+ it is very flexible, choose proper topology is not easy without some 
experiences
+ many roles, which one MTA can do
+ too many RFCs describing email, and some of them are not well cooperative
+ outdated or incomplete/wrong guides
+ lack of (open source) tools to work with eg. MIME mails



In case this helps:

RFC 5598: Internet Mail Architecture

🔗 https://www.rfc-editor.org/rfc/rfc5598 



d/

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

Re: [mailop] SPF +all considered harmful

[Collider via mailop]

there's one case where SPF +all is valid. That's when you already have DKIM 
anyway, and in any event, only if mail from your domain can validly come from 
anywhere.

The only time this'd be an issue is if you had MUAs sending directly, which 
mostly doesn't exist anymore, much to my chagrin (afaik none support DKIM 
outbound anyway, nor would that be a valid use of the technology).

Le 11 juillet 2023 18:29:26 UTC, Bill Cole via mailop  a 
écrit :
>On 2023-07-11 at 13:49:32 UTC-0400 (Tue, 11 Jul 2023 19:49:32 +0200)
>Benny Pedersen via mailop 
>is rumored to have said:
>
>> Bill Cole via mailop skrev den 2023-07-11 19:01:
>>> On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
>>> Benny Pedersen via mailop 
>>> is rumored to have said:
>>>
 direct to mx will have spf pass without +all, on next hub envelope sender 
 changes, so new spf problem when next hub forwards mails,
>>>
>>> You keep repeating this (and equivalent statements) as if it is true.
>>>
>>> ***IT IS FALSE***
>>>
>>> Unless a MTA implements something like SRS specifically to accommodate
>>> SPF, the envelope sender a mail arrives with is the same one it is
>>> relayed with, if it is being forwarded by the traditional "aliases"
>>> and ".forward" mechanisms of Sendmail and Postfix. This practice,
>>> *without SRS*, is still the most widespread form of forwarding
>>> individual addresses to other individual addresses.
>>
>> i keep what postfix does, not what any other forwarding service does, its 
>> false aswell to not know how postfix works, period
>
>If that were anything close to grammatically correct I might understand it.
>
>Postfix does not modify the envelope sender when using aliases or .forward 
>files to forward mail.
>>
>> https://mx.junc.eu/dmarc/junc.eu/all.txt prove my incorrect now ?
>
>I am not about to review whatever that flood of text means, and it appears to 
>be likely not evidence of anything...
>
>> if you are right i would see more spf pass
>
>Non sequitur. If your assumptions are incorrect, as they clearly are, I doubt 
>that your data analysis and logic are sound.
>
>Go ahead, sniff the packets or make the MTA log everything. Prove me wrong.
>
>-- 
>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

-- 
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] SPF +all considered harmful

[Sebastian Nielsen via mailop]

>>them loathed the idea of the envelope from address being changed at one 
or more hops along the way.

I think sender adress should be changed.
The reason is, you didn't compose the email, you shouldn't use the sender's 
identity.

When forwarding a email, you overtake the spam responsibility for that email in 
any case, so you ought to ensure your server isn't used for spam.
On the other hand, you have the responsibility to ensure a forwarding user 
doesn't set up anyones else's address as forward, by for example using 
double-opt-in verification or where you really know they hold that email adress 
(even when authorized users are using the forward system, for example employees 
of a company).

Couple these 2 together and you don't risk up ending up on blacklists because a 
user forwards a spam through your forward, because spam is both filtered AND 
forward is confirmed only.

I have always tought it’s a ugly practice to forward the email as-is, as its 
same as forging someone's signature.
You use someone elses identity, because you CLAIM to have received a email from 
their server.
The receiving server on the other end cannot know this.

This is why sender address should ALWAYS be rewritten when forwarding an email.

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

Re: [mailop] SPF +all considered harmful

[Grant Taylor via mailop]

On 7/11/23 10:08 AM, Benny Pedersen via mailop wrote:
on next hub envelope sender changes, so new spf problem when next hub 
forwards mails


This behavior is not guaranteed and SHOULD NOT be relied on.  If it 
works, then great!  But don't be surprised if it doesn't work.


I remember Sender Rewriting Scheme being discussed multiple different 
places many different times and the vast majority of people involved in 
them loathed the idea of the envelope from address being changed at one 
or more hops along the way.


For a long time Gmail actively discouraged SRS et al. saying that that 
they would associate the spam nature with the domain used in the changed 
envelope from address, thereby likely associating it with your server 
instead of the original purported source.


My understanding is that Gmail has (finally?) changed sides and now 
agrees that there are times to change the envelope from address, if not 
actually recommending it.


As for Postfix doing this by default, that's a new information to me and 
I consider it highly atypical.


As someone that has gone out of my way to run SRS on emails that I relay 
(but not originate) I agree with the idea.  But I also think that I'm in 
the extreme minority in my belief / support of SRS.  I take some comfort 
in Postfix (purportedly) defaulting to it.  But I still think that I'm 
in the minority and that most forwarding will not modify the smtp 
envelope from.




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

Re: [mailop] No MX but A: broken MTA(s)

[Grant Taylor via mailop]

On 7/11/23 12:35 PM, Michael Orlitzky via mailop wrote:
Seriously though, it's not a "fallback" in any pejorative sense. 
 SMTP predates much of DNS, including MX records. It's a fundamental 
part of the specification.

I largely agree, especially from a historic point of view.

However, I don't see any mention of a-record fallback in RFC 5321.  -- 
I didn't chase any updates.  --  I do see four occurances of "fall" in 
the document, three of which are fall( )back and all three have to do 
with something other than MX records vs a-records.


As such, I'd question the veracity of current SMTP needing to support 
a-record fallback.


Email, SMTP, is an evolving and changing standard.  It's important to 
know what both current expectations are and I think it behooves you to 
have an idea what previous expectations were.




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

Re: [mailop] SPF +all considered harmful

[Bill Cole via mailop]

On 2023-07-11 at 13:49:32 UTC-0400 (Tue, 11 Jul 2023 19:49:32 +0200)
Benny Pedersen via mailop 
is rumored to have said:

> Bill Cole via mailop skrev den 2023-07-11 19:01:
>> On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
>> Benny Pedersen via mailop 
>> is rumored to have said:
>>
>>> direct to mx will have spf pass without +all, on next hub envelope sender 
>>> changes, so new spf problem when next hub forwards mails,
>>
>> You keep repeating this (and equivalent statements) as if it is true.
>>
>> ***IT IS FALSE***
>>
>> Unless a MTA implements something like SRS specifically to accommodate
>> SPF, the envelope sender a mail arrives with is the same one it is
>> relayed with, if it is being forwarded by the traditional "aliases"
>> and ".forward" mechanisms of Sendmail and Postfix. This practice,
>> *without SRS*, is still the most widespread form of forwarding
>> individual addresses to other individual addresses.
>
> i keep what postfix does, not what any other forwarding service does, its 
> false aswell to not know how postfix works, period

If that were anything close to grammatically correct I might understand it.

Postfix does not modify the envelope sender when using aliases or .forward 
files to forward mail.
>
> https://mx.junc.eu/dmarc/junc.eu/all.txt prove my incorrect now ?

I am not about to review whatever that flood of text means, and it appears to 
be likely not evidence of anything...

> if you are right i would see more spf pass

Non sequitur. If your assumptions are incorrect, as they clearly are, I doubt 
that your data analysis and logic are sound.

Go ahead, sniff the packets or make the MTA log everything. Prove me wrong.

-- 
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] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/11/23 8:29 AM, Bill Cole via mailop wrote:
It is worthwhile to protect the details of a SMTP session on the wire, 
beyond simply protecting the contents of email.


Agreed.

+1

E2E tend to only address data and completely ignores metadata which 
transport encryption helps.




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

Re: [mailop] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/11/23 4:54 AM, Slavko via mailop wrote:
If something have to be said, then it have to be said and then 
doesn't matter who said it ;-)

Well said.

Nowaydays (especially joung) people tends to feel as experts, when 
they setup something first time. Thus, when not used word by word, it 
is good reminder. On other side, i work with computers & networks for 
more than 30 years, and still have questions ;-)


:-)

I start to maintain my own mail after 20 years of experiences with  
other nerwork services (both, LAN & WAN). Before that i afraid, that 
my experiences are not enough to fight with SPAM (in both directions, 
incoming & outgoing). But finally i recently (some years) decided to 
start with it, thus my point of view is relative fresh.


Fair enough.

Fortunately, with email, especially with a non-high-value domain, can be 
relatively safe to start with.


Setup and get it working is not different than other services, not 
more easy nor more hard, just different. It requires to learn how to 
setup particular SW as in other services.


I suspect that one of the things that makes email harder is that it 
encompasses many other interrelated and interdependent things.  So if 
you're starting from zero there is a lot to learn.  Other protocols / 
services tend to have less interdependencies.



What i see as more hard with email is:

+ it is not one protocol (SMTP and IMAP/POP)
+ it is not one SMTP purpose (MTA/Submission)
+ terminology is not clear (how many terms eg. for return-path, relay, etc)
+ it is very flexible, choose proper topology is not easy without 
some experiences

+ many roles, which one MTA can do
+ too many RFCs describing email, and some of them are not well cooperative
+ outdated or incomplete/wrong guides
+ lack of (open source) tools to work with eg. MIME mails

These things make email harder to start, than other services, but 
after one got them, it is as easy/hard as any other service.


BTW, what i most afraid (before i start) was how i will fight with 
SPAM to (required) postmaster mailbox. But that simple doesn't happen 
and that address gots near to no SPAM.


I think my concern back when I started administering email was that my 
server didn't become part of the problem / become a source of spam, 
relayed email, etc.  Functioning as I wanted it was a secondary desire. 
Fortunately I think I've manged to do just enough of both for quite a 
while now.


Aside:  I agree, my RFC mandated accounts get very little spam.


Yes, but will iname it as good practice, not as best.


Fair enough.

I have mixed feel from these. While can be "good friends", it seems 
that they involved to "bad boss". I feel, that particular RFCs was 
done by people, who consider them as "must have" and thus they 
mention cases (eg. DMARCs none policy) in not clear way, and doesn't 
describe clearly what to do if not all are implemented (eg. SPF 
without DMARC) on receiver side...


I suspect that some of that was on purpose as to not dictate what 
recipients should do.  After all, your server, your rules.


I think SPF itself is relatively straightforward.

1)  A domain owner publishes where they will send email from and what 
they would like recipients to do with email that does not match said 
publication.
2)  A receiving email server uses that published data to influence their 
local filtering algorithms.


IMHO DKIM is slightly more complex:

1)  A sending server applies a cryptographic attestation of (part of) 
the message that it is sending.
2)  A receiving email server uses that cryptographic attestation to 
influence their local filtering algorithms.


DMARC is more complicated yet in what it checks.

1)  A domain owner publishes filtering criteria that they would like 
applied to their domain.
2)  A receiving email server uses that published data to influence their 
local filtering algorithms.


Notice how all three are someone publishing information and someone 
(else) using that published information to influence recipient filtering 
configuration.


What each filters on and how it does the filtering is different.  But at 
a basic level, they are all similar two part systems; publish 
information and use said information.


That oligarch's behaviour is IMO direct result of aforementioned 
"must have" approach.


I'd have to go back and reread the various RFCs, but I don't remember 
anywhere in the specification what values should be in what fields, just 
that specific fields should be populated.  Of course this is predicated 
on you wanting to utilize said specification in an interoperable way.


I meet rejects due forward confirmed reverse DNS fails, then i setup 
it. But i agree, that mention it as requirements is wrong.


Yes, you will very likely need your forward and reverse DNS to match.

But those values matching has nothing to do with what those values are.

   3-2-0-192.CITY.STATE.ISP.EXAMPLE.IN  A   192.0.2.3

And

   3.2.0.192.in-addr.arpa.  IN  PTR 3-2-0-192.CI

[mailop] Outlook/o365 having DNS Troubles?

[Michael Peddemors via mailop]

Jul 11 08:20:04 be msd[1974542]: CONN: 52.96.233.45 -> 587 GeoIP = [US] 
PTR = NXDOMAIN OS = Windows NT kernel
Jul 11 08:20:04 be msd[1974542]: EHLO command received, args: 
SJ1PR84MB3115.NAMPRD84.PROD.OUTLOOK.COM


The fingerprint looks funky too.. trying to see if this is an actual 
cloud outlook, or a forgery..


Sure be nice if Microsoft properly SWIP'ed those segments of it's IP 
space dedicate to o365, instead of making people guess if this is an 
Azure abuse or not..


I am sure not ALL of this range is cloud outlook..

NetRange:   52.96.0.0 - 52.115.255.255
CIDR:   52.112.0.0/14, 52.96.0.0/12
NetName:MSFT
NetHandle:  NET-52-96-0-0-1
Parent: NET52 (NET-52-0-0-0-0)
NetType:Direct Allocation
OriginAS:
Organization:   Microsoft Corporation (MSFT)
RegDate:2015-11-24
Updated:2021-12-14
Ref:https://rdap.arin.net/registry/ip/52.96.0.0



OrgName:Microsoft Corporation



--
"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] key exchange parameters: ECDHE, DHE, RFC 7919

[Bastian Blank via mailop]

Hi

On Tue, Jul 11, 2023 at 05:47:12PM +0200, Paul Menzel via mailop wrote:
> Testing the mail setup, I was surprised to have the key exchange parameters
> flagged [1]:
> > a1241.mx.srv.dfn.de.DH-2048 insufficient

This test is for web or e-mail?  MX or MSA?

Given that this host only reacts on port 25 but not on port 587, I
assume this is MX.

> Mozilla’s SSL Configuration Generator also suggests for *Intermediate* and
> *Old* [3]:
> # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
> # not actually 1024 bits, this applies to all DHE >= 1024 bits
> smtpd_tls_dh1024_param_file = /path/to/dhparam

This generator is for web and other authenticated use.  You are talking
about MX, which is unauthenticated in the absence of DANE.

For unauthenticated MX use you want to allow as much encrypted
communication as possible.  So don't disable TLS 1.0 or weak ciphers,
clients will otherwise just downgrade to plaintext and make it worse.

So if you are not ready to also cut off plaintext connections overall,
don't touch it too much.  Clients will often restrict itself to more
modern settings anyway.

> Have most of you moved to ECDHE? If not, are you using the predefined finite
> field groups specified in RFC 7919 [5]?

Every current system supports ECDHE, so sure.  The original DH is dead,
because it's just too slow.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF +all considered harmful

[Benny Pedersen via mailop]

Bill Cole via mailop skrev den 2023-07-11 19:01:

On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
Benny Pedersen via mailop 
is rumored to have said:

direct to mx will have spf pass without +all, on next hub envelope 
sender changes, so new spf problem when next hub forwards mails,


You keep repeating this (and equivalent statements) as if it is true.

***IT IS FALSE***

Unless a MTA implements something like SRS specifically to accommodate
SPF, the envelope sender a mail arrives with is the same one it is
relayed with, if it is being forwarded by the traditional "aliases"
and ".forward" mechanisms of Sendmail and Postfix. This practice,
*without SRS*, is still the most widespread form of forwarding
individual addresses to other individual addresses.


i keep what postfix does, not what any other forwarding service does, 
its false aswell to not know how postfix works, period


https://mx.junc.eu/dmarc/junc.eu/all.txt prove my incorrect now ?

if you are right i would see more spf pass

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

Re: [mailop] No MX but A: broken MTA(s)

[Michael Orlitzky via mailop]

On Tue, 2023-07-11 at 17:13 +, ml+mailop--- via mailop wrote:
> 
> Which MTA is that?
> 

Microsoft Exchange Server 2003?

Seriously though, it's not a "fallback" in any pejorative sense. SMTP
predates much of DNS, including MX records. It's a fundamental part of
the specification.

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

Re: [mailop] SPF +all considered harmful

[Benny Pedersen via mailop]

Brandon Long via mailop skrev den 2023-07-11 18:50:

I assumed most people had already tuned their systems to ignore +all
or overly broad IP ranges, spammers abused that like a decade ago.


so why did gmail.com add 30+ ipv4 when it could be simple as +all ? 
:)


i did not count ipv6 on gmail.com


I feel like we even discussed it here, including having to exempt
Apple who had their entire class A listed at one point (they no longer
do).


we could hope for less ip space allowed in spf with is imho the real 
thing to solve, sadly +all and losts of valid ips is also valid, eg 
ip4:0.0.0.0/0 -all is complete nonsens, but valid in spf


if spf should solve this nonsense its needs to calc how many ips is 
listed in total, i would if over 256 ips consider domain as +all and in 
spamassassin untrust it as a spamming domain



Saying anyone can send mail as your domain is saying you don't care
about who abuses your domain... or you're protesting against
modern email and pining for the old days.


we could start using uucp and usenet again :)


And agreed, it doesn't solve the mailing list DMARC problem because
the spf is done against the envelope sender which will be the bounce
address for the mailing list, and that won't align with the from
header domain.


there is no dmarc problem if we ask maillist owners, mailman solve it 
all :)



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

Re: [mailop] No MX but A: broken MTA(s)

[ml+mailop--- via mailop]

On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:

> I think that A-record fallback is dependent on the sending MTA.

And which MTA are those which do not implement the RFCs properly?
"We are ..., we don't care about standards"

> Though if memory serves that's because my MTA of choice balks at the lack of
> MX record for the recipient domain.

Which MTA is that?

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF +all considered harmful

[Bill Cole via mailop]

On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
Benny Pedersen via mailop 
is rumored to have said:

> direct to mx will have spf pass without +all, on next hub envelope sender 
> changes, so new spf problem when next hub forwards mails,

You keep repeating this (and equivalent statements) as if it is true.

***IT IS FALSE***

Unless a MTA implements something like SRS specifically to accommodate SPF, the 
envelope sender a mail arrives with is the same one it is relayed with, if it 
is being forwarded by the traditional "aliases" and ".forward" mechanisms of 
Sendmail and Postfix. This practice, *without SRS*, is still the most 
widespread form of forwarding individual addresses to other individual 
addresses.


-- 
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] key exchange parameters: ECDHE, DHE, RFC 7919

[Slavko via mailop]

Dňa 11. júla 2023 15:47:12 UTC používateľ Paul Menzel via mailop 
 napísal:

>Have most of you moved to ECDHE? If not, are you using the predefined finite 
>field groups specified in RFC 7919 [5]?

I do not know what most of others, but i disabled DHE
ciphersuites, including all FFDH groups some years ago.
Roughly in time when OpenSSL with TLS1.3 come into
Debian oldstable.

Thus yes, only ECDHE here.

regards


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

Re: [mailop] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/11/23 8:15 AM, Bill Cole via mailop wrote:

Surprisingly, A-record fallback works just fine for B2B email.


My experience differs.  I've found A-record fallback to work inconsistently.

I think that A-record fallback is dependent on the sending MTA.

No one notices. Or at least no one appears to reject mail solely for 
that reason and inbound mail works perfectly.  It is, after all, the 
way email was originally designed to work.
The few times that I've tried to use A-record fallback -- testing for 
science / discussions like this one -- have resulted in failure.


Though if memory serves that's because my MTA of choice balks at the 
lack of MX record for the recipient domain.


IMHO, A-record fallback in 2023 is what Bob Ross would call a happy 
little accident.


However, I admit my evidence for that is ~2y old. I wouldn't 
*intentionally* allow an actively mailing domain to rely on A fallback...


I tried A-record fallback (on a test domain) some time in 2022 and it 
failed when I tested.




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

Re: [mailop] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/11/23 4:26 AM, Jaroslaw Rafa via mailop wrote:
TECHNICALLY, any email (there is no technical difference if it is B2B 
or not) requires only a machine that has an A record and a running 
MTA.


I'll wager a lunch that A records aren't even required.  Maybe not any 
name resolution at all.  Things like /etc/hosts and NIS(+) for 
resolution aside.


The thing that I was thinking about when I wrote my longer email was 
businesses explicitly configuring email routing in their MTA such that 
messages for a given destination domain were routed to a specified IP 
address or even host name.  That IP address, or hostname, can be locally 
significant and not known by anyone outside the organization.


This type of bidirectional configuration would only be done between 
organizations expressly trying to make sure that messages didn't flow 
through the open Internet.  The most likely entities to do this are 
businesses.


Yes, individuals can do this, I've done it with friends as a proof of 
concept.  But such individuals are such the minority as to be a rounding 
error.


And I understand Grant was writing from a technical, and not 
administrative point of view.


I think that the pair of entities explicitly configuring their MTA to 
route email to the others MTA independently of MXs also speaks to 
administrative points of view.  After all, it was likely a business 
decision / administrative decision that prompted the desire to do such.


You can mail to username@hostname.domain, you don't need to have a 
MX record. MX records are just a convenience so you can mail to 
username@domain instead of username@hostname.domain.


Agreed.

I'll add that TCP/IP networks don't /need/ nor /require/ a *default* 
gateway.  They just need a route, whatever that route is.  It can be an 
explicit route solely for the destination which doesn't apply to any 
other destination.


I've found that what the vast majority of what people do is a 
significant subset of what is possible to do that it's not even funny. 
What's worse is that -- in my opinion -- too many people fail to 
understand that there are options that don't require doing what others 
do, e.g. MX record for email or default gateway for IP routing.


These are Google requirements, not SMTP protocol requirements. We 
should not confuse one with the other.

I absolutely agree.

Google, et al., have chosen to configure their email servers to require 
things that the SMTP protocol does not require to function.


Each postmaster is free to configure their server(s) as they / their 
organization sees fit to do so.  But that does not make such 
configuration good.




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

Re: [mailop] SPF +all considered harmful

[Brandon Long via mailop]

I assumed most people had already tuned their systems to ignore +all or
overly broad IP ranges, spammers abused that like a decade ago.

I feel like we even discussed it here, including having to exempt Apple who
had their entire class A listed at one point (they no longer do).

Saying anyone can send mail as your domain is saying you don't care about
who abuses your domain... or you're protesting against
modern email and pining for the old days.

And agreed, it doesn't solve the mailing list DMARC problem because the spf
is done against the envelope sender which will be the bounce address for
the mailing list, and that won't align with the from header domain.

Brandon

On Tue, Jul 11, 2023 at 8:21 AM Benny Pedersen via mailop 
wrote:

> Alessandro Vesely via mailop skrev den 2023-07-11 11:12:
>
> > You need +all if you're after dmarc=pass.
>
> no not at all, direct to mx will have spf pass without +all, on next hub
> envelope sender changes, so new spf problem when next hub forwards
> mails, it does not need to be a maillist btw
>
> if dmarc is configure to align to be aligned to make dmarc pass, then it
> will fail for maillists, hmm ?
>
> aligned is to make sure its not forwarded and thus can be trusted not
> travel malicious servers on transit
>
> i just don't care :)
>
>
>
> ___
> 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] Isn't SpamEatingMonkey's SEM-URI broken?

[Grant Taylor via mailop]

On 7/11/23 4:18 AM, Jaroslaw Rafa via mailop wrote:
Sadly, you're probably right. It would take someone as universally 
trusted (and as trustworthy) as Jon Postel was once, to run such a 
service. But there are no people like Jon Postel in decisive 
positions anymore...

Yes, I try to find the good in others more so than many.

However I don't think that it would require someone like Jon Postel. 
Though I would implicitly trust him.


I think that what I'm describing could be done in the open above board 
and completely visible to all.  Much like how Certificate Transparency 
logs provide visibility into what Certificate Authorities do.


I don't necessarily need to trust the local scribe if what they record 
is publicly visible and authenticateable (using contemporary technology).


Look at how we -- ostensibly -- trust the DNSSEC for the root zone. 
It's open, it's visible, it's auditable.


I think that if we really wanted to we could come up with something like 
that to assess if a given RBL operator (entity) has provided evidence 
that they are adhering to a minimum level of acceptable behavior and / 
or exceeding it.


To me, this is largely just data that is publicly available that is run 
through a definable / publishable algorithm.  As such, there is not as 
much trust in the organization holding the data as the data and public 
algorithm itself.


Yes, I agree there is an opportunity for questionable practices to be 
done in a closed system.  That's expressly why I'm thinking about an 
open / visible / auditable system.


I genuinely believe that we could come up with something that (the vast 
majority if not everybody) could be trusted.  Or at the very least make 
it easy to detect when someone did something wrong.




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

[mailop] key exchange parameters: ECDHE, DHE, RFC 7919

[Paul Menzel via mailop]

Dear mail operators,


Testing the mail setup, I was surprised to have the key exchange 
parameters flagged [1]:



a1241.mx.srv.dfn.de.DH-2048 insufficient


Explanation:


DHE: The security of Diffie-Hellman Ephemeral (DHE) key exchange
depends on the lengths of the public and secret keys used within the
chosen finite field group. We test if your DHE public key material
uses one of the predefined finite field groups that are specified in
RFC 7919. Self-generated groups are 'Insufficient'.



See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1'
from NCSC-NL [2], guideline B5-1 and table 9 for ECDHE, and guideline
B6-1 and table 10 for DHE (in English).


Mozilla’s SSL Configuration Generator also suggests for *Intermediate* 
and *Old* [3]:


# curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
# not actually 1024 bits, this applies to all DHE >= 1024 bits
smtpd_tls_dh1024_param_file = /path/to/dhparam

I read the explanation [4], but I am ignorant about the cryptographic 
details.


Have most of you moved to ECDHE? If not, are you using the predefined 
finite field groups specified in RFC 7919 [5]?



Kind regards,

Paul


[1]: https://www.internet.nl/mail/molgen.mpg.de/968847/#control-panel-15
[2]: 
https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1
[3]: 
https://ssl-config.mozilla.org/#server=postfix&version=3.6.0&config=intermediate&openssl=1.1.1s&guideline=5.7
[4]: 
https://crypto.stackexchange.com/questions/81992/should-i-use-self-generated-or-predefined-rfc-7919-dh-groups

[5]: https://www.rfc-editor.org/rfc/rfc7919
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF +all considered harmful

[Benny Pedersen via mailop]

Alessandro Vesely via mailop skrev den 2023-07-11 11:12:


You need +all if you're after dmarc=pass.


no not at all, direct to mx will have spf pass without +all, on next hub 
envelope sender changes, so new spf problem when next hub forwards 
mails, it does not need to be a maillist btw


if dmarc is configure to align to be aligned to make dmarc pass, then it 
will fail for maillists, hmm ?


aligned is to make sure its not forwarded and thus can be trusted not 
travel malicious servers on transit


i just don't care :)



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

[mailop] SendGrid is deleting your mail (again)

[Michael Orlitzky via mailop]

Early yesterday morning, our upstream circuit was down from about
2:30am until 5:00am EDT. During that time, our MX was not answering;
so, no 4xx or 5xx response involved.

It's been over 24h, and I'm (personally) still missing five GitHub
notifications from that time:

4:03am EDT,
https://github.com/php/php-src/pull/11654?notification_referrer_id=NT_kwDOABXaR7I3MDEwODM5NzU0OjE0MzIxMzU#pullrequestreview-1521502822

4:24am EDT,
https://github.com/php/php-src/pull/11631?notification_referrer_id=NT_kwDOABXaR7I2OTk5ODQxMjEyOjE0MzIxMzU#pullrequestreview-1521540314

4:25am EDT,
https://github.com/php/php-src/commit/092e090cf00477e51802eae39651493b718c1415

4:42am EDT,
https://github.com/php/php-src/pull/11654?notification_referrer_id=NT_kwDOABXaR7I3MDEwODM5NzU0OjE0MzIxMzU#pullrequestreview-1521565401

4:43am EDT,
https://github.com/php/php-src/commit/893ca537b0a3dfb05d918d53e61fbf8cf9ca4f90


The complete lack of regard for your legitimate customers is maddening.

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

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 06:28:47 UTC-0400 (Tue, 11 Jul 2023 12:28:47 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:

And if mail *is* E2E encrypted, transport level encryption is 
basically

redundant...


Not really.

It is worthwhile to protect the details of a SMTP session on the wire, 
beyond simply protecting the contents of email.


--
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] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 05:26:25 UTC-0400 (Tue, 11 Jul 2023 11:26:25 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:

These are Google requirements, not SMTP protocol requirements. We 
should not

confuse one with the other.


Right, and that may be why Laura specifically referred to B2B mail.

Hobbyists can live with not delivering to GMail or MS, companies that 
need to work with other businesses via email cannot.



--
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] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 04:05:42 UTC-0400 (Tue, 11 Jul 2023 09:05:42 +0100)
Laura Atkins via mailop 
is rumored to have said:

B2B email requires a MX (like, if you don’t have an MX do you even 
email?)


Surprisingly, A-record fallback works just fine for B2B email. No one 
notices. Or at least no one appears to reject mail solely for that 
reason and inbound mail works perfectly.  It is, after all, the way 
email was originally designed to work.


However, I admit my evidence for that is ~2y old. I wouldn't 
*intentionally* allow an actively mailing domain to rely on A 
fallback...



--
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] Guide for setting up a mail server ?

[Andy Smith via mailop]

Hello,

On Tue, Jul 11, 2023 at 11:26:25AM +0200, Jaroslaw Rafa via mailop wrote:
> Dnia 11.07.2023 o godz. 09:05:42 Laura Atkins via mailop pisze:
> > B2B email requires a MX (like, if you don’t have an MX do you even email?) 
> 
> TECHNICALLY,

[…]

> These are Google requirements, not SMTP protocol requirements.

I imagine if you want to set up a technically correct RFC-compliant
mail server that can't deliver a lot of the email that real people
want sent then there is probably a mailing list and guide for that
somewhere, but I imagine that the OP was seeking real world
practical advice.

Bare minimum RFC compliance will not get you there on today's
Internet and Laura's advice was spot on.

> We should not confuse one with the other.

I really don't think that anyone was.

Cheers,
Andy

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

Re: [mailop] Guide for setting up a mail server ?

[Slavko via mailop]

Dňa 11. júla 2023 10:28:47 UTC používateľ Jaroslaw Rafa via mailop 
 napísal:
>Dnia 11.07.2023 o godz. 09:54:36 Slavko via mailop pisze:
>> 
>> This makes TLS strict requirement for Submission, IMAP &
>> POP3, in best with trusted certs.
>
>Agree, but this is only to protect against password snooping, not against
>content snooping, because:

I hope, that all of mail server admins (here) are aware of hop-by-hop
nature of SMTP and what this means for TLS. Thus not need to go
into it again and again.

This have to be repeated to users, again and again, that TLS is
not magic word, which will solve all their privacy problems  ;-)

regards


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

Re: [mailop] Isn't SpamEatingMonkey's SEM-URI broken?

[Slavko via mailop]

Dňa 11. júla 2023 7:24:29 UTC používateľ Mathieu via mailop  
napísal:

>Actually, it adds 3.5 *by scope*. And it has 3 scopes: url, email and dkim. 
>Which eventually sum up to 10.5... You would reject our messages.

Ah, i miss that. But no, i will not reject your messages, as 10
is threshold for deliver it to Junk. To reject, it must reach 16...

Anyway, i will guess that your emails will get some good
score too, eg. SPF, DKIM, DMARC, bayes, ..., which will
decrease that number...

If you are interested, be free to send me email directly,
i will send you result back and we both will see ;-)

I am not sure how high are default thresholds...

>If somebody from SEM is reading this, it would be easy for him/her to find out 
>the domain I'm talking about. And maybe help us to understand what SEM is 
>doing?

Yes, i am curious/interested to know more too.

regards


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

Re: [mailop] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 09:54:36 Slavko via mailop pisze:
> 
> This makes TLS strict requirement for Submission, IMAP &
> POP3, in best with trusted certs.

Agree, but this is only to protect against password snooping, not against
content snooping, because:

> In SMTP (MTA-MTA) it is not as strongly required, but IMO after
> Snowden, using it without TLS must be only rare. Sure, one
> cannot know how mail will be relayed latter, but one have
> maintain/setup own services.

Due to the nature of email (you don't know where it will be stored and who
will have access to it) if you want to protect the contents of your email
communication, you must use E2E encryption. Just transport-level encryption
(TLS) is not enough.

If you don't use E2E encryption, you should assume your mail *can* be
intercepted, no matter if it is sent over TLS or not...

And if mail *is* E2E encrypted, transport level encryption is basically
redundant...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Alessandro Vesely via mailop]

On Mon 10/Jul/2023 11:25:04 +0200 Carsten Schiefner via mailop wrote:

Home - maddy
https://maddy.email/



Courier-MTA is another all-in-one package.
https://www.courier-mta.org/


They both have a long list of configuration tasks.  I don't think one can work out a 
guide from comparing them, but it might be interesting to look at (If your mail 
reader won't rewrap)"

MAddy   Courier-MTA

Getting a serverUpgrading an 
existing installation
Installing maddyOverview
System configuration (systemd-based distribution)   Preparing for 
installation
Host name + domain  OPTIONAL: 
Install the Socks 5 client toolkit
TLS certificatesRun configure
First run   IPv6
DNS records Compile and run 
make check
MTA-STS and DANEInstallation
User accounts and maddy command Install 
configuration files
Building from sourceAdjust system 
paranoia level
Forward messages to a remote MX 
Post-installation setup
Using PAM authentication
Post-installation checks
OPTIONAL: 
Configure webadmin
Release builds  Create system 
aliases
Multiple domains configuration  Create smtp 
access list
Upgrading from older maddy versions Backscatter 
suppression
Outbound delivery security  Miscellaneous 
configuration
Docker  Define local 
domains
Reference manualOPTIONAL: 
Configure UUCP
OPTIONAL: 
Configure LDAP aliasing
Modules introductionOPTIONAL: 
Enable standard mail filters
Global configuration directives OPTIONAL: 
Configure custom mail filtering
TLS configuration   Create a list 
of domains to accept mail for
Automatic certificate management via ACME   Starting and 
stopping the Courier mail server
Endpoints configuration Run the Courier 
mail server in parallel to your mail server
IMAP4rev1 endpoint  OPTIONAL: 
Configure ESMTP authentication and SSL
SMTP/LMTP/Submission endpoint   OPTIONAL: 
Configure ESMTP smarthosting
OpenMetrics/Prometheus telemetryOPTIONAL: 
Configure the SECURITY ESMTP extension
IMAP storageOPTIONAL: 
Configure the Sender Policy Framework
IMAP filtersOPTIONAL: 
Configure the IMAP server
SQL-indexed storage OPTIONAL: 
Configure IMAP shared folders
Blob storageOPTIONAL: 
Configure IMAP over SSL
Filesystem  OPTIONAL: 
Certificate Authentication
Amazon S3   OPTIONAL: 
Sending mail via an IMAP connection
SMTP message routing (pipeline) OPTIONAL: 
Configure IMAP realtime folder status updates
SMTP targetsOPTIONAL: 
Configure SMAP
Local queue OPTIONAL: 
Configure the POP3 server
Remote MX delivery  OPTIONAL: 
Configure POP3 over SSL
SMTP & LMTP transparent forwarding  OPTIONAL: 
Configure the IMAP/POP3 aggregator proxy
SMTP checks OPTIONAL: 
Configure the webmail server
Check actions   OPTIONAL: 
Configure webmail calendaring
DKIMOPTIONAL: 
Configure mail filtering for the webmail server
SPF OPTIONAL: 
Changing mail account passwords using the webmail server
Milter client   OPTIONAL: 
Configure autoreplies for the webmail server
rspamd  OPTIONAL: 
Configure encryption for the webmail server
DNSBL lo

Re: [mailop] Guide for setting up a mail server ?

[Slavko via mailop]

Dňa 10. júla 2023 16:44:55 UTC používateľ Grant Taylor via mailop 
 napísal:

>I'm sorry that both 1) I feel that the following needs to be said and 2) that 
>I'm the one that's saying it.

If something have to be said, then it have to be said and then doesn't
matter who said it ;-)

>On 7/10/23 7:48 AM, Richard Clayton via mailop wrote:
>> not that I know of -- arguably there should be one, but perhaps it will just 
>> encourage unwise activity. I am reminded of Usenet advice of not posting for 
>> the first six months and if you ask why that is good advice then add another 
>> six months...
>
>I agree with -- what I'll call -- auditing.  I don't agree with asking 
>questions meaning that you need to extend the audit time.  I've seen some 
>EXTREMELY intelligent questions asked by people very knew to the situation.

Nowaydays (especially joung) people tends to feel as experts, when
they setup something first time. Thus, when not used word by word,
it is good reminder. On other side, i work with computers & networks
for more than 30 years, and still have questions ;-)

>> I recently reviewed an IETF draft on (de)centralisation which observed that 
>> running your own mail system, rather than using a centralised provider was 
>> far too hard.
>
>This disappoints me, greatly.  Both the idea that running a decentralized mail 
>server is hard and more so that such recommendations would admit or worse 
>support such a stance.

I start to maintain my own mail after 20 years of experiences with
other nerwork services (both, LAN & WAN). Before that i afraid,
that my experiences are not enough to fight with SPAM (in both
directions, incoming & outgoing). But finally i recently (some years)
decided to start with it, thus my point of view is relative fresh.

Setup and get it working is not different than other services,
not more easy nor more hard, just different. It requires to learn
how to setup particular SW as in other services. What i see as
more hard with email is:

+ it is not one protocol (SMTP and IMAP/POP)
+ it is not one SMTP purpose (MTA/Submission)
+ terminology is not clear (how many terms eg. for return-path, relay, etc)
+ it is very flexible, choose proper topology is not easy without some 
experiences
+ many roles, which one MTA can do
+ too many RFCs describing email, and some of them are not well cooperative
+ outdated or incomplete/wrong guides
+ lack of (open source) tools to work with eg. MIME mails

These things make email harder to start, than other services,
but after one got them, it is as easy/hard as any other service.

BTW, what i most afraid (before i start) was how i will fight
with SPAM to (required) postmaster mailbox. But that simple
doesn't happen and that address gots near to no SPAM.

>> * arrange for a backup MTA
>
>I'll argue that requiring a backup MTA is not strictly required.
>I'll absolutely agree that a backup MTA is best practice.

Yes, but will iname it as good practice, not as best.

>> * manage DNS MX, DKIM, DMARC and SPF records

>SPF, DKIM, and DMARC are the order that I'd advise others be implemented.

I have mixed feel from these. While can be "good friends", it seems
that they involved to "bad boss". I feel, that particular RFCs was
done by people, who consider them as "must have" and thus they
mention cases (eg. DMARCs none policy) in not clear way, and
doesn't describe clearly what to do if not all are implemented
(eg. SPF without DMARC) on receiver side...

>Chances are quite good that you will be able to exchange email with domains 
>that aren't hosted by the email oligarchs.

That oligarch's behaviour is IMO direct result of aforementioned
"must have" approach.

>> * manage reverse lookup records, including managing the uncertain chain of 
>> authority between the instance and the nearest SOA

>Yes, this can make it harder for someone to run an email server at home.  But 
>if they really want to do this, they can find ways to make it happen.  I'm 
>happy to help people make it happen too.

I meet rejects due forward confirmed reverse DNS fails, then
i setup it. But i agree, that mention it as requirements is wrong.

I run own LANs MTAs and forwad to ISP's smarthost for years,
no IP is involved, but it is still own email server (including IMAP
via fetchmail).

>> * manage certificates associated with TLS for SMTP and IMAP
>
>I'll argue that TLS is not strictly required.

I do not agree here. Don't forget that both are used by clients
(Submission), the plaintext for that is deprecated for years,
recently even STARTTLS was marked as legacy (sorry, i don't
remember RFC number). Running these over plain text is
questionable even in LAN, especially with wireless connections.

This makes TLS strict requirement for Submission, IMAP &
POP3, in best with trusted certs.

In SMTP (MTA-MTA) it is not as strongly required, but IMO after
Snowden, using it without TLS must be only rare. Sure, one
cannot know how mail will be relayed latter, but one have
maintain/setup own ser

Re: [mailop] Isn't SpamEatingMonkey's SEM-URI broken?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 02:26:02 Rob McEwen via mailop pisze:
> First, Grant, you're far too trusting of institutions and
> government. They're especially corrupt these days. Many governments
> that have had decades or centuries-long track records for bing
> mostly trustworthy and fair - are actually very corrupt these days.
> Such a governing body would downward devolve into "what benefits our
> party" before long.

Sadly, you're probably right. It would take someone as universally trusted
(and as trustworthy) as Jon Postel was once, to run such a service. But
there are no people like Jon Postel in decisive positions anymore...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 09:05:42 Laura Atkins via mailop pisze:
> 
> B2B email requires a MX (like, if you don’t have an MX do you even email?) 

TECHNICALLY, any email (there is no technical difference if it is B2B or
not) requires only a machine that has an A record and a running MTA.
And I understand Grant was writing from a technical, and not administrative
point of view.

You can mail to username@hostname.domain, you don't need to have a MX
record. MX records are just a convenience so you can mail to username@domain
instead of username@hostname.domain.

> In order for mail to be accepted at Google Workspace you must have either
> SPF or DKIM. There have been long discussions here about that. If you’re
> on IPv6 they’re a MUST (in the traditional RFC sense))

These are Google requirements, not SMTP protocol requirements. We should not
confuse one with the other.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF +all considered harmful

[Alessandro Vesely via mailop]

On Sat 08/Jul/2023 11:47:41 +0200 Sebastian Nielsen via mailop wrote:
I would say +all is always harmful. The difference between having +all and not 
having any at all (or ?all) is that you affirmately, by using +all, tell the 
system the email is genuine. If you somehow want to treat all emails as 
“unspecified” or “unknown”, ergo don’t want to reject, but you want to still 
have a SPF so you don’t get sent to spam folder for not having a SPF, you can 
use ?all to force a “neither genuine or fake” result that should be treated as 
no SPF at all in the actual validation system.



You need +all if you're after dmarc=pass.


If you as a webshop would put +all on a SPF, and I got a email, that was 
stamped as genuine in my email client, and I enter my card number on a website 
that was linked in said email to correct an order, I would held you accountable 
for every loss of money on that credit card, since you certified the email as 
genuine, and affirmately told me (or my computer system), by publishing a +all 
SPF, that I should trust that email to 100%.



Did any reimbursement claim ever succeed?


+all in SPF, ergo a harmful action, may however have its usage in certain 
situations, for example development or testing or SPF validation systems or 
similar.



It is used in alumni and similar sites.  E.g. member.fsf.org.


Best
Ale
--






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

Re: [mailop] Isn't SpamEatingMonkey's SEM-URI broken?

[Mathieu via mailop]

Thankfully, it seems there is a kind of "Whitelisted by policy":
  https://spameatingmonkey.com/lookup/gmail.com
"This is a normal email service, don't you know gmail?" :-D
  https://spameatingmonkey.com/lookup/gandi.net
With an evidence looking exactly like mines.
  https://spameatingmonkey.com/lookup/outlook.com
  https://spameatingmonkey.com/lookup/spameatingmonkey.com

Now the question is, why these domains, and how to apply?

Or, as it looks like, was it possible only in July, 2019?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Laura Atkins via mailop]

> On 10 Jul 2023, at 17:44, Grant Taylor via mailop  wrote:
> 
> Dear ${FELLOW_EMAIL_ADMINIATRATOR},
> 
> I don't know how to preface this email other than to say -- I believe the 
> following needs to be said lest we loose even more control of our email 
> community.
> 
> I'm sorry that both 1) I feel that the following needs to be said and 2) that 
> I'm the one that's saying it.
> 
> ...
> 
> I can't say that any of Richard's comments are technically wrong.  But I will 
> say that the tone of what the email represents is both disappointing and 
> concerning to me.
> 
> N.B. that Richard is one of many that have said similar things.  My comments 
> are *NOT* directed at Richard.
> 
> Rather many of us are culpable for allowing things to get into this state by 
> not actively fighting against it.  --  The first step is admitting you have a 
> problem.
> 
> ...
> 
> I agree that email is not easy by any stretch of the imagination.  But 
> comparatively I suspect it's easier to host your own email than starting a 
> company to build a car from scratch.  Is this a good comparison, probably 
> not.  But is it true?  I really hop so.
> 
> On 7/10/23 7:48 AM, Richard Clayton via mailop wrote:
>> not that I know of -- arguably there should be one, but perhaps it will just 
>> encourage unwise activity. I am reminded of Usenet advice of not posting for 
>> the first six months and if you ask why that is good advice then add another 
>> six months...
> 
> I agree with -- what I'll call -- auditing.  I don't agree with asking 
> questions meaning that you need to extend the audit time.  I've seen some 
> EXTREMELY intelligent questions asked by people very knew to the situation.
> 
> Simply asking a question does not, in and of itself, mean that someone is 
> ignorant of the topic.  Quite the opposite can be true.  E.g. "Is there any 
> reason to ever run an open relay?  There seem to be LOTS of negative points 
> to doing so; ." type thing.
> 
>> I recently reviewed an IETF draft on (de)centralisation which observed that 
>> running your own mail system, rather than using a centralised provider was 
>> far too hard.
> 
> This disappoints me, greatly.  Both the idea that running a decentralized 
> mail server is hard and more so that such recommendations would admit or 
> worse support such a stance.
> 
>> In discussions with Eliot Lear we ended up with a list of things you had to 
>> do:
>> * configure and manage the MTA
> 
> This is obvious and not specific to email.  You have to configure the service 
> for any and all services.  Chances of defaults doing exactly what you want 
> are quite rare.
> 
>> * arrange for a backup MTA
> 
> I'll argue that requiring a backup MTA is not strictly required.
> 
> I'll absolutely agree that a backup MTA is best practice.
> 
> There is a really big delta between strict requirement and best practice.
> 
>> * manage DNS MX, DKIM, DMARC and SPF records
> 
> None of those are strictly required either.  Business to business email can 
> function without any of them.

This is bad advice. 

B2B email requires a MX (like, if you don’t have an MX do you even email?) 

In order for mail to be accepted at Google Workspace you must have either SPF 
or DKIM. There have been long discussions here about that. If you’re on IPv6 
they’re a MUST (in the traditional RFC sense))

DMARC is wholly optional. 

laura 

-- 
Having an Email Crisis?  800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: http://wordtothewise.com/blog  





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

Re: [mailop] Isn't SpamEatingMonkey's SEM-URI broken?

[Mathieu via mailop]

On 10/07/2023 20:01, Slavko via mailop wrote:

Sources are on github, any one can see that. It adds 3,5 score by
default, while relative high, not significant itself and requires other
marks. 3,5 is not enough to mark message as SPAM even with
default thresholds, on my site 10 is required for that.


Actually, it adds 3.5 *by scope*. And it has 3 scopes: url, email and 
dkim. Which eventually sum up to 10.5... You would reject our messages.

  SEM_URIBL (7) [example.com:url,example.com:email]
  SEM_URIBL (10.5) [example.com:url,example.com:email,example.com:dkim]


Anyway, if this RBL is really as bad, it is not worth to use it and
would be great to get evidence from others too.


Sure. I can't believe, like Jarland said, that SEM would tag domains so 
simply!


By the way, as expected, we got listed again :-(

Some "evidences":


Received: from dltrngr.net ([240e:390:5d03:af1f:215:383:da23:52d])
by spameatingmonkey (spamtrap) with SMTP id 
11AEBA66-904E-4BEB-A4AF-C03AF2E0B406.1
envelope-from ;
Tue, 11 Jul 2023 05:42:16 +



Received: from zqxd.com ([240e:390:5d03:978f:215:329:2a23:52d])
by spameatingmonkey (spamtrap) with SMTP id 
22458D54-2F08-4D56-A805-4A5EBF576198.1
envelope-from ;
Tue, 11 Jul 2023 03:45:24 +



Received: from uveuqmfh.org ([240e:390:5d03:95cc:215:3bb:623:52d])
by spameatingmonkey (spamtrap) with SMTP id 
AE4E9276-6718-4FDB-8CCB-C578F1F7F76A.1
envelope-from ;
Tue, 11 Jul 2023 02:13:54 +


If somebody from SEM is reading this, it would be easy for him/her to 
find out the domain I'm talking about. And maybe help us to understand 
what SEM is doing?

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