Re: [DNG] New Devuan-based distro

[Steve Litt]

On Wed, 2 Aug 2017 10:36:50 -0300
Emiliano Marini  wrote:

> Not new, but now based on Devuan.
> 
> EterTICs GNU/Linux is a GNU/Linux distribution aimed for community
> radios of Latinamerica. His goal is to be 100% libre and it has all
> the software needed to setup a "libre" radio including Radit,
> Guarangoradio, Rivendell, Audacity, Ardour and Cadence.
> 
> Many Latinamerican radios are using this distribution at this time,
> so it's nice to know Devuan will power many community radios from now
> on.
> 
> Go check it out ;)
> 
> https://gnuetertics.org

I couldn't read the web page ,but if this references software defined
radio, you know, where you use an A/D converter as a tuner and control
it with software, I'm really interested.


SteveT

Steve Litt 
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Excessive bounces

[Narcis Garcia]

1. SPF is a friendlier solution and enough for this.
3. GPG signatures is more standard and friendlier solution for this.

This kind of tricky solutions (as DKIM) only make people to move to
other easier but non-neutral technologies, hosted services such as
WhatsApp or web-based.



El 03/08/17 a les 00:44, Daniel Abrecht ha escrit:
> I'm sorry, I'm using DMARC, and I didn't get the DMARC report about the
> bounced mails, probably because I forgot a DMARC DNS entry for the
> report receiving mail address. I have changed my DMARC policy from
> reject to quarantine for now.
> 
> That said, I won't remove the DMARC record completely, and I plan to
> switch my DMARC policy back to reject after this issue has been
> resolved. A lot of people claim that DMARC won't work with mailing
> lists, but this isn't correct, it's just that most mailing lists aren't
> configured in a way that makes DMARC usable, (and no, changing the from
> address isn't the correct solution.)
> 
> I use DMARC and believe it to be necessary because it allows me to:
>  1) Make sure nobody can use my E-Mail address to impersonate me or send
> spam
>  2) I will be notified if anyone attempts to do so
>  3) The recipient can check if the message content was changed
> 
> That said, the correct way to deal with DKIM, SPF and DMARC protected
> mails is to:
>  1) Provide an SPF record. This mailing list doesn't seam to have one
>  2) Don't change anything from the message below the DKIM headers, add
> the other headers before the DKIM signature instead. This will also
> solve the problem that some mail clients like the android mail client
> don't display text-only mails correctly.
> 
> In think the email body, subject and from header shouldn't be altered
> anyway. Of course, changing the from header and removing the DKIM header
> would avoid the problem as well, but I'm against that solution since it
> obscures who wrote the mail.
> 
> I haven't done much with mailman yet, so I don't know how it needs to be
> configured or if it can even be configured that way. I'll take a look at
> mailman in a few weeks.
> 
> I've attached two versions of an email I've sent to the list earlier.
> The first one contains the message as I received it again from the list.
> The second one is edited in such a way that the added headers and the
> original message body are preserved and the DKIM check succeeds, only
> the added mailing list signature was removed.
> 
> Daniel Abrecht
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Excessive bounces

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> SPF breaks mailing lists and mail forwarders - and this is NOT (IMO)
> fixable without introducing a wide open front gate for spammers to
> ride through and completely bypass SPF.

No. it does not break mailing lists.  It _does_ break other common types
of forwarders unless they adopt SRS-wrapping.

