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

[Slavko via mailop]

Hi,

Dňa 14. júla 2023 18:36:53 UTC používateľ Grant Taylor via mailop 
 napísal:

>With this in mind, my opinion is that hard and fast is often better / less 
>problematic in the long term.

I guess, that by "hard and fast" you mean reject early, thus in
case of SPF as response to "MAIL FROM", right?

Yes, that is big advantage of standalone SPF.

>The DMARC implementations that I use don't do the SPF nor DKIM checks 
>themselves.  Instead there are other independent filters that do those before 
>the DMARC filter and the DMARC filter uses the results from those tests.

I was not clear enough, sorry. I tried to "repair" that by last sentence
of this section, but i see that it doesn't solved it, thus i will try to
rephrase it:

Of course, it doesn't matter when the SPF/DKIM checks are done,
if as part of DMARC or as separate checks. What i meant is, when
result is applied...

>I'm fairly certain that SPF checks significantly pre-date DMARC.

Yes

Of course, some receivers can still do SPF only, in mean no DMARC
at all (i skip all other combinations). Beside that it is (IMO indirectly)
mentioned in RFC, it is IMO common (not only in email environment)
to not implement "new" techology immediately.

Anyway, i would expect something as this in RFC:

DMARC compliant receiver MUST NOT apply standalone SPF
results, unless DMARC's policy is p=none. In case of p=none,
they SHOULD/MAY apply standalone SPF.

Beside my poor English, it will be then clear for both sides, what
receivers can do and what senders can expect... For now receiver
have freedom and sender can only guess, and that is not about
interoperability...

>There's businesses hosting their own email which only effects them and then 
>there are businesses that host other people's email as a service. I think the 
>two are quite different in many regards.  E.g. Google does things quite 
>differently for @google.com email than their Gmail product does for @gmail.com 
>email.  GSuite hosted email is even more different.

But they are not doing that as differently, both, the @gmail.com
and @google.com, connections are here over TLS1.3, in both
directions. I didn't inspect their settings in more depth.

>Sometimes MTAs are forced to modify messages.  I usually see it when the MSA 
>or upstream MTAs support 8BITMIME and downstream MTA(s) don't.  Thus the last 
>8BITMIME supporting MTA *MUST* convert to 7-bit messages if the sender 
>utilized 8BITMIME.

IMO that modification is fully acceptable nowadays, i meant
another modifications, eg. to qualify To:/From: addresses,
add Date:/Message-ID: headers, etc.

BTW, our alphabet has 43 letters, ASCII-US was not enough for
us from start. Exim is 8bit transparent, even without asking it,
i didn't meet server requiring to ask that (except postfix requiring
to ask SMTPUTF8 due 8bit subject, but that was problem of
friend's PHP site). While i know whole story behind email's 7bit,
i do not understand why that problem still exists, but that is out
of our discussion.

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 ?

[John Levine via mailop]

It appears that Michael Peddemors via mailop  said:
>On 2023-07-14 09:20, Slavko via mailop wrote:
>
>You all realize that the poor guy looking for a guide on how to set up 
>and email server long since left, you scared him to death with the 
>complexity..

Um, that was me who asked the question on behalf of someone else.

To reply to someone else's question, we're not talking about setting
up an entire mail system for random users. He wants to be able to send
and receive mail for a handful of people and rols accounts and wonders
how to make it more likely that other mail systems will accept his
mail.

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 Thomas Walter via mailop  said:
>Hey Michael,
>
>On 13.07.23 00:53, Michael Peddemors via mailop wrote:
>> And yes, email forwarding will break.. but email forwarding remotely 
>> should be killed off anyways.. everyone can log into two accounts.
>
>Everyone has always been able to log into two accounts.

Some of us are old enough that we remember when that was not true, or
at least not true in a useful way.  If you had accounts on different
systems, you had to log out from one and log into the other to check.
Usually via dialup.

>I have sold one of my personal domains. The buyer agreed to forward the 
>personal address I had used to a new mailbox for a while. 

That's certainly one reason.

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 Jaroslaw Rafa via mailop  said:
>Most of regular consumer email users don't have any reason for this. As Bill
>Cole, whom I was replying to, wrote - nobody would try to impersonate you or
>me in a phishing campaign for financial gain, because there won't be any.

Since we all seem to have forgotten everything we talked about last
week, the reason we have to deal with DMARC for normal mail systems
(as opposed to places like Paypal where it makes sense) is that back
when AOL and Yahoo were different companies, they both had such poor
security that they let crooks steal their user address books, so
people were getting spam with return addresses of people they knew.

I think there were better ways to deal with that particular problem,
but it is definitely the case that normal people get their addresses
forged in spam.  Perhaps it doesn't happen to hobby systems hosted in
free public subdomains, but it happens to other people.

R's,
John
___
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/14/2023 11:21 AM, Grant Taylor via mailop wrote:
Suggest you might consider changing the topic, if you want to argue 
the various nuances and complexities of SPF/DKIM/DMARC etc..?


And break existing threading and avoid any ignore thread filters that 
people have put in place?


That seems like people changing email addresses to get around filters. 



This is exactly the type of breakage, caused by From field re-writing, 
that has been entirely ignored, in spite of being cited with some 
frequency.  It is, to coin a phrase, an inconvenient truth.



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

[Paul Smith via mailop]

On 14 July 2023 18:24:45 Dave Crocker via mailop  wrote:


We need to 'encourage' people to run their own mail servers, not scare
them away..


We also need to encourage people to do all the servicing for their car,
to build their own house, and to grow their own food.

Or we might take a somewhat more modern view of life and deal
pragmatically with the realities of the division of labor.


But if someone *wants* to set up a mail server, we shouldn't put them off 
unnecessarily.


Or would you put someone off growing vegetables in their garden as well?

If someone says "I want to receive email", then suggesting they set up 
their own mail server may be inappropriate, but that's not the case here.


Paul

___
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/14/23 11:20 AM, Slavko via mailop wrote:

Hi,


Hi Slavko,


Possible? Yes. Expected? Hard to tell... See latter.

 From which point of view?


My experience is that hard and fast usually surfaces errors much closer 
to the time they are introduced.


Conversely soft and slow usually causes errors to surface much later, 
frequently after the change that introduced the error has left the 
brains cache.  I usually see soft and slow errors written off as "I 
don't know what caused that, I'll dig deeper if / when it happens 
again."  Thus becoming a circular loop.


With this in mind, my opinion is that hard and fast is often better / 
less problematic in the long term.



We all are doing mistakes...


Yep.

I assume that you are aware of DMARC checking, as defined in RFC 7489, 
thus i shorten only important parts. The receiver:


1. gets MIME From: domain
1. gets DMARC policy
2. does DKIM check
3. does SPF check
4. does alignment check
5. applies policy

My understanding of that RFC is that both, SPF/DKIM checks happens 
as part of DMARC.


Maybe.  Not always.

The DMARC implementations that I use don't do the SPF nor DKIM checks 
themselves.  Instead there are other independent filters that do those 
before the DMARC filter and the DMARC filter uses the results from those 
tests.


That RFC clearly states, that fail ("-all") can be applied by **some** 
receivers before DMARC checks. I understand that section to be 
included as note, that not all receivers does DMARC checks, not 
as suggestion to do that before DMARC. Am i wrong?


I'm fairly certain that SPF checks significantly pre-date DMARC.

Just because something can be done as part of DMARC doesn't mean that it 
has to be done as part of DMARC.


My understanding is, that DMARC compliant receivers doesn't 
do independent SPF/DKIM checks, they are done as part of 
DMARC (see diagram in RFC). But doing these independed checks 
is  is not exactly prohibited, which IMO really lacks there.


Why does the SPF check need to wait until the DMARC check which needs 
the body (DATA)?


Why can't SPF be checked very much earlier at the MAIL FROM stage before 
the body (DATA) is sent?


Of course, where i wrote independent check, i mean apply 
result too.


Agree, but i don't extract bussines to separate category.


There's businesses hosting their own email which only effects them and 
then there are businesses that host other people's email as a service. 
I think the two are quite different in many regards.  E.g. Google does 
things quite differently for @google.com email than their Gmail product 
does for @gmail.com email.  GSuite hosted email is even more different.


Yes, starting without encryption is good. It makes debuging/learning 
significantly simpler.


:-)

I remember my 28.8 kbit/s modem and download 50 MB MySQL 
upgrade as whole day task ;-)


:-)


eg. MTA are prohibited to modify message. But yes they do it...


I question the veracity of that.

Sometimes MTAs are forced to modify messages.  I usually see it when the 
MSA or upstream MTAs support 8BITMIME and downstream MTA(s) don't.  Thus 
the last 8BITMIME supporting MTA *MUST* convert to 7-bit messages if the 
sender utilized 8BITMIME.


I know that there are other scenarios where an MTA will alter a message 
in transit.  This is one of the reasons why DKIM has relaxed and simple 
canonicalization.


I was not enough clear, these instances are not running on the same host 
(container) for the same reasons as you mentioned, sorry.


Thank you for clarifying.


regards


:-)



Thank you and have a good day,

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/14/2023 11:20 AM, Paul Smith wrote:


On 14 July 2023 18:24:45 Dave Crocker via mailop  
wrote:



We need to 'encourage' people to run their own mail servers, not scare
them away..


We also need to encourage people to do all the servicing for their car,
to build their own house, and to grow their own food.

Or we might take a somewhat more modern view of life and deal
pragmatically with the realities of the division of labor.



But if someone *wants* to set up a mail server, we shouldn't put them 
off unnecessarily.


Or would you put someone off growing vegetables in their garden as well?

If someone says "I want to receive email", then suggesting they set up 
their own mail server may be inappropriate, but that's not the case here.



The use of 'encourage', that I was responding to, was not in a tone that 
had to do with an individual person's preferences, but about pressing 
for a professional bias. In the context of this discussion, it frankly 
had a tone of social pressure, IMO.


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

[Grant Taylor via mailop]

On 7/14/23 11:31 AM, Michael Peddemors via mailop wrote:
You all realize that the poor guy looking for a guide on how to set up 
and email server long since left, you scared him to death with the 
complexity..


Why does an active ongoing conversation between multiple parties need to 
stop because the person that asked the original question walked away?


How and why are the currently active and communicating parties dependent 
on the person that originally asked the question?


We need to 'encourage' people to run their own mail servers, not scare 
them away..


If you read any part of my replies I think you would see that I am 
trying to encourage people to run their own mail server.


I try to be very much here's how you do something, here are the problems 
that you'll likely run into, and here's how you overcome those problems. 
 Let's talk if you have questions.


Suggest you might consider changing the topic, if you want to argue the 
various nuances and complexities of SPF/DKIM/DMARC etc..?


And break existing threading and avoid any ignore thread filters that 
people have put in place?


That seems like people changing email addresses to get around filters.

No thank you.



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]

We need to 'encourage' people to run their own mail servers, not scare 
them away.. 


We also need to encourage people to do all the servicing for their car, 
to build their own house, and to grow their own food.


Or we might take a somewhat more modern view of life and deal 
pragmatically with the realities of the division of labor.


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

[Michael Peddemors via mailop]

On 2023-07-14 09:20, Slavko via mailop wrote:

You all realize that the poor guy looking for a guide on how to set up 
and email server long since left, you scared him to death with the 
complexity..


We need to 'encourage' people to run their own mail servers, not scare 
them away..


Suggest you might consider changing the topic, if you want to argue the 
various nuances and complexities of SPF/DKIM/DMARC etc..?



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

[Slavko via mailop]

Hi,

Dňa 13. júla 2023 23:42:15 UTC používateľ Grant Taylor via mailop 
 napísal:

>I absolutely think that it's quite possible to apply SPF independently 
>nowadays.

Possible? Yes. Expected? Hard to tell... See latter.

>Is it better to fail soft and slow or hard and fast?

From which point of view?

>Sure, SPF publishers make mistakes.

We all are doing mistakes...

>I'll argue that if I set a "-all" on my SPF record that I really honestly and 
>truly want no server than my authorized server to send email claiming to be 
>from me.  This includes mailing lists.

I assume that you are aware of DMARC checking, as defined in RFC 7489,
thus i shorten only important parts. The receiver:

1. gets MIME From: domain
1. gets DMARC policy
2. does DKIM check
3. does SPF check
4. does alignment check
5. applies policy

My understanding of that RFC is that both, SPF/DKIM checks happens
as part of DMARC.

That RFC clearly states, that fail ("-all") can be applied by **some**
receivers before DMARC checks. I understand that section to be
included as note, that not all receivers does DMARC checks, not
as suggestion to do that before DMARC. Am i wrong?

My understanding is, that DMARC compliant receivers doesn't
do independent SPF/DKIM checks, they are done as part of
DMARC (see diagram in RFC). But doing these independed checks
is  is not exactly prohibited, which IMO really lacks there.

Of course, where i wrote independent check, i mean apply
result too.

>For a business selling email services, no.

Agree, but i don't extract bussines to separate category.

>I say this because I think that people don't /need/ to learn about / mess with 
>encryption when they are /first/ starting to learn about email servers.

Yes, starting without encryption is good. It makes debuging/learning
significantly simpler.

>I've routinely seen MSAs configured with longer time out values than MTAs.

I remember my 28.8 kbit/s modem and download 50 MB MySQL
upgrade as whole day task ;-)

>What's the actual violation?  What fails to function from and end users stand 
>point?

eg. MTA are prohibited to modify message. But yes they do it...

>For Sendmail, it's actually more complicated to run multiple instances of the 
>daemon.

I was not enough clear, these instances are not running on the same host
(container) for the same reasons as you mentioned, sorry.

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/13/23 10:56 AM, Slavko via mailop wrote:

Ahoj,


Hi,

OK, our opinions are near the same, but still opinions only, without 
something in RFC.


:-)


IMO one cannot apply SPF independently nowadays.


I absolutely think that it's quite possible to apply SPF independently 
nowadays.


Sure, your recipients might not like you honoring the sending domain's 
request.  But who's problem is it really?  Who is the most capable of 
fixing the root cause of the problem?


Should we hold sending domains accountable for what they publish in DNS? 
 Or should we coddle them ostensibly because we know better?


"Honesty and ass-kicking" from Taylor Mali's What Teachers Make poem 
comes to mind.  "If you ask for it, then I have to let you have it."


Link - What Teachers Make
 - https://taylormali.com/poems/what-teachers-make/
 - https://www.youtube.com/watch?v=RxsOVK4syxU

Is it better to fail soft and slow or hard and fast?


As discussed multiple times, SPF breaks forwarding


Didn't the purported sending domain ask that messages not from 
authorized sources be treated harshly?  (Assuming SPF ends in "-all".)


Honesty and ... "-all" means that I am asking you to really reject email 
not from sources that I authorize.



(thus can lead to false positives)


I question the veracity of a false positive if it's contrary to the 
published SPF.


Sure, SPF publishers make mistakes.  But what's better, to coddle them 
and have transient delivery errors for a long time (fail slow and soft) 
or make the errors very apparent to them (fail fast and hard) so that 
they can fix them?



and its (soft)fail result can be overridden latter by DMARC,


What does does the requested handling; anything between "-all" and 
"+all", have to do with overriding the result?  Or is it that you're 
only willing to override specific requests, possibly from specific people?



and one don't know DMARC result before evaluate it...


So?

I'll argue that if I set a "-all" on my SPF record that I really 
honestly and truly want no server than my authorized server to send 
email claiming to be from me.  This includes mailing lists.



IMO applying DKIM independently is pointless from start.


Okay.  The value of a result of a test is somewhat orthogonal to if the 
when the test can be run.


As this, DKIM is good only for statistical purpose, eg. to count 
reputation for success DKIM's domain.


DMARC finally checks them both + alignment, but can be evaluated only 
after full message body was received. As it can negate (soft)failed 
SPF, it must be evaluated, to know if and which policy sender 
defines.


Only after DMARC is evaluated and found no DMARC policy (record) or 
p=none, pure SPF can be applied.


That is one way to apply SPF.  But it doesn't mean that SPF can't be 
applied differently.


But one still needs to do DMARC record discovery, and as it is based 
on MIME From: domain, cannot be discovered before full body is 
received. That negates one big SPF advantage -- apply before body was 
received...


Success DMARC with p=none has the same wight as with any other 
policy. IMO the difference is/have to be only on failed DMARC.



No, that was not what i talk about. Plain text SMTP is not 
deprecated nor legacy, it is part of SMTP definition. It have to be 
not suggested (or avoid) only novadays for reasons outside of SMTP.



Perhaps i am too affected by my previous job (army's IT, encryption, 
etc), or i am simple paranoid. But as Snowden show us many years 
ago, not only bad boys are spying. And as social networks shows, 
collection of many small details (which are all not important by 
self) can reveal important complex information about individuals...


I absolutely agree that encryption SHOULD be used.

I also absolutely agree that email can function without encryption.

Yes, a meet that too, i avoid that services if possible (i know, 
that you don't like my "if possible").


Avoiding services with an unfavorable configuration doesn't mean that 
the services don't exist.


No. I consider encrypting/protecting network connection as normal 
behavior. Exactly as anyone distinguish own behavior on public 
places and at home...


I agree that encryption should be the norm.  I think it is becoming the 
norm.  But I don't think we are there yet.


I my job, i have boss. He is independent manager, but still has own 
boss (raw terms). From time to time the boss's boss does some 
resolution or directive, eg. my boss must use their email system. And 
that email system provides only legacy 587/tcp connection. It is not 
possible for me to avoid it, as that provider MUST be used...


I get it.

In any other situation, i will either ask to provide better service 
(pointless in this case) or change provider (impossible in this 
case). That is point of "is possible"...


ACK

Or, i have one appliance with relative old SSH server is running, 
which doesn't understand nowadays OpenSSH signatures. I had to allow 
legacy sinature in my client, but

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

[Gellner, Oliver via mailop]

> On 13.07.2023 at 11:12 Hans-Martin Mosner via mailop wrote:
>
> 
> Has anyone on this list tried forwarding (e.g. for ex-employees) via 
> attachment? The original message would be kept intact, while the outer 
> message clearly originates with the forwarding agent who may even add a human 
> readable reminder to the addressee to let the sender know about the changed 
> address.
>
> Opening message attachments should be possible with most modern MUAs, but TBH 
> I don't really have much experience with that.

I see two potential hurdles with attachment forwarding (not necessarily 
dealbreakers):
1. Some webmail frontends and email apps on smartphones did not let you view 
eml attachments or at least weren’t able to open nested attachments, ie when 
the original message before forwarding already had another message attached. 
Maybe the support has improved recently, I don’t know.
2. If you don’t do the forwarding for yourself but for random users / 
customers, they might get confused or annoyed because of the attachments.

Also attachment forwarding obviously does not free you from possible problems 
if you forward spam.

—
BR Oliver




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

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

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

[Slavko via mailop]

Ahoj,

Dňa Wed, 12 Jul 2023 10:04:10 -0500 Grant Taylor via mailop
 napísal:

> In my opinion, if a domain's DMARC has a p=none, then you don't
> filter on  DMARC.  But you still independently apply your site's
> local SPF filtering policy preferably following the sending domain's
> stated SPF wishes.  The only thing that you would do with DMARC is
> send the notification of the result.

OK, our opinions are near the same, but still opinions only, without
something in RFC.

> 1)  I would expect you to apply SPF independently of DKIM and DMARC
> if the sending domain publishes SPF records.

IMO one cannot apply SPF independently nowadays. As discussed multiple
times, SPF breaks forwarding (thus can lead to false positives) and its
(soft)fail result can be overridden latter by DMARC, and one don't know
DMARC result before evaluate it...

> 2)  I would expect you to apply DKIM independently of SPF and DMARC
> if the message has DKIM headers and the sending domain publishes DKIM 
> information.

IMO applying DKIM independently is pointless from start. Failed DKIM
have to be considered ad no DKIM at all. And success DKIM means
relative nothing, as here is no way to find reliable relation between
sender and d= domain, thus anyone can fill "own" d= domain.

As this, DKIM is good only for statistical purpose, eg. to count
reputation for success DKIM's domain.

> 3)  I would expect you to apply DMARC using the aforementioned SPF
> and / or DKIM results if the sending domain publishes DMARC
> information.

DMARC finally checks them both + alignment, but can be evaluated
only after full message body was received. As it can negate
(soft)failed SPF, it must be evaluated, to know if and which policy
sender defines.

Only after DMARC is evaluated and found no DMARC policy (record) or
p=none, pure SPF can be applied.

> A DMARC policy of none simply elides that 3rd step to me.

But one still needs to do DMARC record discovery, and as it is based on
MIME From: domain, cannot be discovered before full body is received.
That negates one big SPF advantage -- apply before body was received...

Success DMARC with p=none has the same wight as with any other policy.
IMO the difference is/have to be only on failed DMARC.

> Perhaps other parts of the world have been using TLS, either implicit
> or explicit via STARTTLS, for so long that they are now no longer
> offering service without TLS.

No, that was not what i talk about. Plain text SMTP is not deprecated
nor legacy, it is part of SMTP definition. It have to be not suggested
(or avoid) only novadays for reasons outside of SMTP.

> My experience has been that unencrypted connections are still offered
> in the areas where I'm interacting.  Usually unencrypted will work
> close to the service (as in connected to the ISP's network) but may
> not work further away.

Perhaps i am too affected by my previous job (army's IT, encryption,
etc), or i am simple paranoid. But as Snowden show us many years ago,
not only bad boys are spying. And as social networks shows, collection
of many small details (which are all not important by self) can reveal
important complex information about individuals...

> I still people using really old configurations without TLS and ISPs
> not choosing TLS when helping customers set up new systems.

Yes, a meet that too, i avoid that services if possible (i know, that
you don't like my "if possible").

> In some ways, TLS has been viewed as "oh, you're one of the people
> that want to be really secure", let me get the documents.

No. I consider encrypting/protecting network connection as normal
behavior. Exactly as anyone distinguish own behavior on public places
and at home...

> I get the avoid part.  I don't know that I'd go so far as to say "if 
> possible".

I my job, i have boss. He is independent manager, but still has own
boss (raw terms). From time to time the boss's boss does some resolution
or directive, eg. my boss must use their email system. And that email
system provides only legacy 587/tcp connection. It is not possible for
me to avoid it, as that provider MUST be used...

In any other situation, i will either ask to provide better service
(pointless in this case) or change provider (impossible in this case).
That is point of "is possible"...

Or, i have one appliance with relative old SSH server is running, which
doesn't understand nowadays OpenSSH signatures. I had to allow legacy
sinature in my client, but only for that appliance, not globally. Thus
i avoid old signatures, where it is possible...

> I would expect that if the legacy thing is not provided, it's not
> even listed as an option.

Sure, when it is not provided, then it is not provided and one rarely
can expect, that someone will enable it...

> LAN is more about locality.

AFAIK, technically it is about used technologies/protocols. Nobody will
be success to connect with twisted pair cable from EU to USA. Nor via
WiFi...

> The minimum viable product as in what can send and rec

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

[Bill Cole via mailop]

On 2023-07-12 at 18:53:31 UTC-0400 (Wed, 12 Jul 2023 15:53:31 -0700)
Michael Peddemors via mailop 
is rumored to have said:


On 2023-07-12 12:53, Jaroslaw Rafa via mailop wrote:
Most of regular consumer email users don't have any reason for this. 
As Bill
Cole, whom I was replying to, wrote - nobody would try to impersonate 
you or
me in a phishing campaign for financial gain, because there won't be 
any.


hehehe.. they do it all the time.. It's your contacts that will fall 
for it, and it will probably be to place a trojan.. and clean out 
THEIR data, and banking information..


I've been having waves of both random and targeted email forgeries for 
25+ years. I've had my personal mailserver knocked offline by the 
bounces of a spam run that used entirely invented scconsult.com 
addresses. The price of using Usenet for over a decade with a real email 
address.


I've never had a personal or professional contact tell me that they've 
received mail forged to appear to be from me. Not using my personal nor 
professional email addresses. I have no secondary evidence of that 
either. Maybe that's because all of my contacts know that I don't send 
anyone random message or anything in HTML so they just ignore it, but I 
doubt that. It just does not happen. I don't believe that I am special.


I am not saying that random people don't hit the bad luck lottery like 
this every day, just that most people will never have it happen to them 
while some people will see a lot of it.




Trust me, fought the whole SPF for a long while, it was 1/2 baked.. 
but when a bank or a large instition publicizes a clean SPF record.. 
honour it.. they will be forged more..


Yes. That's what SPF is good for: protecting senders of high-value mail 
from forgery.


I don't ignore SPF/DKIM/DMARC entirely, but they are very low-value 
tests in differentiating between legitimate and illegitimate email 
relative to their processing cost. They only provide usable in formation 
for those domains that one already is familiar with.



--
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/13/23 4:00 AM, Hans-Martin Mosner via mailop wrote:
Has anyone on this list tried forwarding (e.g. for ex-employees) via 
attachment?


I have done exactly this on a onesie-twosie / manual basis.

I have .forward files on systems that I administer and can run into 
problems when I send an email from my main account to said system 
account -- for testing purposes.  The messages make it to the system and 
the system tries to forward them per traditional .forward.  The problem 
is that my main mail system rejects them as that system is not 
authorized (SPF) to send messages claiming to be me.  --  SPF is working 
exactly like it should be.


The testing that I've done of having those messages be sent as a 
message/rfc822 attachment have worked out perfectly in this scenario.


The original message would be kept intact, while the outer 
message clearly originates with the forwarding agent who may even add a 
human readable reminder to the addressee to let the sender know about 
the changed address.


Exactly!

Opening message attachments should be possible with most modern MUAs, 
but TBH I don't really have much experience with that.


Sadly, I've run into too many -- what I'll call -- contemporary MUAs 
that don't handle message/rfc822 in what I consider to be an acceptable 
manner.  Specifically, for a long time one of the email oligarch's web 
mail interface utterly failed to handle message/rfc822 and had zero hope 
of forwarding such messages.


My intention, once I find sufficing round2it chits is to write something 
that I can put into venerable .forward files to receive the message from 
STDIN and compose a new message outgoing message with the incoming 
message as a message/rfc822 attachment.


Aside:  I'm still undecided if I want to rely on the system's email 
stack to send the new message out -or- if I want to have minimal 
connectivity to my primary email server for outbound submission.  If I 
do the latter I'll likely want to make the script more self hosted and 
rely on fewer living off the land type resources.


I have found that originating a new email with a message/rfc822 
attachment to work exceedingly well.  Better than .forward did 25 years 
ago.  Specifically it maintains the message as it was received and does 
not have any additional headers or modifications made to it.




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

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

[Florian.Kunkel--- via mailop]

On top of that a mailbox receiving such a forwarded message could "unpack" it 
automagically, provided it trusts the forwarding instance signature.
So the message appears as delivered locally with original signatures intact, 
and the MUA opening the message would not have to open an attachment anymore.

Florian

Von: mailop  Im Auftrag von Hans-Martin Mosner via 
mailop
Gesendet: Donnerstag, 13. Juli 2023 11:00
An: mailop@mailop.org
Betreff: Re: [mailop] Guide for setting up a mail server ?

Has anyone on this list tried forwarding (e.g. for ex-employees) via 
attachment? The original message would be kept intact, while the outer message 
clearly originates with the forwarding agent who may even add a human readable 
reminder to the addressee to let the sender know about the changed address.

Opening message attachments should be possible with most modern MUAs, but TBH I 
don't really have much experience with that.

Cheers,
Hans-Martin

Am 13. Juli 2023 09:46:11 schrieb Andrew C Aitchison via mailop 
mailto:mailop@mailop.org>>:

On Wed, 12 Jul 2023, Michael Peddemors via mailop wrote:

And yes, email forwarding will break.. but email forwarding remotely should
be killed off anyways.. everyone can log into two accounts.

Universities would like to allow the world to contact staff who have
recently left. We forward paper mail; why not email ?
Former staff don't have door keys.

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

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

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

[Hans-Martin Mosner via mailop]

Has anyone on this list tried forwarding (e.g. for ex-employees) via 
attachment? The original message would be kept intact, while the outer 
message clearly originates with the forwarding agent who may even add a 
human readable reminder to the addressee to let the sender know about the 
changed address.


Opening message attachments should be possible with most modern MUAs, but 
TBH I don't really have much experience with that.


Cheers,
Hans-Martin

Am 13. Juli 2023 09:46:11 schrieb Andrew C Aitchison via mailop 
:



On Wed, 12 Jul 2023, Michael Peddemors via mailop wrote:


And yes, email forwarding will break.. but email forwarding remotely should
be killed off anyways.. everyone can log into two accounts.


Universities would like to allow the world to contact staff who have
recently left. We forward paper mail; why not email ?
Former staff don't have door keys.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
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] Guide for setting up a mail server ?

[Thomas Walter via mailop]

Hey Michael,

On 13.07.23 00:53, Michael Peddemors via mailop wrote:
And yes, email forwarding will break.. but email forwarding remotely 
should be killed off anyways.. everyone can log into two accounts.


Everyone has always been able to log into two accounts. There are other 
reasons why this functionality was created.


I have sold one of my personal domains. The buyer agreed to forward the 
personal address I had used to a new mailbox for a while. So I can 
switch over wherever it is still in use, have access to "2FA 
confirmations" or "password recovery" functions where needed, etc.


I am not supposed to be able to send emails using their servers anymore, 
so I didn't get my own account.


Regards,
Thomas Walter

--
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/


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

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

[Andrew C Aitchison via mailop]

On Wed, 12 Jul 2023, Michael Peddemors via mailop wrote:

And yes, email forwarding will break.. but email forwarding remotely should 
be killed off anyways.. everyone can log into two accounts.


Universities would like to allow the world to contact staff who have 
recently left. We forward paper mail; why not email ?

Former staff don't have door keys.

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

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

[K. M. Peterson via mailop]

On Sun, Jul 9, 2023 at 18:52 John Levine via mailop 
wrote:

> A friend of mine wants to set up a mail server on a VPS and asked me what
> he needs to do beyond the obvious setting up postfix and dovecot.  Is there
> a good summary somewhere?


So, at the risk of totally missing the point, I’ll add a different branch.
Sadly, from some experience…

1. There is a management element missing in these discussions. How does
your friend plan to maintain credentials for those using his service?
There isn’t really any in-protocol way to, for example, allow an end-user
to change their password.

2. Supporting people configuring their mail clients - documenting how to
set up Mac Mail.app/Thunderbird/Outlook, etc.  Bit of work there, too.

3.  Spamassassin setup?  Decisions on marking or automatically (sieve?)
routing to a Junk mailbox, or even dropping - assuming you reject what you
can before spooling the message data.

4. Managing space, automating Trashes deletion, backups.  Ayeee, and people
expect vacation responders.  I’ll bet that is another thread that I’m not
going to pick up.

Clearly to this point there has been lots of good discussion in the weeds
(and this IS the mailop list, after all) but I’ve set up a couple of these
and found I spent a whole lot of time on, er, “details” like this.
Offering access via a web-based UI will fix some but not all of these
issues, of course, but the intended user base may need consideration at a
different level.

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

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

[Michael Peddemors via mailop]

On 2023-07-12 12:53, Jaroslaw Rafa via mailop wrote:

Most of regular consumer email users don't have any reason for this. As Bill
Cole, whom I was replying to, wrote - nobody would try to impersonate you or
me in a phishing campaign for financial gain, because there won't be any.


hehehe.. they do it all the time.. It's your contacts that will fall for 
it, and it will probably be to place a trojan.. and clean out THEIR 
data, and banking information..


Trust me, fought the whole SPF for a long while, it was 1/2 baked.. but 
when a bank or a large instition publicizes a clean SPF record.. honour 
it.. they will be forged more..


And yes, email forwarding will break.. but email forwarding remotely 
should be killed off anyways.. everyone can log into two accounts.


Going back to slaying dragons.. This thread is getting a bit off the 
original posters question.


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

[Jaroslaw Rafa via mailop]

Dnia 12.07.2023 o godz. 13:58:21 Grant Taylor via mailop pisze:
> 
> IMHO, some -- but not all -- that choose not to publish any
> information to make the recipient's lives any easier are somewhat
> choosing to say "I don't care, I'm not going to lift a finger, and
> you must do all the work, even if it's ten times the work compared
> to if I had given you the smallest amount of data."  --  I try to be
> a better net'itizen than that.  A few people / organizations have
> very specific reasons for not publishing information.

I would say otherwise.

A few people / organizations DO have reason to publish SPF/DKIM/DMARC. These
are the ones who send transactional mail. These - when impersonated - could
cause harm to recipients by eg. redirecting them to a malicious website. 
Eg. said delivery companies, online stores, banks etc.

Most of regular consumer email users don't have any reason for this. As Bill
Cole, whom I was replying to, wrote - nobody would try to impersonate you or
me in a phishing campaign for financial gain, because there won't be any.

If I receive mail from an unknown account on Gmail, what does the "pass"
result of SPF/DKIM/DMARC check actually tell me? What benefit gives me the
fact that the message actually does come from Gmail, if Gmail has millions
of users, unknown (but significant) percentage of them being malicious?

On the other hand, if I receive a message from someone I know, I can usually
recognize if it's actually written by that person or someone is trying to
impersonate him/her. The style of writing, relevance to actual events that
we are both concerned about and behavioral patterns (the time when the email
is sent, the correlation between topic and length of the message etc.) are
factors that we all intuitively, subconsciously take into account and are
able to recognize a forgery quite well.

So my opinion is that consumer-oriented email services, especially the big
ones, have in fact little reason to publish SPF/DKIM/DMARC. On the contrary,
corporate domains that are used specifically to send transactional email
have a big reason to do it.

As far as I remember, that was how these characteristics were initially
thought of. Only later the "email oligarchs" forced the attitude that they
should be quasi-mandatory for all.

And to return to the topic, my initial message was not about *not
publishing* SPF/DKIM/DMARC, but about *not checking* them on *incoming*
mail. I still say - I don't do it because I don't need it. I don't remember
a single phishing incident that wasn't at the same time an obvious and
blatant spam, easy to catch by antispam filters. And referring to your
comparison to "800 lb gorilla", if my "800 lb gorilla" does the job good
enough and causes no issues with potential CPU overload on my server, there
is absolutely no need for me to introduce additional "monkeys" that do
(partially) the same job.
-- 
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 ?

[Grant Taylor via mailop]

On 7/12/23 9:28 AM, Jaroslaw Rafa via mailop wrote:
Despite I said that SPF/DKIM/DMARC adds little to security, I would 
disagree with what you write here.


The problem is for recipients, not for senders.


I'd argue that almost all SMTP shortcomings are on the receiving end, 
not the sending end.


Assume someone receives a forged mail claiming to be from a delivery 
company (like DHL or similar) saying "Your package cannot be 
delivered, because additional delivery charge of 1$ is required, 
please go here to pay: ".


Detecting (some large subset of) spoofed senders is the primary use I 
see for SPF.


The primary use case I see is spoofed $ADMINISTRATOR from $YOUR_DOMAIN 
saying that your password is expiring and needs to be reset or that you 
have a quarantined message please check it.


Even if one in 1000 people who receive it logs in to the fake 
payment gateway - and in turn will have their online banking 
credentials intercepted and their money stolen - it is a HUGE damage 
if they send this phish to millions of people.


Agreed.

The same type of attack can be performed by impersonating basically 
any company that sells something online, because the key point here 
is to direct recipients to the fake payment gateway, which allows the 
attacker to steal their money ("their" == recipients, not 
impersonated company).


That's one of the key attacks.  Another is to harvest email credentials 
to be used for other campaigns.


Theoretically SPF/DKIM/DMARC should protect against it. But this type 
of messages is also very well recognized and filtered by 
antispam/anti-malware software.


I see many examples of it where anti-spam / anti-virus / anti-malware 
don't detect it.


Almost all of those examples could easily be detected with SPF.

It's also enough that the attacker uses own domain that is similar to 
the impersonated one (for example uses dhl-courier.com or 
dhl-poland.com instead of dhl.com; both don't exist as of this 
writing) to pass all SPF/DKIM/DMARC tests (while the 
antispam/anti-malware software should still properly detect and 
filter the message).


I consider that to be a testament to how successful SPF can be such that 
it moved the problem from impersonation attack to a look-alike / homonym 
attack.  As in we caused the spammers to change their tactics because 
what they were doing no longer works.


Also, as I already said, this type of attack is usually carried out 
using SMS messages to mobile phones, not email (at least huge 
majority of phishing campaigns of this type that were reported by 
security-related websites in my country were carried out using SMS). 
 I don't remember any serious phishing incident in recent years that 
was related to email.


As an email administrator I can't do anything about SMS attacks.  But I 
can do something about email attacks.


Maybe this is because of more widespread use of SPF/DKIM/DMARC, but I 
rather suppose this is because much more potential victims can be 
reached via phone than via e-mail, and because it is much harder to 
verify on a phone what website you are logging to. The phishing 
message uses a link shortener (which seems understandable because of 
the limited length of a text message), people just click on that link 
and land on a website that looks just like the real one they are used 
to.


I've had people be annoyed with me that their password manager didn't 
offer to fill their password on the look-alike website only to later 
wish they had not copied and pasted their password after learning that 
they had just compromised themself.


Fuses blowing and circuit breakers tripping can be annoying.  But they 
are doing so for a reason.  Things are trying to keep us safe.  -- 
Don't put a penny in the fuse box and then wonder why you have an 
electrical fire.


I also think that in the realm of filtering methodologies spam / virus 
filtering takes more computing than DMARC filtering, which takes more 
computing than DKIM, which takes more computing than SPF, which takes 
more computing than basic TCP connection filtering.  As such I try to do 
filtering using the fewest computational resources and thus start with 
the simpler things and work up in computational cost; TCP connection 
filtering -> SPF filtering -> DKIM filtering -> DMARC filtering -> spam 
/ AV filtering.  Can SpamAssassin detect something that fails SPF, quite 
likely.  Do I need the 800 lb gorilla that is SpamAssassin when I can 
use the 80 lb monkey that is SPF?  Nope.  I can use the 80 lb monkey 
perfectly fine.


As you say, the problem is for recipients.  So, why force the 
recipient's hand to use an 800 lb gorilla when they could use the 80 lb 
monkey if you simply provide them data to give the 80 lb monkey in the 
form of publish SPF information.


IMHO, some -- but not all -- that choose not to publish any information 
to make the recipient's lives any easier are somewhat choosing to say "I 
don't care, I'm not going to lift a finger, and you must d

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

[Grant Taylor via mailop]

On 7/12/23 4:11 AM, Slavko via mailop wrote:

BTW, my English is not best, don't take me word by word, please...


I don't think I've had any more trouble understanding you / your use of 
English as an additional language than I have had with others who use 
English as their primary language.  Different uses of meanings of words 
happens within languages too.


Perhaps that was goal, but if so, then i much more like the language 
eg. of RFC5321: ...something "is out of scope of this document".


That works for me.


The only problem here is, that some sites/tools doesn't respects
that broken signarure have to be treated as no signature. But that is
not DKIM's mistake.


I consider / classify that as a problem with a given site's use or 
configuration of DKIM not a problem with DKIM itself.


Individual DKIM installations and DKIM in general can cause problems. 
But the former is much more localized to the specific installation while 
the latter tends to be common across multiple installations.


What is not clear, at least from my point of view, is p=none policy. 
RFC mention it as way to not enforce any policy, but receive

reports.

But what then if DMARC's p=none, no DKIM and SPF fails? Have to be 
applied SPF result or have to be applied none policy?


In my opinion, if a domain's DMARC has a p=none, then you don't filter 
on  DMARC.  But you still independently apply your site's local SPF 
filtering policy preferably following the sending domain's stated SPF 
wishes.  The only thing that you would do with DMARC is send the 
notification of the result.


It is not about which action have i to choose. I wonder what one 
can/have to expect from other sides... Yes i know, their servers,

their rules, thus one can expect relative anything. But no one can
expect anything even on RFC compliant targets...


I think that we should safely expect sites to be largely RFC, or BCP, 
compliant.  I consider that to be the middle of the road and for people 
to stay on their side of said road.



BTW, i apply pure SPF (+ DKIM) in case of DMARC's p=none.


1)  I would expect you to apply SPF independently of DKIM and DMARC if 
the sending domain publishes SPF records.


2)  I would expect you to apply DKIM independently of SPF and DMARC if 
the message has DKIM headers and the sending domain publishes DKIM 
information.


3)  I would expect you to apply DMARC using the aforementioned SPF and / 
or DKIM results if the sending domain publishes DMARC information.


A DMARC policy of none simply elides that 3rd step to me.


Of course, i do my best effort to be as interoperable as i can/know.
I consider that as crucial in mixed environment, as Internet is.


Perhaps ISP was not right abbreviation, sorry for that. I meant email
provider, but i want to avoid ESP abbreviation as it is often used
with conjunction of mass mail here.


I think that ISP and ESP are both correct.  ISP is probably the older 
answer with ESP being the newer answer.


As with all things (Internet related) some are abused or used for things 
we don't like and they can earn an unpleasant meaning.  But I believe 
that Email Service Provider is exactly that, a company that provides 
email service.  What that email service is used for it independent of 
the fact that it is providing email service.


Yes, there are some very questionable / shady ESPs.  But there are still 
many good ESPs.



IMO we basically agree, that plain text connection over public net
have to be secured. I would consider setting VPN for mail only as too
mutch effort, especially for regular users.


I absolutely agree that using some form of encryption is strongly 
recommended and that not using encryption is ill advised.



Sure, there are cases when encryption is not needed, eg. i don't
encrypt communication to 127.0.0.0/8 and ::1, nor over LXC internal
bridge. But my original point was about connections over public and
semi-public networks.

But then nowadays best practices have to mention it.


Yes, encryption of some form is very much so a SHOULD in RFC speak.


But IMO in case of foreign services here is another mean: one cannot
expect, that it will be provided.


That surprises me.

Perhaps other parts of the world have been using TLS, either implicit or 
explicit via STARTTLS, for so long that they are now no longer offering 
service without TLS.


My experience has been that unencrypted connections are still offered in 
the areas where I'm interacting.  Usually unencrypted will work close to 
the service (as in connected to the ISP's network) but may not work 
further away.


I still people using really old configurations without TLS and ISPs not 
choosing TLS when helping customers set up new systems.


In some ways, TLS has been viewed as "oh, you're one of the people that 
want to be really secure", let me get the documents.


The notable exceptions that I've seen are the email oligarchs, some of 
whom tend to be charging full speed ahead and dragging the rest of us 
with 

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

[Jaroslaw Rafa via mailop]

Dnia 12.07.2023 o godz. 08:53:16 Bill Cole via mailop pisze:
> For the overwhelming majority of sending systems, the only internal
> security benefit to implementing SPF/DKIM/DMARC is to make
> impersonation of local users by outsiders for the purpose of fraud
> (so-called "BEC") much harder.
> 
> For most sending domains, targeted forgery to the world at large is
> a non-problem. No one is out there impersonating you or me in email
> to random strangers for financial gain. Most businesses do not have
> widespread 'brand value' that can be stolen by random broadcast
> forgery.

Despite I said that SPF/DKIM/DMARC adds little to security, I would disagree
with what you write here.

The problem is for recipients, not for senders.

Assume someone receives a forged mail claiming to be from a delivery company
(like DHL or similar) saying "Your package cannot be delivered, because
additional delivery charge of 1$ is required, please go here to pay: ".

Even if one in 1000 people who receive it logs in to the fake payment
gateway - and in turn will have their online banking credentials intercepted
and their money stolen - it is a HUGE damage if they send this phish to
millions of people.

The same type of attack can be performed by impersonating basically any
company that sells something online, because the key point here is to direct
recipients to the fake payment gateway, which allows the attacker to steal
their money ("their" == recipients, not impersonated company).

Theoretically SPF/DKIM/DMARC should protect against it. But this type of
messages is also very well recognized and filtered by antispam/anti-malware
software.

It's also enough that the attacker uses own domain that is similar to the
impersonated one (for example uses dhl-courier.com or dhl-poland.com instead
of dhl.com; both don't exist as of this writing) to pass all SPF/DKIM/DMARC
tests (while the antispam/anti-malware software should still properly detect
and filter the message).

Also, as I already said, this type of attack is usually carried out using
SMS messages to mobile phones, not email (at least huge majority of phishing
campaigns of this type that were reported by security-related websites in my
country were carried out using SMS). I don't remember any serious phishing
incident in recent years that was related to email.

Maybe this is because of more widespread use of SPF/DKIM/DMARC, but I rather
suppose this is because much more potential victims can be reached via phone
than via e-mail, and because it is much harder to verify on a phone what
website you are logging to. The phishing message uses a link shortener
(which seems understandable because of the limited length of a text
message), people just click on that link and land on a website that looks
just like the real one they are used to.
-- 
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 ?

[Taavi Eomäe via mailop]

On 12/07/2023 15:53, Bill Cole via mailop wrote:
For most sending domains, targeted forgery to the world at large is a 
non-problem. No one is out there impersonating you or me in email to 
random strangers for financial gain.


That is simply not true. For the past two years we have been seeing an 
ongoing onslaught of malicious actors "forging" four-letter .com 
domains. There have been actual cases of the owners of those domains 
wondering why they're ending up in spam. The answer is simple - sorry, 
your letters are not differentiable enough from spam. That's just one 
example of many.


You're never too small to become random collateral. I'd say you're never 
so small to be impersonated either, but I can't share examples of that.


Mechanisms for general public authentication of email from strangers 
exist for the primary benefit of big senders, their customers, and 
their prospective customers who need to know that their spam is 
authentic. 


So yeah, that is absolutely false.



smime.p7s
Description: S/MIME Cryptographic Signature
___
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-12 at 05:46:47 UTC-0400 (Wed, 12 Jul 2023 11:46:47 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:

Exactly, because from my experience SPF, DKIM and DMARC bring very 
little

(if anything at all) to security. I


TRUTH.

For the overwhelming majority of sending systems, the only internal 
security benefit to implementing SPF/DKIM/DMARC is to make impersonation 
of local users by outsiders for the purpose of fraud (so-called "BEC") 
much harder.


For most sending domains, targeted forgery to the world at large is a 
non-problem. No one is out there impersonating you or me in email to 
random strangers for financial gain. Most businesses do not have 
widespread 'brand value' that can be stolen by random broadcast forgery. 
Mechanisms for general public authentication of email from strangers 
exist for the primary benefit of big senders, their customers, and their 
prospective customers who need to know that their spam is authentic.



--
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 ?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 18:47:03 Grant Taylor via mailop pisze:
> 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.

Exactly, because from my experience SPF, DKIM and DMARC bring very little
(if anything at all) to security. I have written above - this is only to
satisfy Google's requirements. Stupid requirements, IMHO, but as you said -
their server, their rules, if I want to send mail to them I need to have
(outgoing) SPF, DKIM and DMARC set up. That's the *only* reason why I had
set them up at all.

> 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.

I had (and still have) no problems whatsoever with phishing without having
to check SPF, DKIM or DMARC. I simply don't need them. Phishing messages
are already caught by antispam filters - I look from time to time into what
my antispam filters have caught and I see a few phishing messages there. 
They are usually so obviously blatant that I wonder how anybody could fall
victim to them - like those famous "I have recorded you masturbating to porn
websites, send me money" emails.

In fact, I receive more phishing via text messages on my phone than I do on
my email. The SMS phishing is actually far more dangerous, because on a
phone you have very little possibility to check if a message is genuine
(there are no headers to look into etc.), and usually shortened links are
used in the message, so you don't know where the link points to. But if you
use some reasoning, those phishing SMS messages also look little probable to
be authentic.

Email phishing is from my point of view a practically nonexistent thing. So
why bothering configuring tools that are theoretically meant to protect
against it (but in my opinion are actually not helpful at all), if they
wouldn't bring any benefit?

Of course YMMV, as I said. I have never experienced phishing as an actual
problem.
-- 
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 ?

[Slavko via mailop]

Dňa 11. júla 2023 18:23:45 UTC používateľ Grant Taylor via mailop
 napísal:

BTW, my English is not best, don't take me word by word, please...

>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.

Yes.

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

Perhaps that was goal, but if so, then i much more like the language
eg. of RFC5321: ...something "is out of scope of this document".

>I think SPF itself is relatively straightforward.

Yes, it is.

>IMHO DKIM is slightly more complex:

More complex to implement, but othervise straightforward.

The only problem here is, that some sites/tools doesn't respects that
broken signarure have to be treated as no signature. But that is not
DKIM's mistake.

>DMARC is more complicated yet in what it checks.

Its check & implementation is straightforward too.

What is not clear, at least from my point of view, is p=none policy.
RFC mention it as way to not enforce any policy, but receive reports.

But what then if DMARC's p=none, no DKIM and SPF fails? Have to be
applied SPF result or have to be applied none policy?

It is not about which action have i to choose. I wonder what one
can/have to expect from other sides... Yes i know, their servers, their
rules, thus one can expect relative anything. But no one can expect
anything even on RFC compliant targets...

BTW, i apply pure SPF (+ DKIM) in case of DMARC's p=none.

> Of course this is predicated on you wanting to utilize said
> specification in an interoperable way.

Of course, i do my best effort to be as interoperable as i can/know. I
consider that as crucial in mixed environment, as Internet is.

>Using your ISP as a smart host is, or was, a good way to do this for
>many people for many years.  Now, things like SPF make this a little
>bit more difficult.

Perhaps ISP was not right abbreviation, sorry for that. I meant
email provider, but i want to avoid ESP abbreviation as it is often
used with conjunction of mass mail here.

>Can we agree to disagree?

IMO we basically agree, that plain text connection over public
net have to be secured. I would consider setting VPN for mail
only as too mutch effort, especially for regular users.

>So again, TLS is not strictly required for email to function.

Sure, there are cases when encryption is not needed, eg. i
don't encrypt communication to 127.0.0.0/8 and ::1, nor
over LXC internal bridge. But my original point was about
connections over public and semi-public networks.

But then nowadays best practices have to mention it.

>The four meanings that Meriam-Webster provides for deprecation all
>imply that something is depreferenced, desire to avoid, should not
>use. However none of them mean that it is non-functional.

But IMO in case of foreign services here is another mean: one
cannot expect, that it will be provided.

>Again, legacy is not the same as non-functional.

I understand legacy as something to avoid if possible and/or
expect, that it can be not provided by remote side.

>Questionable is not the same as non-functional.

Sure. By questionable i meant, that i often read about LAN as
about secure environment. Of course, it is more secure than
public net. But eg. in job i didn't consider our LAN as secure
network, for warious reasons.

>All three of your terms; deprecated, legacy, and questionable have
>significantly more to do with if they would be chosen to be used today
>and effectively nothing to do with if they function or not.

We are still talking about "best practices", right? My words
was not meant as to be included in it, but about ponting to
what have to be take into account, when writing that practices.

>The protocols themselves still function and do the job that they were
>designed to do.

Sure, SMTP, IMAP and/or POP (and many other application layer
protocols) will work independly of that if its transport channel is
secured or not. That is not the question. The question is who
can see communication content and where the clients will be
connected to.

AFAIK, the TLS was designed to work independently on upper layer
protocols.

>Sadly, I find that MTA-MTA use of STARTTLS is not nearly what I would
>hope that it is.

Can you please elaborate more about this?

>> Please, how this DKIM certificate looks as? Where its format is
>> defined?
>
>I'd have to go look things up, but I don't think that the certificate
>format is defined anywhere.  Rather DKIM focuses on the permutations
>(read: math) applied to selected part of the messages.  Howe the
>keying material is stored for that on a given server is implementation
>dependent.

My pont was, that DKIM uses keys pair. The certificate, as known eg. in
TLS, is basically public key + couple additional data... AFAIK these
additional data are not used in DKIM, just keys.

>SMTP, POP3, and IMAP all 

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] 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] 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] 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] 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] 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] 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] 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

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

[Sean Kamath via mailop]

Grant,

Well put.

I was just going to link to Gilles Chehade’s post 
(https://poolp.org/posts/2019-12-15/decentralised-smtp-is-for-the-greater-good/)

I don’t find running my own personal email server that hard or time consuming.  
The most time consuming element being “keep OpenBSD updated”. :-)

Sean

> On Jul 10, 2023, at 09: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.
> 
> I'll VERY STRONGLY ENCOURAGE at the very least MX record(s).
> 
> SPF, DKIM, and DMARC are the order that I'd advise others be implemented.
> 
> Chances are quite good that you will be able to exchange email with domains 
> that aren't hosted by the email oligarchs.
> 
> Aside:  Have enough email administrators given up the torch and now started 
> praying at the alter of the email oligarchs?
> 
>> * manage reverse lookup records, including managing the uncertain chain of 
>> authority between the instance and the nearest SOA
> 
> I didn't have a problem with reverse DNS being required 22 years ago and I 
> have even less of a problem with it today.
> 
> 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.
> 
> There is also the fact that unless the ISP is doing egress filtering -- 
> that's it's own independent discussion which the lack thereof helps me in 
> this discussion -- users can probably have acceptable success with all but 
> the email oligarchs if they simply have their MTA hello as the name that the 
> ISP assigns to the connection presuming that the ISP has forward and reverse 
> DNS configured therefor.
> 
>> * manage certificates associated with TLS for SMTP and IMAP
> 
> I'll argue that TLS is not strictly required.
> 
> I'll absolutely agree that TLS is a best practice.
> 
> I'll also posit that IMAP is not required for email.
> 
>> * manage DKIM certificate
> 
> I maintain that DKIM is not a strict requirement.
> 
>> * manage one's upstream to addres

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

[Grant Taylor via mailop]

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.


I'll VERY STRONGLY ENCOURAGE at the very least MX record(s).

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

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


Aside:  Have enough email administrators given up the torch and now 
started praying at the alter of the email oligarchs?


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


I didn't have a problem with reverse DNS being required 22 years ago and 
I have even less of a problem with it today.


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.


There is also the fact that unless the ISP is doing egress filtering -- 
that's it's own independent discussion which the lack thereof helps me 
in this discussion -- users can probably have acceptable success with 
all but the email oligarchs if they simply have their MTA hello as the 
name that the ISP assigns to the connection presuming that the ISP has 
forward and reverse DNS configured therefor.



* manage certificates associated with TLS for SMTP and IMAP


I'll argue that TLS is not strictly required.

I'll absolutely agree that TLS is a best practice.

I'll also posit that IMAP is not required for email.


* manage DKIM certificate


I maintain that DKIM is not a strict requirement.


* manage one's upstream to address PBL issues


Maybe, maybe not.


* keep the MTA secure and free from DOS attack


I have problems with that statement.

1st:  What is "secure" in this context?

2nd:  Why is anything other than an MTA less susceptible to a DOS attack 
than an MTA?


Also, Michael W. Lucas's I Have A Dream comment about "goals" vs 
"dreams" comes to mind.


TL;DR:  Focus on goals, things that you can influence, and don't worry 
about dreams, things that you have no influence over.


Link - I Have A Dream
 - https://mwl.io/archives/22749

ALSO back in 2011 (when the world was a little simpl

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

[Al Iverson via mailop]

I covered that here:
https://www.spamresource.com/2020/07/small-mailserver-best-current-practices.html

Anybody who would like to write up a guide, I'd be happy to publish it
on Spam Resource (or link to it if you publish it elsewhere). Feel
free to reach out.

Cheers,
Al Iverson

-- 

Al Iverson / Deliverability blogging at https://www.spamresource.com
Subscribe to the weekly newsletter at https://ml.spamresource.com
DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Richard Clayton via mailop]

In message <20230709223922.dd59afd9f...@ary.qy>, John Levine via mailop
 writes

>A friend of mine wants to set up a mail server on a VPS and asked me what
>he needs to do beyond the obvious setting up postfix and dovecot.  Is there
>a good summary somewhere?

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 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. In discussions with Eliot Lear we ended up
with a list of things you had to do:

* configure and manage the MTA

* arrange for a backup MTA

* manage DNS MX, DKIM, DMARC and SPF records

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

* manage certificates associated with TLS for SMTP and IMAP

* manage DKIM certificate

* manage one's upstream to address PBL issues

* keep the MTA secure and free from DOS attack

>I'm thinking of things like:
>
>- choose a provider that has decent mail behavior, e.g., not Digital Ocean
>
>- make sure the MTA's forward and reverse DNS match
>
>- set up an SPF record, probably "v=spf1 mx ~all"
>
>- set up DKIM signing for each domain you host, make the
>DKIM domain match the From: domain
>
>= start slow and look at any bounces
>
>- maybe collect DMARC stats but for a small volume MTA, not very interesting

ALSO back in 2011 (when the world was a little simpler perhaps) I worked
on a M3AAWG BCP on this topic -- which eventually went nowhere ... the
list then was (and I stress this was not sufficiently peer reviewed then
to be authoritative, but it was written by some experts)

* Use a static IPv4 address for your email system

* Do not share this IPv4 address with user machines

* Do not host your email system 'in the cloud'

* Make sure that your IP address is not listed in the PBL

* Provide an MX record

* Provide meaningful and consistent reverse DNS

* Your system should say HELO (or EHLO) with its hostname

* Keep your software completely up-to-date

* Ensure that only authorised users can send email through your system. 

* Limit outgoing email volumes

* Accept reports of problems with your systems

* Review the mail system logs on a regular basis

* Be reliable (viz have at least 4 9s availability)

* Don't be an open relay

* Don't create backscatter

* Maintain a good reputation

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Carsten Schiefner via mailop]

Home - maddy
https://maddy.email/

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: "Taavi Eomäe via mailop" 
To: John Levine , mailop@mailop.org
Sent: Mo., 10 Juli 2023 10:12
Subject: Re: [mailop] Guide for setting up a mail server ?

Instead of struggling with Postfix, OpenDKIM, Dovecot and friends (and 
losing out on quite a few features). I'd really recommend looking at 
Maddy instead.

Immensely better "UX" than the currently mentioned approach.

___
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]

Instead of struggling with Postfix, OpenDKIM, Dovecot and friends (and 
losing out on quite a few features). I'd really recommend looking at 
Maddy instead.


Immensely better "UX" than the currently mentioned approach.



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

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

[Michael Rathbun via mailop]

On 9 Jul 2023 22:07:38 -0400, John Levine via mailop 
wrote:

>In fact it's for people but you never know what some people will do.
>Don't start by letting your chatty user send "here's my new address"
>to all 10,000 people in his address book.

Ah.  Somebody doing that on my server would get an automated but polite notice
that we need to have a discussion of domain policy and expected behavior
before any more email could go out.  Good fences, good neighbors, &c.

mdr
-- 
   We are all temps.
  -- Daisy Adair

___
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 Michael Rathbun via mailop  said:
>On 9 Jul 2023 18:39:22 -0400, John Levine via mailop 
>wrote:
>
>>= start slow and look at any bounces
>
>This implies to me that this will be a broadcast server rather than mailboxes
>for individuals and businesses.  If so, there are some paragraphs that might
>need to be added, especially about list hygiene.

In fact it's for people but you never know what some people will do.
Don't start by letting your chatty user send "here's my new address"
to all 10,000 people in his address book.

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

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

[Michael Rathbun via mailop]

On 9 Jul 2023 18:39:22 -0400, John Levine via mailop 
wrote:

>= start slow and look at any bounces

This implies to me that this will be a broadcast server rather than mailboxes
for individuals and businesses.  If so, there are some paragraphs that might
need to be added, especially about list hygiene.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

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