Oh.
  I then thought i Cc: an email related IETF list.
  And i think that is ok (i am not subscribed there no more,
  though), because it is not destructive, but painstakenly
  iterates valid issues that are simply not addressed on high
  tables, causing lots of grief in real email life.

Austin Group Issue Tracker via austin-group-l at The Open Group wrote in
 <[email protected]>:
 ...
 |https://austingroupbugs.net/view.php?id=1998 
 ...
 | (0007492) kre (reporter) - 2026-09-03 11:46
 | https://austingroupbugs.net/view.php?id=1998#c7492 
 |---------------------------------------------------------------------- 
 |I might have been mistaken about the mailing list - the primary MX might
 |accept mail from munnari (the secondary won't - protected.outlook.com
 |destinations won't even reply to DNS queries for addresses).
 |
 |I will look into this more later, but perhaps all is not lost on the list
 |re-joining front after all. 

If all else fails you could get an email alias here (i would have
to look into postfix address rewriting), or does NetBSD not offer
email aliases?  I never understood your PTR refusal really,
i actively test this myself, reverse lookup should really work in
my opinion.  This is plain RFC 1034 from 1987.

And ok, they seem to have switched the external email provider
from XY to Microsoft.  I did not know that.  It is still external
and out of direct control, to some extend, it seems.
And last, 

 |And last, (since gmail is one of the destinations that refuses
 |mail from munnari) - re being a poor volunteer standards org,
 |I fully understand.   But running an e-mail server is not a very
 |onerous task, particularly if one ignores the mandates of the
 |almost monopolies and doesn't keep trying to keep up with their
 |ever changing demands.    But as (effectively anyway) an

Granted i am quite "bitten off", because the email part of the
IETF has emitted in the last 15-20 years what had devastating
effects, especially to myriads of small services and personal
email servers, at least in the western world, or the dependant
following, and e-mail server *is* that word you say, and that in
particular.
I am happy you stopped emitting consciously broken (?) DKIM
signatures, because i do not think that changes the email world to
anything better.

But it is a fight, and i wholeheartly agree and respect, yes
honour, that you are among those who fight on the right side, for
free and usable electronic email in a somewhat free international
network.  Yes.

Yet i for one would hope for an iterated DKIM, to replace all
those devastating, and, mind you, breaking and thus broken

- SPF (killing aliases, one of the eldest email features),
- ARC (braindead: putting cryptographic signatures on unverifiable
  fishy data),
- DMARC (completely mislead and misleading; signalling on domain
  level that emails should either verify SPF or DKIM, ie either IP
  address or message content, against some header field,
  mutilating the sense of that and more),

what caused masses of additional software to be deployed for
"sender rewriting scheme" application, for message content
mitigations, after masses of additional DNS lookups that is, that human
message readers still perceive as being emitted by "original
sender", what possibly is not correct, mind you, as well as

- DKIM (at least technically incomplete and attackable)

IETF emissions.  Massively increased software and admistration
complexity, incurred by people sitting high and not taking any
care.  (And what they plan is hot air that makes it worse, and
i can technically justify that, and already did so, in fact.)

So, in this respect, i would hope that this working group does
*not* go IETF due to email issues (!!!), because what these people
there do is the *absolute*opposite* of creating and maintaining
fine-grained, balanced and technically sound technical solutions.

Btw, if they get their way, you will get a single-recipient-SMTP
constraint, causing massive data duplication.
Luckily this WG creates text with content, and that means, for
example, messages of 3KB and less talking about 64-bit/128-bit
hardware ssize_t/size_t / ptrdiff_t/uintptr_t issues.  Wow!


P.S.: my browser (firefox as compiled by Mozilla) always crashes.
      (At least due to apulse incompatibilities, at the moment;
      means i can/could watch music videos, but not open certain
      menu entries under Help->, without crashing.  Rusty.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to