The reason it does not adversely affect mailing lists is that SPF
validates only the envelope header:  The receving MTA verifies that the
delivering MTA's IP address is mentioned in the claimed sending domain's
SPF RR (if there is one in that domain's DNS).

Consider the envelope header of your own Dng posting, as received by
linuxmafia.com's MTA when it received my subscription's copy.  Here's
the way your post arrived:

  From dng-boun...@lists.dyne.org Thu Aug 03 05: 8:39 2017
  Return-path: 
  Envelope-to: r...@linuxmafia.com

So, the envelope sender's domain was dyne.org, not thehobsons.co.uk, and
my receiving MTA will perform a DNS check against the former.

:r! dig -t txt dyne.org +short

"google-site-verification=6FghqJroXIvBY8cutq6ouO0RC-a8qynFu6sJR3S-IbA"
"v=spf1 mx ip4:178.62.188.7/32 ip4:188.226.191.63/32 ip4:213.127.180.241/32 
-all"
"google-site-verification=2XoWrMMTQ7jmgcB_76Y_TQSnWDGhR4e-y_KLqoKOK1Q"


:r! dig lists.dyne.org +short
178.62.188.7

And, lo!  The envelope sender does validate.

You are probably confusing mailing lists, which provide new envelope
headers during forwarding citing the forwarding domain, with other
forwarders like /etc/alias entries and ~/.forward files.  It's the
_latter_ that SPF author Meng Wong invented that goofy Sender Rewriting
System.  Mailing lists, by contrast, don't have the problem he invented
that kludge to fix.


And, again, Simon, my mail domain linuxmafia.com has had an SPF hardfail
directive in its DNS since around 2003, and the specifier is extremely
narrow:

:r! dig -t txt linuxmafia.com +short
"v=spf1 a mx -all"

That says 'If a mail's envelope header claims it's from linuxmafia.com,
but the delivering MTA doesn't match either linuxmafia.com's DNS A
record or its MX record, please consider it definitively a forgery.'
I'm on _many_ mailing lists on many hosts.  If my mailing list mail had
a deliverability problem caused by hardfailing forgeries of my envelope
header, I'd have figured that out, some time over hte past 14 years.  It
does not happen, because mailing lists work better than /etc/alias
entries and ~/.forward files by design.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Excessive bounces

[Arnt Gulbrandsen]

For what it's worth, SPF, DKIM and DMARC were developed by largely 
different sets of people, who disagreed without each other about what 
was acceptable tradeoffs, what was doable and more.


The "they" you 
mention act senselessly because it is not one set of people. Patching 
up email against spam is a hard problem and you cannot expect wide 
agreement about the best tradeoffs.


IMO the right solution to the 
problem at hand is to delete dkim signatures during list processing and 
to tell dmarc supporters to either have their cake or eat it.


Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [test] Excessive bounces

[Daniel Abrecht]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is just a test mail, please ignore. This time without MIME/PGP
signing, because it causes mailman to add a multipart header before
the message, which interferes with the DKIM check.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZg2sXAAoJEHAEo2n3S1aBDcUH/3CwGtjBX/tWq8bO9X6cAgKU
ApKNiNCTUu/CATJ9PqeG3iwgGDDjOZwF9Ral0Eq70YspEosfPnOh9QxMqD/F/Qvu
Pn6F1WPBXZSscjXMEUxPhBr19K3wprwm6dbfj+EUHR8KDAYILgjH4mqDiLf+6PAK
CMVWuqXUYthNEYYn6OPNNcIjoYv+UDpoPgwxEHZ8YfGimw3q0fuQKCcZDMM4hFsI
vHT3PnvsJbe0eB7aTzTmETCfoyvuan+uaEpLijz1ydL2yPN6dKySYNK3EM01u0sS
yFTdinPPzFL+J99oCosArKMLJMk/Ie0eMmiGwz0Rn08N8zB8A4u/94MXh3tRkI0=
=aZyR
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [test] Excessive bounces

[Daniel Abrecht]

This is just a test mail, please ignore. I have changed my OpenDKIM
config again, and added Return-Path, References and In-Reply-To to the
list of headers to be not covered by DKIM.  (also, I switched back to
MIME/PGP signing, I think I'll just have to search a better mail client
for that.)

Daniel Abrecht



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New Devuan-based distro

[John Morris]

On Thu, 2017-08-03 at 03:31 -0400, Steve Litt wrote:
> On Wed, 2 Aug 2017 10:36:50 -0300
> > 
> > EterTICs GNU/Linux is a GNU/Linux distribution aimed for community
> > radios of Latinamerica. His goal is to be 100% libre and it has all
> > the software needed to setup a "libre" radio including Radit,
> > Guarangoradio, Rivendell, Audacity, Ardour and Cadence.
> > 
> I couldn't read the web page ,but if this references software defined
> radio, you know, where you use an A/D converter as a tuner and control
> it with software, I'm really interested.

Nah, they are building radio station automation systems.  Also a very
interesting thing, but farther up the stack from the raw modulation /
demodulation / tuning SDR is about.


signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [test] Excessive bounces

[Rick Moen]

Quoting Daniel Abrecht (d...@danielabrecht.ch):

> This is just a test mail, please ignore. This time without MIME/PGP
> signing, because it causes mailman to add a multipart header before
> the message, which interferes with the DKIM check.

Not a complaint, just an observation.  On every system where I
administer Mailman, I make a point of having a mailing list called
'test' where I and others can, when useful, send test postings
(averting the need to send those to a bunch of uninterested
subscribers).


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Excessive bounces

[Rick Moen]

Daniel, again, thank you for your efforts to collect diagnostic data for
the Devuan Project, and for your care and precision.

I respect the reasons you're making DMARC work for your domain, and
certainly have no argument with you doing so (though I do not come to
the same conclusion for my own domain).  A few comments that come
to mind:


Quoting Daniel Abrecht (d...@danielabrecht.ch)

> The SPF checks from the report have currently the result None, which
> usually indicates that domain does not have an SPF record. I did add
> ?mx:lists.dyne.org to my SPF record, which should have resulted in an
> SPF result of Neutral, so either the mailing list needs an SPF record,
> or google & co. are wrongly reporting a None result instead of a
> Neutral one.

Let's be careful about what we're speaking about, here.  By definition,
a posting that transits a mailing list goes through two phases, where
to the best of my understanding a different SPF RR is relevant for each.

In the first phase, mail arrives at (say) the lists.dyne.org MTA
purporting to be from your domain.  If the receiving MTA is checking SPF
on arriving mail, then it seeks to validate the envelope header of
arrived mail against the published SPF RR of the claimed sender domain
as reflected in the envelope.  A forged mail at this point would have an
envelope claiming it's from danielabrecht.ch, but the IP would fail
vetting against your A and MX records (declared as authorised senders in
your domain's SPF RR).  If it's genuine, otherwise.

The accepted posting gets handed by the receiving MTA to the MLM
software.  The MLM software now remails, or to put it another way,
creates fresh mails (thus, second phase), with an entirely different
SMTP envelope reflecting the MLM's host identity.  The internal 'From: '
header is (ideally) left intact, the internal 'To: ' header is
customised for each subscriber, and some number of other additions and
changes get made by the MLM software prior to handing it off to the
outbound MTA.

If subscribers' receiving MTAs now attempt, during this second phase, to
validate the SMTP envelope, they will do so based on the MLM host's
domain, not the original sender's.


> When a mail is sent, there are the envelope-to and the envelope-from
> (which aren't mail headers), but also To and From headers.[...]

Yes, I'm extremely well aware of this.  The latter 'From header' is
traditionally called the internal 'From:' header to distinguish it from
the envelope 'From ' header.

I was on NANAE during the incident in which envelope forgery was
invented and demonstrated in the famous revenge-spam attack against Joe
Doll of Joe's Cyberpost.

> Normally when an SPF check is made, the envelope from address is used.
> If the mail server doesn't have an SPF header, the SPF result is None
> and the receiving mail server should accept the mail.

To my knowledge, there is no such thing as an 'SPF header' (except see
below).  No extra headers get used to implement SPF.  It's just a DNS RR
that declares what authorised sending MTA hosts exist, and gets used by
supporting (receiving) MTAs to vet the envelope sender.  (There's also
an optional 'Authentication-Results' header that's similar, except for
recording border MTAs' results.)

My understanding is that some MTAs add a Received-SPF header to
all emails arriving via SMTP that test to any result other than 'fail'.
This is added _after_ SPF evaluation to record the results of that
check.  It's advisory, and merely a place to record the result.


> There is no point in getting notified if nothing happens or everything
> works as expected, but if something didn't work or someone tried to
> send a mail in my name and failed, I certainly want to know about
> that.

Certainly your prerogative, but I personally don't care to get notified
when someone tries to forge my domain and fails, because that amounts to
getting spam about spam.

There's a reason why I've finely tuned logcheck to stop notifying me of
pointless and futile attempts to use generic username/password pairs on
my sshd, and a thousand other bits of basically meaningless noise that's
just part of the routine of having a 24x7 Internet server.


> >> 3) The recipient can check if the message content was changed
> > 
> > gpg signing alone can do that.
> 
> gpg and DKIM have a bit different scope.

Yes, but both can authenticate and attest to the integrity of whatever
dataset was signed.  And that thus matches 'can check if the message
content was changed'.  Just crypto-sign the message contents.  Anything
extraneous inserted into the signed bloc will cause validation failure.
Anything outside it will be obviously _not_ attested to, and recipients
should accordingly understand that.

You might have more reasonably made the objection 'Ordinary folks won't
check PGP attestation.'  Maybe not.  Personally, I regard this as Not My
Problem.  If I say something where text integrity really matters, like
the body of a CVE, I will PGP-sign it. 

[DNG] VimL expert needed

[Steve Litt]

Hi all,

If any of you is proficient in Vim's internal language (I think it's
called VimL), and you want to work on a Free Software project, I need
your help.

I'm forking VimOutliner (VO), because the project's current crew changed
VO's main keyboard prefix from easy ,, to wrist-twisting and different
location on different keyboards \. They did this without any discussion
on the mailing list.

My main job in the fork is to change all these keyboard mappings so
that they're not affected by the Vim  and 
constants: The main excuse for this change. After my changes, distro
package managers can change  and  to anything they
want, but VimOutliner will still use double comma, which was studied
extensively and found to be fastest and easiest.

So please let me know if you know VimL and are interested in working on
this.

Thanks,

SteveT

Steve Litt 
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Excessive bounces

[Simon Hobson]

Narcis Garcia  wrote:

> 1. SPF is a friendlier solution and enough for this.

SPF breaks mailing lists and mail forwarders - and this is NOT (IMO) fixable 
without introducing a wide open front gate for spammers to ride through and 
completely bypass SPF.

So consider that *I* publish an SPF record for my domain(s). If I post on a 
mailing list then I need to include the IP address of the list server in my SPF 
record - if I don't, then any MX that checks SPF will reject the message. I 
need to keep the SPF record up to date whenever ANY of the mailers used by ANY 
of the lists I'm subscribed to changes.

Now, with my own mail server, it might just be practical to do that. If you use 
a hosted service such as hotmail, Gmail, ... then it isn't going to happen.

To work around that, the mail list must either be configured to munge the 
sender address - ugly and breaks traditional usage - or they must use SRS.

SRS is the wide open gate I referred to. It basically (AIUI) tells a downstream 
MX "I am relaying this on behalf of X, but for SPF purposes treat it as having 
come from me".
So all a spammer has to do is send out his spam with the right "looks like SRS" 
from address and you've bypassed SPF - AFAICS for ANY sender domain !


AFAICS, with SPF/DKIM/DMARC/whatever they come up with tomorrow they seem to be 
laying gaffer tape on gaffer tape trying to fix something that's fundamentally 
broken and which they keep breaking even worse with each layer of gaffer tape. 
And what's more, it seems that most outfits using all this gaffer tape are 
taping over problems in their own systems - if they didn't accept message they 
know they won't be delivering, then half the problem would disappear !

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng