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] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Gellner, Oliver via mailop]

> On 13.07.2023 at 20:52 Robert L Mathews via mailop wrote:
>
> On 7/13/23 11:12 AM, Jarland Donnell via mailop wrote:
>> Perhaps it's going off topic and apologies if so, but this makes me wonder a 
>> second thing. Who is, and why are they, adding subdomains to the PSL when 
>> subdomains above that in hierarchy are in the same zone file?
>
> Some domains that offer service to other people via subdomains do this to 
> prevent sharing of cookies, etc., between the subdomains.

Yes, cookies are not supposed to be shared between different apex domains. 
Neither are DNS zones :)

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

[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] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Gellner, Oliver via mailop]

> On 13.07.2023 at 17:55 Bill Cole via mailop wrote:
>
> It's not at all logically hard to meet that arbitrary requirement, you just 
> need a zone cut everywhere you have a MX record. I've run a DNS and mail 
> hosting environment that way. Zone files are very small and numerous. 
> *Logistically* changing an existing zone with many MXs for subdomains to that 
> model could be a  serious chore.

It has already been mentioned in the discussion last month but to reiterate: 
You can send emails from random.subdomain.scconsult.com to Yahoo just fine as 
long as scconsult.com has a SOA record, which is and has always been mandatory 
anyway. IMHO this requirement by Yahoo is a non-issue and automatically met by 
everyone except three groups:
1. Domains with misconfigured DNS as seen in this thread.
2. DNS zones that span over multiple different organizational domains as seen 
in the thread last month. Domains under different administrative control must 
not share the same SOA record.
3. Emails from made-up domain names, ie from spammers or other miscreants.

—
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] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Robert L Mathews via mailop]

On 7/13/23 11:12 AM, Jarland Donnell via mailop wrote:
Perhaps it's going off topic and apologies if so, but this makes me 
wonder a second thing. Who is, and why are they, adding subdomains to 
the PSL when subdomains above that in hierarchy are in the same zone file?


Some domains that offer service to other people via subdomains do this 
to prevent sharing of cookies, etc., between the subdomains.


For example, "a6a2a5081647f0470.awsglobalaccelerator.com" and 
"ab39e1e4da31f5b08.awsglobalaccelerator.com" are both run by Amazon AWS 
and in the same zone, but the content of those two subdomains is 
controlled by two entities who shouldn't trust each other, so 
"awsglobalaccelerator.com" is on the PSL to (hopefully) prevent their 
data from being combined.


--
Robert L Mathews
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Marcel Becker via mailop]

On Thu, Jul 13, 2023 at 11:19 AM Slavko via mailop 
wrote:

>
> Would not be more effective to not use technique prone to false
> positives? For both sides...
>

So you mean not trying to filter spam or fight spammers at all? I have not
seen a solution which doesn't produce false positives.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Jarland Donnell via mailop]

Perhaps it's going off topic and apologies if so, but this makes me 
wonder a second thing. Who is, and why are they, adding subdomains to 
the PSL when subdomains above that in hierarchy are in the same zone 
file?


On 2023-07-13 13:06, Robert L Mathews via mailop wrote:


On 7/13/23 10:44 AM, Jaroslaw Rafa via mailop wrote:

If .tld is on PSL, then example.tld will be the organizational domain. 
And
it definitely should have its own zone file, so it should have SOA. I 
can't

imagine a scenario in which it doesn't.


An example is something like "apc.homeoffice.gov.uk": its parent 
"homeoffice.gov.uk" is on the PSL, but both appear to be part of the 
same zone:


$ dig apc.homeoffice.gov.uk SOA

... QUERY: 1, ANSWER: 0, AUTHORITY: 1 ...

;; AUTHORITY SECTION:
homeoffice.gov.uk.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Slavko via mailop]

Dňa 13. júla 2023 17:41:51 UTC používateľ Marcel Becker via mailop 
 napísal:
>On Thu, Jul 13, 2023 at 10:35 AM Robert L Mathews via mailop <
>mailop@mailop.org> wrote:
>
>
>> I still think this is a check that's prone to false positives
>>
>
>Or other issues. Yes. That's why we are also helping where we can when
>folks reach out to us.

Would not be more effective to not use technique prone to false
positives? For both sides...

regards



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

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Robert L Mathews via mailop]

On 7/13/23 10:44 AM, Jaroslaw Rafa via mailop wrote:


If .tld is on PSL, then example.tld will be the organizational domain. And
it definitely should have its own zone file, so it should have SOA. I can't
imagine a scenario in which it doesn't.


An example is something like "apc.homeoffice.gov.uk": its parent 
"homeoffice.gov.uk" is on the PSL, but both appear to be part of the 
same zone:


 $ dig apc.homeoffice.gov.uk SOA

 ... QUERY: 1, ANSWER: 0, AUTHORITY: 1 ...

 ;; AUTHORITY SECTION:
 homeoffice.gov.uk.

--
Robert L Mathews
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Bill Cole via mailop]

On 2023-07-13 at 12:06:45 UTC-0400 (Thu, 13 Jul 2023 11:06:45 -0500)
Grant Taylor via mailop 
is rumored to have said:


On 7/13/23 10:49 AM, Bill Cole via mailop wrote:
It's not at all logically hard to meet that arbitrary requirement, 
you just need a zone cut everywhere you have a MX record. I've run a 
DNS and mail hosting environment that way. Zone files are very small 
and numerous. *Logistically* changing an existing zone with many MXs 
for subdomains to that model could be a  serious chore.


I question the veracity of "need a zone cut everywhere you have an MX 
record".


My current working understanding is "you need a zone cut for domains 
immediately subordinate of the PSL".


Right. I was speaking more directly to the OP's situation where they 
already have a big zone rooted at a PSL-listed domain and a lot of 
subdomains.




--
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] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Jaroslaw Rafa via mailop]

Dnia 13.07.2023 o godz. 10:23:24 Robert L Mathews via mailop pisze:
> 
> But anyway, if other people have this trouble, note that it can
> happen whether the MAIL FROM domain name is directly at a PSL
> breakpoint or not. The issue is just that there's no SOA found at
> the MAIL FROM domain name level, nor at the PSL organizational
> domain level (if different), so you need to make one of those exist.

I wonder what can be the real scenario when PSL organizational domain has
no SOA.

If .tld is on PSL, then example.tld will be the organizational domain. And
it definitely should have its own zone file, so it should have SOA. I can't
imagine a scenario in which it doesn't.

IMHO, this would be only possible if example.tld and .tld itself would be
defined in the same zone file. But that contradicts the very meaning of
.tld being on PSL! If domain is on PSL, it means its subdomains belong to
different administrative entities than the main domain, so they obviously
should have their own zone files and SOA.

If anybody knows such a scenario, could you please explain it?
-- 
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] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Marcel Becker via mailop]

On Thu, Jul 13, 2023 at 10:35 AM Robert L Mathews via mailop <
mailop@mailop.org> wrote:


> I still think this is a check that's prone to false positives
>

Or other issues. Yes. That's why we are also helping where we can when
folks reach out to us.

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

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Robert L Mathews via mailop]

On 7/12/23 9:42 PM, Felix Fontein via mailop wrote:

right now there is only a SOA record for `us.` itself and for
`ci.westfir.or.us.`, but for nothing inbetween.


Ugh, you're right, the customer has removed the delegation of 
westfir.or.us (I was testing on internal servers that still showed the 
results.)


And Marcel Becker describes that what Yahoo is actually doing is 
checking for an SOA in two places:


- the "domain name" used in a MAIL FROM, and
- the PSL-based organizational domain that's the parent of the subdomain 
(if any).


If neither exists, you get this error.

That explains the issue I saw (thanks!), although it means that the 
check isn't only run for MAIL FROM domains that are directly at a PSL 
delegation point, as was suggested in the thread in May.


I still think this is a check that's prone to false positives -- it's 
assuming things about other peoples DNS setups don't necessarily hold 
true. For example, even if a domain name is on the PSL, there's no 
reason that the same organization couldn't also host the DNS for the 
levels below it in the same zone file, in which case no SOA will exist 
for the level below.


But anyway, if other people have this trouble, note that it can happen 
whether the MAIL FROM domain name is directly at a PSL breakpoint or 
not. The issue is just that there's no SOA found at the MAIL FROM domain 
name level, nor at the PSL organizational domain level (if different), 
so you need to make one of those exist.


--
Robert L Mathews
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Marcel Becker via mailop]

On Thu, Jul 13, 2023 at 9:00 AM Bill Cole via mailop 
wrote:

>
> It is worth noting that this is in no way a "standard" or even a
> widely-known "best practice"
>

Nobody has claimed that.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Grant Taylor via mailop]

On 7/13/23 10:49 AM, Bill Cole via mailop wrote:
It's not at all logically hard to meet that arbitrary requirement, you 
just need a zone cut everywhere you have a MX record. I've run a DNS and 
mail hosting environment that way. Zone files are very small and 
numerous. *Logistically* changing an existing zone with many MXs for 
subdomains to that model could be a  serious chore.


I question the veracity of "need a zone cut everywhere you have an MX 
record".


My current working understanding is "you need a zone cut for domains 
immediately subordinate of the PSL".


My (limited) personal testing supports not needing a zone cut for a 
sub-domain of my personal domain.




Grant. . . .
___
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] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Bill Cole via mailop]

On 2023-07-13 at 10:15:27 UTC-0400 (Thu, 13 Jul 2023 07:15:27 -0700)
Marcel Becker via mailop 
is rumored to have said:




No. I might as well reveal the actual domain names involved, since 
it's

not particularly secret: it's "westfir.or.us" and "ci.westfir.or.us".


It's actually not that complicated. We want to see an SOA record for 
either

the domain OR the organizational domain.

We use the PSL to determine the organizational domain.


It is worth noting that this is in no way a "standard" or even a 
widely-known "best practice" and that it was entirely the invention of 
the Big Brains at Yahoo, the place that helped give us the ridiculous 
fragility of DKIM...




--
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] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Bill Cole via mailop]

On 2023-07-12 at 18:38:05 UTC-0400 (Wed, 12 Jul 2023 15:38:05 -0700)
Robert L Mathews via mailop 
is rumored to have said:

Today I had a customer complain that mail they send to AOL or Yahoo 
addresses was being returned with:


451 Message temporarily deferred due to unresolvable RFC.5321 from 
domain; see https://postmaster.yahooinc.com/error-codes


According to that page,

"- These errors indicate that the domain used to the right of the @ in 
the MAIL FROM does not appear to be a real domain.
- We determine if the domain name exists by using an SOA query; 
therefore, if multiple subdomains are used in MAIL FROM commands, then 
besides setting up a DNS A or MX record (perhaps using a wildcard), 
then SOA records must be set up as well."


This is surprising!



It's also not the whole story.

Yahoo does not reject mail from valid addresses in subdomains of 
scconsult.com which have MX or A records but no SOA or NS records.


I have done absolutely nothing to achieve that. I only know it to be 
true because someone mentioned this issue on some mailing list a few 
weeks ago and I tested myself.


Supposedly, Yahoo is basing this on the PSL, only requiring domains at 
registry boundaries to have SOAs. This much more subtle than but just as 
stupid as what their error page says.


It's not at all logically hard to meet that arbitrary requirement, you 
just need a zone cut everywhere you have a MX record. I've run a DNS and 
mail hosting environment that way. Zone files are very small and 
numerous. *Logistically* changing an existing zone with many MXs for 
subdomains to that model could be a  serious chore.


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

[mailop] Auto-forwarding emails as attachments

[Carsten Schiefner via mailop]

Hans-Martin & all -

On 13.07.2023 11:00, 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.


this is what I have thought up to tackle such tasks:



#!/bin/bash mailbody="$(grep -v '^From ' -)" today="$(date '+%d.%m.%Y')" 
msgid="$(echo "$mailbody" | grep -i '^message-id:' | sed 's/^[^:]*: 
//')" readarray -t recipients < ./addressees.list for i in 
"${recipients[@]}" do v_mailpart="$(date '+%s%N'|sha1sum|sed 's/ .*//')" 
echo "References: $msgid Subject: Forwarded email of $today for $i To: 
$i From: Carsten Schiefner  BCC: 
carsten@schiefner.berlin X-Forwarded-Message-Id: $msgid In-Reply-To: 
$msgid Content-Type: multipart/mixed;  boundary=\"$v_mailpart\" 
MIME-Version: 1.0 This is a multi-part message in MIME format. 
--$v_mailpart Content-Type: text/plain; charset=\"UTF-8\" 
Content-Transfer-Encoding: quoted-printable --$v_mailpart Content-Type: 
message/rfc822;  name=\"Attached Message.eml\" 
Content-Transfer-Encoding: 8bit Content-Disposition: attachment; 
 filename=\"Attached Message.eml\" $mailbody --$v_mailpart--" | exim 
-ti done





The script is invoked from the .procmailrc file:



:0 * ^To: .*[addressee's email address] | ./auto_forward_script




The email addresses in the "addressees.list" text file should have the 
format "first_name last_name " or something similar that 
will equally be understood by exim resp. your chosen MTA.


Feel free to use it and - even better! :-) - improve it. If that occurs, 
please be kindly asked to share your result here again.


Cheers,

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

Re: [mailop] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Marcel Becker via mailop]

>
>
> No. I might as well reveal the actual domain names involved, since it's
> not particularly secret: it's "westfir.or.us" and "ci.westfir.or.us".
>
>
It's actually not that complicated. We want to see an SOA record for either
the domain OR the organizational domain.

We use the PSL to determine the organizational domain.

or.us is in the PSL. So the organizational domain seems to be westfir.or.us
.

Contrary to your original mail that does not have a SOA.

ci.westfir.or.us seems to have one though. So that should not have issues.

So if you make sure your organizational domains have an SOA (as you
originally stated you do), you should be fine.

-- Marcel
___
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] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Grant Taylor via mailop]

On 7/13/23 2:24 AM, Gellner, Oliver via mailop wrote:
The requirement is actually less restrictive as it only requires a 
SOA record and not additional A,  or MX records in DNS. It is not 
necessary that every hostname has a SOA record, that indeed would be 
unreasonable. Yahoo only requires a SOA record for the organizational 
domain (base domain). As "or.us" has been added to the PSL and the 
owner wants it to be treated as a TLD, a SOA record is required for 
westfir.or.us, however none exists.
I keep thinking that someone at Yahoo / AOL has forgotten the difference 
between a domain and a zone.


But then I re-read / test things and realize that this seems to center 
on things directly in domains listed in -- what I'm understanding to be 
-- Mozilla's Public Suffix List.


So I'm left thinking that this is an artificial -- not necessarily 
arbitrary -- restriction that Yahoo / AOL is imposing o things directly 
in PSL.


My concern is that it's quite possible to have sub-domains in the parent 
zone.  This used to be common for a lot of smaller entities that simply 
relied on their parent domain to manage the child's DNS as part of the 
parent domain's zone, especially with small entities that had no 
technical need nor desire to host their own DNS.


I did some minimal testing after reading this thread and skimming thread 
that Andy linked to from earlier this year.  I sent from the address I'm 
using now to my wife's Yahoo account and it was delivered to her inbox 
just fine.  I also sent from an address in a subdomain (e.g. 
test.tnetconsulting.net) to my wife.  That second message was delivered 
to her spam folder, but it was delivered.


I don't like this restriction, but I don't object to it as long as it's 
central to the PSL and direct children therein.  If it ever extends 
further into children of the PSL, then I'll be upset -- for all the good 
that will do.


My concern is that Yahoo / AOL isn't creating an arbitrary "every domain 
must have an SOA record" and completely loosing sight of the fact that 
SOAs belong to the /zone/ apex and are not associated with /domain/s.




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

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

[Paul Menzel via mailop]

Dear Bastian,


Thank you for your reply.

Am 11.07.23 um 19:43 schrieb Bastian Blank:


On Tue, Jul 11, 2023 at 05:47:12PM +0200, Paul Menzel via mailop wrote:

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

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


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

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


Correct, it’s an MX. (The DFN – Deutsche Forschungsnetz – offers a 
MailSupport service, running MXes doing mostly spam filtering and 
phishing, and then passes the messages on.)



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


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


The DFN-MailSupport supports DANE since September 2020 [6].


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


Agreed. That wasn’t my intention.


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


Indeed.


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


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


With Postfix 3.6 and empty `smtpd_tls_dh1024_param_file` (equals to 
auto) [7], Internet.nl shows DH 2048, but also ECDHE is supported.


Then I tried to configure the RFC 7219 ffdhe3072 parameters, but somehow 
the Internet.nl email test still says DH 2048 is used.


# wget -O /project/mx/etc/ffdhe3072.pem 
https://github.com/internetstandards/dhe_groups/blob/main/ffdhe3072.pem

# postconf -n smtpd_tls_dh1024_param_file
smtpd_tls_dh1024_param_file = /project/mx/etc/ffdhe3072.pem
# postfix reload

Viktor Dukhovni commented on postfix-users [8]:


This is misguided.  If 2048-bit RSA root CAs are good enough for WebPKI,
system software updates, ... then 2048-bit DH parameters are also  good
enough for opportunistic TLS in SMTP.


He recommended to ignore this test, which I will do, and set the 
parameter `smtpd_tls_dh1024_param_file` to empty.



Kind regards,

Paul


[6]: https://www.mailsupport.dfn.de/news/aktivierung-der-tlsa-records
[7]: https://www.postfix.org/postconf.5.html#smtpd_tls_dh1024_param_file
[8]: https://www.mail-archive.com/postfix-users@postfix.org/msg99647.html
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Gellner, Oliver via mailop]

On 13.07.2023 at 00:38 Robert L Mathews via mailop wrote:

> Aside from anything else, it implies that SOA records can be easily added to 
> solve this, similar to how you add MX or A records. But that is usually not 
> the case: SOA records can exist only at a DNS zone delegation boundary, not 
> at the level of any arbitrary hostname.
>
> I know AOL/Yahoo folks are on here. IS it intentional to be this restrictive, 
> effectively introducing a new DNS requirement for mail senders? If so, this 
> is going to be a problem for many people.
>
> To give a concrete example of the difficulty, we host mail and DNS for 
> "cityname.or.us". Our system generates a DNS zone file that originally looked 
> like:
>
>  $ORIGIN cityname.or.us
>  @  SOA   ns1.tigertech.net. a.tigertech.net. ( 1 2 3 4 5 )
>  @  MX 0  mx.tigertech.net.
>  @  A 192.0.2.44
>  @  (SPF and DKIM records omitted for brevity)

The requirement is actually less restrictive as it only requires a SOA record 
and not additional A,  or MX records in DNS.
It is not necessary that every hostname has a SOA record, that indeed would be 
unreasonable. Yahoo only requires a SOA record for the organizational domain 
(base domain). As "or.us" has been added to the PSL and the owner wants it to 
be treated as a TLD, a SOA record is required for westfir.or.us, however none 
exists.

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