Re: [Asus x205ta] Sound not working on Intel HDMI/DP LPE Audio

[Leandro Noferini]

Ric Moore  writes:

>> pulseaudio to use only the first audio card?
>
> Install pavucontrol. Under the configuration tab you can either
> configure or turn off the devices it finds. Turn off the one you don't
> want. You should use alsamixer first, as pulse sits on top of
> alsa. Use the F6 key to select a source other than the system
> source. It ought to work just fine. (google for alsamixer for more
> options) If you have more questions just ask. Remember alsamixer
> first, pavucontrol second. Ric

I cannot follow this solution because pulseaudio dies at the beginning
of the user session so I cannot control it. I think I need a way to
blacklist the device it gives me problem.

-- 
Ciao
leandro
http://6xukrlqedfabdjrb.onion/blog/
Alla bellezza preferisco la verità.
E il dubbio è l'unità di misura.


signature.asc
Description: PGP signature

Re: bad upgrade libgstgl-1.0.so.0

[Pétùr]

Le 21/03/2018 à 19:38, Kushal Kumaran a écrit :
> The package version mentioned above is not from the official debian
> repositories.  It appears to be from deb-multimedia.org.
> 
> The Debian Multimedia FAQ at
> https://wiki.debian.org/DebianMultimedia/FAQ might help.  See sections
> 2.5 and 3.1.

Thank you Kushal,

The problem was indeed created by a conflit with the deb-multimedia
repository. I fixed it by stopping using this repository and downgrading
all the packages concerned.

It seems there is less reason to use deb-multimedia these days. The
official (unstable) repositories contain almost the same version of
packages. The only program I didn't find is avidemux.

Pétùr

Re: Federated, decentralised communication on the internet

[deloptes]

Miles Fidelman wrote:

> the problem with DMARC is simple - it breaks any kind of retransmission
> - in particular mailing lists

that's why I don't get the mails delivered to the mailbox or get numerous
non deliverable mails from the mail server.

nevertheless you will not be able to resent mails soon and perhaps the news
group community should react respectively in time and not just state "the
problem with DMARC".
You know what happens in nature with animals that do not evolve. I am sure
there is a way to handle this with DMARC as well.

regards

Re: [Asus x205ta] Sound not working on Intel HDMI/DP LPE Audio

[deloptes]

Leandro Noferini wrote:

> I cannot follow this solution because pulseaudio dies at the beginning
> of the user session so I cannot control it. I think I need a way to
> blacklist the device it gives me problem.

Have you tried deleting your ~/.pulse directory?

Re: Federated, decentralised communication on the internet (was: domain names, was: hostname)

[deloptes]

David Wright wrote:

> Sure, so in my case, I'd be forced to find out what my router's
> hostname is so that I can quote a hostname that will resolve to the
> address that I woud be posting on. Currently this appears to be
> ip70-179-161-106.fv.ks.cox.net

these are not valid SMTP domain names. It might be valid FQDN, but the
server on the other end is most likely to reject it.

> but it changes at random times governed by I know not what.
> But wait: to post from any of my machines, they all have to have
> ip70-179-161-106.fv.ks.cox.net in /etc/hosts so that exim uses it
> as the HELO string. This to an ISP that knows which wire I'm
> connected to at their end.

Best is to use dynamic DNS or DDNS service, but I am not sure if the free
versions support MX records (most probably not)

regards

Re: Federated, decentralised communication on the internet

[Darac Marjal]

On Wed, Mar 21, 2018 at 10:47:24PM +, Brian wrote:

On Wed 21 Mar 2018 at 16:41:25 -0500, Richard Owlett wrote:


On 03/21/2018 03:47 PM, Brian wrote:
> On Wed 21 Mar 2018 at 12:05:53 -0400, Miles Fidelman wrote:
>
> > On 3/21/18 11:48 AM, Charlie Gibbs wrote:
> >
> > > On 21/03/18 01:00 AM, to...@tuxteam.de wrote:
> > >
> > >
> > > My problem with "social networks" is that they're monopolies. Imagine
> > > popping down to the local pub for a pint and a bit of conversation, only
> > > to find that it's part of a huge chain run by a transnational
> > > conglomerate.  I much prefer the Usenet model, although web sites that
> > > let you leave messages come pretty close. What I don't like are those
> > > web sites that make you log in through Facebook in order to post.  Since
> > > I don't have a Facebook account and never will, such sites will have to
> > > do without my pearls of wisdom.  :-)
> >
> > Maybe we should move back to USENET.  It worked pretty well, and it's still
>
> Maybe we should just continue to talk about email in this thread. Keeps
> it on-topic etc. Feel free to contribute to it.
>

POT vs KETTLE ?


Eh? Does anyone understand this remark?


I do. It is a reference to the Spanish/English idiom "The pot calling 
the kettle black" 
[https://en.wikipedia.org/wiki/The_pot_calling_the_kettle_black]. The 
direct implication of that idiom is that the pot is ALSO black, but is 
accusing the kettle of being so. The implication of Richard referencing 
that idiom is that you are guilty of the same thing you are accusing 
Miles of, viz, getting off topic.





For the record, very many OT sub-threads to threads I began have been
*VALUABLE*.


They are up there in the Hall of Fame. Never to be forgot.


One liners which are nominally ON-Topic, much less so ;/
YMMV


So be it: back to discussing email, then.

--
Brian.

--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Federated, decentralised communication on the internet (was: domain names, was: hostname)

[Joe]

On Thu, 22 Mar 2018 08:59:11 +0100
deloptes  wrote:

> David Wright wrote:
> 
> > Sure, so in my case, I'd be forced to find out what my router's
> > hostname is so that I can quote a hostname that will resolve to the
> > address that I woud be posting on. Currently this appears to be
> > ip70-179-161-106.fv.ks.cox.net  
> 
> these are not valid SMTP domain names. It might be valid FQDN, but the
> server on the other end is most likely to reject it.

It doesn't need to be a mail domain, it's a hostname. What is important
is that it:

a) exists, and
b) that a DNS lookup returns the same IP address, 

i.e. there is an A record which points to an IP address and a PTR
record for the IP address that points back to the same A record. Note
that these are often maintained by different companies: the owner of
the IP address, the ISP, maintains the PTR record (and may allow the
user to do so) and the domain name host maintains the A record. It
isn't normally necessary for this hostname to have any connection with
any email address or HELO.

Unfortunately, many domestic ISPs now maintain this relationship even
on their dynamic addresses, so it is becoming less useful in
identifying spammers.

> 
> > but it changes at random times governed by I know not what.
> > But wait: to post from any of my machines, they all have to have
> > ip70-179-161-106.fv.ks.cox.net in /etc/hosts so that exim uses it
> > as the HELO string. This to an ISP that knows which wire I'm
> > connected to at their end.  
> 
> Best is to use dynamic DNS or DDNS service, but I am not sure if the
> free versions support MX records (most probably not)

About ten years ago, when I was active on the MS Small Business Server
newsgroup/forum, it was often claimed that it was practical to run a
mail server on DDNS. 

-- 
Joe

Network Problems

[David]

Dear Group,

I'm having some network issues where I have several Arduino's on my
network and I may have given two of them the same MAC address.

Does Debian keep a table of MAC addresses? If so where can I locate it?

It could of course be my browser that is keeping this table, I'm using
PaleMoon.

David.

Re: Network Problems

[Thomas Pircher]

On Thu, 22 Mar 2018, David wrote:
> Does Debian keep a table of MAC addresses? If so where can I locate it?

The kernel does. You can get the ARP table e.g. with

ip neigh list

This table is relatively short-lived and if you haven't talked to that
device recently it might not show up in the table.

Another place you could look for MAC addresses is your router. Most
routers keep a table of MAC addresses which is a bit longer-lived than
the ARP table on a host, because they need to hand out IP addresses over
DHCP and need to remember the MAC-IP combination for some time.

Thomas

Re: how to view config file changes without running an upgrade?

[Curt]

On 2018-03-21, deloptes  wrote:
> Richard Hector wrote:
>
>> Where 'checked' was presumably the debilitate one :-)
>
> true, sorry - even double checking fails sometime :D
>
>

When Norman Mailer's Harlot's Ghost was published it contained a
grammatical error in the first sentence (and one can only imagine how
many human minds proof-read the thing before it went to press): 

Here it is:

 "On a late-winter evening in 1983, while driving through the fog along
 the Maine coast, recollections of old campfires began to drift into the
 March mist, and I thought of the Abnaki Indians of the Algonquin tribe
 who dwelt near Bangor a thousand years ago."

The error was subsequently corrected.

So take heart.



-- 
Bah, the latest news, the latest news is not the last.
Samuel Beckett

Re: how to view config file changes without running an upgrade?

[Harald Dunkel]

On 03/21/18 17:18, Greg Wooledge wrote:

On Wed, Mar 21, 2018 at 04:46:16PM +0100, Harald Dunkel wrote:

Its pretty painful to resolve config file conflicts in (lets say)
dovecot at upgrade time, putting EMail access for +200 users at risk.
I have to check in advance. Resolving config file conflicts during
the upgrade is too late.


Then you need a second system, to test the upgrades on.  If you don't
keep one around at all times, then you could create one on the fly
with debootstrap, rsync your current configs into it, and test the
upgrade in there.



We have tons of stage systems. EMail stage systems are especially painful.
They are constantly out of sync to the production host, making it even
more necessary to review the diffs between the config files in the most
recent packages and the installed files *before* running an upgrade.

Dovecot was just an example, anyway.

Regards
Harri

Re: Network Problems

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Mar 22, 2018 at 09:46:02AM +, Thomas Pircher wrote:
> On Thu, 22 Mar 2018, David wrote:
> > Does Debian keep a table of MAC addresses? If so where can I locate it?
>
> The kernel does. You can get the ARP table e.g. with
>
> ip neigh list

There's also the arp (8) command: you can query and manipulate
the ARP table (arp stands for "address resolution protocol", which
is tasked with keeping this MAC -- IP mapping up to date).

For example, just typing "sudo arp" will show you a list of known
IP Address to MAC address mappings. With "arp -s  " you
can set one such mappings. And so on.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqzglkACgkQBcgs9XrR2kai7wCdH863goBZDFtVIFpJeqVoHxEu
3/4An1ELnMKk9e8y8FBo3Xr9ZZ6022A8
=FwQH
-END PGP SIGNATURE-

Re: Network Problems

[David]

On Thu, 2018-03-22 at 11:15 +0100, to...@tuxteam.de wrote:
> On Thu, Mar 22, 2018 at 09:46:02AM +, Thomas Pircher wrote:
> > On Thu, 22 Mar 2018, David wrote:
> > > Does Debian keep a table of MAC addresses? If so where can I locate it?
> >
> > The kernel does. You can get the ARP table e.g. with
> >
> > ip neigh list
> 
> There's also the arp (8) command: you can query and manipulate
> the ARP table (arp stands for "address resolution protocol", which
> is tasked with keeping this MAC -- IP mapping up to date).
> 
> For example, just typing "sudo arp" will show you a list of known
> IP Address to MAC address mappings. With "arp -s  " you
> can set one such mappings. And so on.
> 
> Cheers
> -- tomás
Thank you to Thomas and Tomas for replying.

I think as Thomas stated it's a router problem, I've been looking at
what the various routers are storing and not found a problem to date.

I suspect that allocating random MAC addresses is the problem and I need
to find out what I can allocate without causing problems. There must be
some rules somewhere, I suspect the Arduino uses a block of addresses
and I've duplicated something.

David.

Re: Federated, decentralised communication on the internet

[Greg Wooledge]

On Thu, Mar 22, 2018 at 12:04:07AM -, Dan Purgert wrote:
> Richard Hector wrote:
> > I often see this alluded to, but struggle to find evidence - why
> > shouldn't there be a postmaster@com, for example? Or perhaps cic@mil?
> 
> It is my understanding that the TLDs are not themselves valid domains.
> That is, a valid domain is by definition "domain.tld".
> 
> I could be entirely wrong though.

>From :

  A fully qualified domain name (FQDN), sometimes also referred to as
  an absolute domain name,[1] is a domain name that specifies its exact
  location in the tree hierarchy of the Domain Name System (DNS). It
  specifies all domain levels, including at least a second-level domain
  and a top-level domain.[2]

Footnote [2]:

  April N. Marine; Joyce K. Reynolds; Gary Scott Malkin (March 1994).
  "Questions About the Domain Name System". Answers to Commonly asked
  "New Internet User" Questions. IETF. sec. 5. doi:10.17487/RFC1594. RFC
  1594. Retrieved 29 April 2013. "If you think of the DNS as a
  tree-structure with each node having its own label, a fully qualified
  domain name for a specific node would be its label followed by the
  labels of all the other nodes between it and the root of the tree."

RFC 1594 :

  A Fully Qualified Domain Name (FQDN) is a domain name that includes all
  higher level domains relevant to the entity named.  If you think of the
  DNS as a tree-structure with each node having its own label, a Fully
  Qualified Domain Name for a specific node would be its label followed by
  the labels of all the other nodes between it and the root of the tree.
  For example, for a host, a FQDN would include the string that identifies
  the particular host, plus all domains of which the host is a part up
  to and including the top-level domain (the root domain is always null).


Now, that's from 1994, and it's an "Informational" RFC ("does not specify
an Internet standard of any kind"), but that's probably as authoritative
as you'll get.

Re: Federated, decentralised communication on the internet (was: domain names, was: hostname)

[Greg Wooledge]

On Wed, Mar 21, 2018 at 06:59:04PM -0500, David Wright wrote:
> Sure, so in my case, I'd be forced to find out what my router's
> hostname is so that I can quote a hostname that will resolve to the
> address that I woud be posting on. Currently this appears to be
> ip70-179-161-106.fv.ks.cox.net
> but it changes at random times governed by I know not what.

First, you're not "forced" to do anything.  You can simply acknowledge
that some SMTP servers will accept your messages, and others will
reject them.  You can never achieve 100% acceptance anyway, since
there will always be SOMEONE out there who only accepts messages
that are cryptographically signed by her grandmother and wrapped in
tin foil and delivered by RFC 1149.

Second, the HELO string you use doesn't necessarily have to be YOUR
hostname.  It just has to be SOME hostname.

That said, using your actual hostname (more precisely, any hostname
which resolves to your public IP address) increases the chances that
your message will be accepted.

Having your IP address get mapped to a hostname that maps back to your
IP address will also increase your odds of acceptance, but for people
with dynamic IP addresses, that is typically outside of your control.

Having a static IP address, with control over the DNS mappings in both
directions, would definitely help you.

> And what's achieved by this when the next step is AUTH?

There is no AUTH step when you're sending outgoing mail to the receiver's
SMTP server.  None.

SMTP looks like this:

(1) Sender:   HELO sender.name
Receiver: 250 receiver.name
(2) Sender:   MAIL FROM:
Receiver: 250 ok
(3) Sender:   RCPT TO:
Receiver: 250 ok
(4) Sender:   DATA
Receiver: 354 ok
(5) Sender:   message headers and body followed by \n.\n
Receiver: 250 ok magic numbers
(6) Sender:   QUIT
Receiver: 221 ok (hangup)

That's it.  That's an entire session.

Step (1) is just the servers telling each other their own names.  It has
nothing to do with the message.  It's simply one of the points at which
some receivers choose to take antispam measures.  A conforming SMTP
server may choose simply to ignore whatever the sender says.

A non-naive SMTP receiver will log the sender's ACTUAL IP address as
well as whatever it called itself in the HELO.

Step (2) is the envelope sender address.  This is what the receiver is
supposed to use to bounce an error message back to the sender if the
mail can't be delivered.  This is where things get really interesting.

A conforming SMTP receiver that plays by the rules and accepts everything
("be liberal in what you accept") and generates bounces for the failing
addresses is too naive for the current Internet.  SMTP was designed in
a simpler time.  Playing by the old rules just makes you a joe-job spam
relay.  You can't do that in the modern era.

Step (3) is the list of envelope recipient addresses.  This is where
the mail ACTUALLY goes.  It doesn't matter what's in the headers.

An SMTP receiver SHOULD validate the recipient address right here,
right now.  It SHOULDN'T just accept everything and then figure out
whether it's deliverable later -- that enables joe-job spam.

Step (4) is just "that's all the recipients".

Step (5) is the actual message, including the headers.  Some SMTP
receivers may perform content analysis during this stage, and may reject
the message as spam based on its content.  Others do not.

Step (6) is optional.  The sender may try to send more messages since it
already has the connection open, assuming it has other messages intended
for this SMTP receiver.  Or, the sender may simply drop the connection
itself, instead of sending QUIT and waiting for the receiver to drop
the connection.

Bundling of multiple messages for a single SMTP session is fairly
uncommon, since it's a whole lot of work and complexity for no real
gain, in a time when bandwidth is plentiful.  Most senders just open
one connection for each message, typically in parallel.

There is NO authentication step.  Remember, the sender may not be the
origin machine of the message.  It may simply be one of a sequence of
mail relays between the origin and the final destination.

Re: Federated, decentralised communication on the internet

[Miles Fidelman]

On 3/22/18 3:56 AM, deloptes wrote:


Miles Fidelman wrote:


the problem with DMARC is simple - it breaks any kind of retransmission
- in particular mailing lists

that's why I don't get the mails delivered to the mailbox or get numerous
non deliverable mails from the mail server.

nevertheless you will not be able to resent mails soon and perhaps the news
group community should react respectively in time and not just state "the
problem with DMARC".
You know what happens in nature with animals that do not evolve. I am sure
there is a way to handle this with DMARC as well.

Well, the list management community HAS been trying to engage with DMARC 
- the thing is the DMARC folks are not really all that responsive - "not 
their problem" and it's a standard that's being imposed by fiat, not in 
the Internet way.


There are work-arounds, sort of - the basic one being to set a list 
manager to have all emails show as coming from the list, not the 
original author.  Makes "reply-to-author" a pain.


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Network Problems

[Darac Marjal]

On Thu, Mar 22, 2018 at 10:50:59AM +, David wrote:

On Thu, 2018-03-22 at 11:15 +0100, to...@tuxteam.de wrote:

On Thu, Mar 22, 2018 at 09:46:02AM +, Thomas Pircher wrote:
> On Thu, 22 Mar 2018, David wrote:
> > Does Debian keep a table of MAC addresses? If so where can I locate it?
>
> The kernel does. You can get the ARP table e.g. with
>
> ip neigh list

There's also the arp (8) command: you can query and manipulate
the ARP table (arp stands for "address resolution protocol", which
is tasked with keeping this MAC -- IP mapping up to date).

For example, just typing "sudo arp" will show you a list of known
IP Address to MAC address mappings. With "arp -s  " you
can set one such mappings. And so on.

Cheers
-- tomás

Thank you to Thomas and Tomas for replying.

I think as Thomas stated it's a router problem, I've been looking at
what the various routers are storing and not found a problem to date.

I suspect that allocating random MAC addresses is the problem and I need
to find out what I can allocate without causing problems. There must be
some rules somewhere, I suspect the Arduino uses a block of addresses
and I've duplicated something.


MAC addresses follow a set format. They are 6 bytes long: the first 3 
bytes is the Organisationally Unique Identifier (OUI), the second 3 
bytes are the NIC specific identifier.


Typically, MAC addresses are set by the manufacturer of the Ethernet 
device. Each manufacturer is allocated one or more OUIs. They are free 
to allocate the last three bytes however they like, so long as they 
remain unique within the organisation. So Intel can produce a device 
with 12:34:56 as the last three bytes, and so can Netgear, but once 
combined with the OUI, the whole *should* be globally unique.


So, what about locally-created Ethernet devices (e.g. Virtual Machine 
interfaces, or devices without a burned-in MAC address)? For these, you 
don't need to apply for your own OUI. The MAC address standard states 
that if the second-least-significant bit of the first octet is 1, then 
the whole MAC address is "locally administered". Thus, if your MAC 
address starts with "x2", "x6", "xA" or "xE" (where x is any digit), 
then it is locally-adminsitered and, in theory, it is up to you to 
ensure uniqueness (at least, unique within the boundary of your Ethernet 
domain).




David.




--
For more information, please reread.


signature.asc
Description: PGP signature

Re: domain names, was: hostname

[David Wright]

On Thu 22 Mar 2018 at 08:58:43 (-0400), Greg Wooledge wrote:
> On Wed, Mar 21, 2018 at 06:59:04PM -0500, David Wright wrote:
> > Sure, so in my case, I'd be forced to find out what my router's
> > hostname is so that I can quote a hostname that will resolve to the
> > address that I woud be posting on. Currently this appears to be
> > ip70-179-161-106.fv.ks.cox.net
> > but it changes at random times governed by I know not what.
> 
> First, you're not "forced" to do anything.

No, hence my writing "I'd'. The "would" is predicated on what you
wrote, "a given receiver may choose to perform BOTH tests", … … …

> You can simply acknowledge
> that some SMTP servers will accept your messages, and others will
> reject them.  You can never achieve 100% acceptance anyway, since
> there will always be SOMEONE out there who only accepts messages
> that are cryptographically signed by her grandmother and wrapped in
> tin foil and delivered by RFC 1149.
> 
> Second, the HELO string you use doesn't necessarily have to be YOUR
> hostname.  It just has to be SOME hostname.
> 
> That said, using your actual hostname (more precisely, any hostname
> which resolves to your public IP address) increases the chances that
> your message will be accepted.

… … … and on the second test consisting of the test in this last paragraph.

IOW: Were this the case, it would be necessary to do as outlined in
my paragraph above.

> Having your IP address get mapped to a hostname that maps back to your
> IP address will also increase your odds of acceptance, but for people
> with dynamic IP addresses, that is typically outside of your control.
> 
> Having a static IP address, with control over the DNS mappings in both
> directions, would definitely help you.

I don't need help because the smarthost I've chosen to use does not
insist on this.

> > And what's achieved by this when the next step is AUTH?
> 
> There is no AUTH step when you're sending outgoing mail to the receiver's
> SMTP server.  None.

So that would be a pretty good reason for an ISP to deny access to
that service if you have no other way of showing who you are.

With certain differences, I can do exactly what you have done below in
your example: I wrap it up in SSL and talk to a different port number,
and it works fine with
. junk EHLO string
. no AUTH authentication
. junk MAIL FROM: string
. No From: To: etc, but I add a Subject: to make the incoming result
  easier to find, and a body that describes the nature of the test.
IOW the only sensible information is RCPT TO:.

Of course, the results are as expected, being either
250 2.0.0 Ok: queued as 420E35AE524
for an address that it recognises on home turf, or
454 4.7.1 : Relay access denied
for one that it doesn't.

When I authenticate, I can send the mail anywhere, but it's tedious to
demonstrate here as I have to dig out my password/encode it in base64
and all that stuff. I've done it to help others here in the past.

> SMTP looks like this:
> 
> (1) Sender:   HELO sender.name
> Receiver: 250 receiver.name
> (2) Sender:   MAIL FROM:
> Receiver: 250 ok
> (3) Sender:   RCPT TO:
> Receiver: 250 ok
> (4) Sender:   DATA
> Receiver: 354 ok
> (5) Sender:   message headers and body followed by \n.\n
> Receiver: 250 ok magic numbers
> (6) Sender:   QUIT
> Receiver: 221 ok (hangup)
> 
> That's it.  That's an entire session.
> 
> Step (1) is just the servers telling each other their own names.  It has
> nothing to do with the message.  It's simply one of the points at which
> some receivers choose to take antispam measures.  A conforming SMTP
> server may choose simply to ignore whatever the sender says.
> 
> A non-naive SMTP receiver will log the sender's ACTUAL IP address as
> well as whatever it called itself in the HELO.
> 
> Step (2) is the envelope sender address.  This is what the receiver is
> supposed to use to bounce an error message back to the sender if the
> mail can't be delivered.  This is where things get really interesting.
> 
> A conforming SMTP receiver that plays by the rules and accepts everything
> ("be liberal in what you accept") and generates bounces for the failing
> addresses is too naive for the current Internet.  SMTP was designed in
> a simpler time.  Playing by the old rules just makes you a joe-job spam
> relay.  You can't do that in the modern era.
> 
> Step (3) is the list of envelope recipient addresses.  This is where
> the mail ACTUALLY goes.  It doesn't matter what's in the headers.
> 
> An SMTP receiver SHOULD validate the recipient address right here,
> right now.  It SHOULDN'T just accept everything and then figure out
> whether it's deliverable later -- that enables joe-job spam.

How is it meant to do that. If it's relaying, the system it's
eventually going to send the message to might not even be
running just now. Email is store and forward, isn't it?

> Step (4) is just "that's all the recipients".
> 
> Step (5) is the actual message, including the headers.  Some SMT

Re: domain names, was: hostname

[Greg Wooledge]

On Thu, Mar 22, 2018 at 12:44:53PM -0500, David Wright wrote:
> I don't need help because the smarthost I've chosen to use does not
> insist on this.

Then you're basically an end user, not a mail admin.

> When I authenticate, I can send the mail anywhere, but it's tedious to
> demonstrate here as I have to dig out my password/encode it in base64
> and all that stuff. I've done it to help others here in the past.

You're authenticating because you're an end user who is asking permission
to use someone else's mail relay.  That relay has to decide who is allowed
to use it, and who is not.  The way they've chosen to do that is by using
password-based authentication.

When your smarthost sends your messages to gmail.com's MX, or to
hotmail.com's MX, or to lists.debian.org's MX, there is no
authentication step.

Likewise, if you were to bypass the smarthost and send your own
messages directly to lists.debian.org's MX (et al.) there would be no
authentication step.

Re: Network Problems

[Tom Furie]

On Thu, Mar 22, 2018 at 02:45:07PM +, Darac Marjal wrote:

> So, what about locally-created Ethernet devices (e.g. Virtual Machine
> interfaces, or devices without a burned-in MAC address)? For these,
> you don't need to apply for your own OUI. The MAC address standard
> states that if the second-least-significant bit of the first octet is
> 1, then the whole MAC address is "locally administered". Thus, if your
> MAC address starts with "x2", "x6", "xA" or "xE" (where x is any
> digit), then it is locally-adminsitered and, in theory, it is up to
> you to ensure uniqueness (at least, unique within the boundary of your
> Ethernet domain).

Also x3, x7, xB and xF - but those should only be used for multicast
addressing.

Cheers,
Tom

-- 
Who messed with my anti-paranoia shot?


signature.asc
Description: Digital signature

Re: domain names, was: hostname

[Brian]

On Thu 22 Mar 2018 at 12:44:53 -0500, David Wright wrote:

[...]

> Here are my points, as it's a month since I made them. I didn't
> quite answer the question as posed.
> 
> --✄--
> 
> > that as well as being asked to supply a hostname I've also been asked
> > to supply a domain value.
> >
> > What, on a home LAN, is that used for?
> 
> Nothing, with the possible exceptions of:
> 
> . avoiding this message at boot up:
>   Mon Feb 19 04:58:38 2018: [] Starting MTA:hostname --fqdn did not 
> return a fully qualified name,
>   Mon Feb 19 04:58:38 2018: dc_minimaldns will not work. Please fix your 
> /etc/hosts setup.
> 
> . satisfying a broken smarthost¹,
> 
> . causing some discussion here.
> 
> --✄--
> 
> My last point may become less true over time because, as I already
> just posted, there is now an authoritative answer: If you don't
> know what to put, put home, corp, or mail, as you wish. They are
> guaranteed never to become TLDs in the future.

The d-i prompt says:

 > The domain name is the part of your Internet address to the right of your
 > host name.  It is often something that ends in .com, .net, .edu, or .org.
 > If you are setting up a home network, you can make something up, but make
 > sure you use the same domain name on all your computers.

There you are: a home user can just invent something. mybrilliantdomain.com
would do. Why agonise over it.

Whatever is chosen goes into /etc/hosts.

A long time ago, the advice was:

 > Please enter your domain name or leave this field empty if you don't have
 > a domain.
 
> Currently I have an empty string. When I next reorganise my network
> here to include bridging, I might consider using .home (it's the
> most appropriate). It affords me no particular advantage as far as
> I can see, but I remain open to persuasion that it has some use.
> What exactly, though? (Still a genuine question, but keep off email
> or we're in danger of getting in a loop.)

An empty string is fine. Just do it; you will be happy with it.

> I'm not convinced that I, and many in my situation, would be better
> off running a mail server rather than having an organisation run a
> smarthost to do it on my behalf. (They also take care of incoming mail
> by running an IMAP server.)

Nobody has really tried to convince you that running a mail server is
better for *you*.

(You actually do run a mail server but use it for relaying, not sending
directly. Greg Wooledge's posts are very informative. Please try to see
the distinctions).

> I think the political discussion arises here because people don't
> recognise that just contributing to this list makes one unusual in
> itself (and I include myself in that). There may be divers diverse
> reasons to run a mail server, but count me out along with many others.

Ben Finney's post really got to you, didn't it?

  https://lists.debian.org/debian-user/2018/03/msg00738.html

-- 
Brian.

Re: Federated, decentralised communication on the internet (was: domain names, was: hostname)

[deloptes]

Forest wrote:

> Does this work better? Evolution rather than web-based email.

definitely

Re: Federated, decentralised communication on the internet

[Richard Hector]

On 23/03/18 01:17, Greg Wooledge wrote:
> On Thu, Mar 22, 2018 at 12:04:07AM -, Dan Purgert wrote:
>> Richard Hector wrote:
>>> I often see this alluded to, but struggle to find evidence - why
>>> shouldn't there be a postmaster@com, for example? Or perhaps cic@mil?
>>
>> It is my understanding that the TLDs are not themselves valid domains.
>> That is, a valid domain is by definition "domain.tld".
>>
>> I could be entirely wrong though.
> 
>>From :
> 
>   A fully qualified domain name (FQDN), sometimes also referred to as
>   an absolute domain name,[1] is a domain name that specifies its exact
>   location in the tree hierarchy of the Domain Name System (DNS). It
>   specifies all domain levels, including at least a second-level domain
>   and a top-level domain.[2]
> 
> Footnote [2]:
> 
>   April N. Marine; Joyce K. Reynolds; Gary Scott Malkin (March 1994).
>   "Questions About the Domain Name System". Answers to Commonly asked
>   "New Internet User" Questions. IETF. sec. 5. doi:10.17487/RFC1594. RFC
>   1594. Retrieved 29 April 2013. "If you think of the DNS as a
>   tree-structure with each node having its own label, a fully qualified
>   domain name for a specific node would be its label followed by the
>   labels of all the other nodes between it and the root of the tree."
> 
> RFC 1594 :
> 
>   A Fully Qualified Domain Name (FQDN) is a domain name that includes all
>   higher level domains relevant to the entity named.  If you think of the
>   DNS as a tree-structure with each node having its own label, a Fully
>   Qualified Domain Name for a specific node would be its label followed by
>   the labels of all the other nodes between it and the root of the tree.
>   For example, for a host, a FQDN would include the string that identifies
>   the particular host, plus all domains of which the host is a part up
>   to and including the top-level domain (the root domain is always null).
> 
> 
> Now, that's from 1994, and it's an "Informational" RFC ("does not specify
> an Internet standard of any kind"), but that's probably as authoritative
> as you'll get.
> 

Thanks - Having read that paragraph of the RFC, it doesn't seem to
require any particular number of levels, only that all that exist are
present.

Richard




signature.asc
Description: OpenPGP digital signature

Re: domain names, was: hostname

[Dan Purgert]

David Wright wrote:
> On Thu 22 Mar 2018 at 08:58:43 (-0400), Greg Wooledge wrote:
>> [...]
>> An SMTP receiver SHOULD validate the recipient address right here,
>> right now.  It SHOULDN'T just accept everything and then figure out
>> whether it's deliverable later -- that enables joe-job spam.
>
> How is it meant to do that. If it's relaying, the system it's
> eventually going to send the message to might not even be
> running just now. Email is store and forward, isn't it?

If it's *relaying*, it is not *receiving*; there's a subtle but key
difference there.  At most, a relay will likely validate 

 
 - source (host or user) is allowed to relay via me.
 - destination is a FQDN

The closest that a relay will "store-and-forward" is in essence similar
to if your roommate (significant other, etc.) is going out ... you say
"hey, since you're gonna go past the mailbox, mind dropping these in
there for me?".  That is, it will only "store" the message long enough
to dump it off at the intended recipient (as defined by the MX Host for
the target domain).

> [...]
>
> My last point may become less true over time because, as I already
> just posted, there is now an authoritative answer: If you don't
> know what to put, put home, corp, or mail, as you wish. They are
> guaranteed never to become TLDs in the future.

They're as guaranteed to "not" become as TLD as much as ".local" or
".me" or ".tech" were guaranteed to "not" be a TLD in the 1990s.

> I'm not convinced that I, and many in my situation, would be better
> off running a mail server rather than having an organisation run a
> smarthost to do it on my behalf. (They also take care of incoming mail
> by running an IMAP server.)

Ultimately it depends on how far you trust your ISP.  Cox is pretty good
(at least they were when I was in their service area).  TWC/Spectrum was
generally good, but they could break hard.  AT&T (Yahoo) is completely
useless.

Also, by running your own mailserver, you are not bound to your ISPs (or
google's, etc.) size limits / ads / etc.  For example, my parents can
send me 50MB emails (old and refuse to learn dropbox / owncloud for pics
of their grandkids ... so they send mails, and I put them where they
belong).


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Federated, decentralised communication on the internet

[Dan Purgert]

Richard Hector wrote:
> On 23/03/18 01:17, Greg Wooledge wrote:
>> [...]
>> RFC 1594 : A Fully Qualified
>> Domain Name (FQDN) is a domain name that includes all higher level
>> domains relevant to the entity named.  If you think of the DNS as a
>> tree-structure with each node having its own label, a Fully Qualified
>> Domain Name for a specific node would be its label followed by the
>> labels of all the other nodes between it and the root of the tree.
>>
>> For example, for a host, a FQDN would include the string that
>> identifies the particular host, plus all domains of which the host is
>> a part up to and including the top-level domain (the root domain is
>> always null).
>
> Thanks - Having read that paragraph of the RFC, it doesn't seem to
> require any particular number of levels, only that all that exist are
> present.
>
> Richard

It requires two "levels"

 1. the TLD itself
 2. the named host

Therefore, "com." (that is, the TLD 'com') is not a valid FQDN. However,
"a.com." (that is, the host 'a' on the 'com' TLD) is a valid FQDN.

NOTE -> the trailing dot is only required in DNS entries, general
internet usage (email, [web|ftp|nntp|etc] services, etc.) do not require
it to be used (although, a quick test to slashdot, google, and sparkfun;
all three resolved properly with the trailing dot included). 


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Re: Federated, decentralised communication on the internet

[dekks herton]

On 03/21, Miles Fidelman wrote:

On 3/21/18 11:48 AM, Charlie Gibbs wrote:


On 21/03/18 01:00 AM, to...@tuxteam.de wrote:


My problem with "social networks" is that they're monopolies. 
Imagine popping down to the local pub for a pint and a bit of 
conversation, only to find that it's part of a huge chain run by a 
transnational conglomerate.  I much prefer the Usenet model, 
although web sites that let you leave messages come pretty close. 
What I don't like are those web sites that make you log in through 
Facebook in order to post.  Since I don't have a Facebook account 
and never will, such sites will have to do without my pearls of 
wisdom.  :-)


Maybe we should move back to USENET.  It worked pretty well, and it's 
still going strong in some quarters.  Add some global identity & 
reputation management, and the ability to set up lots of small 
newsgroups - and we'd have one hell of a Facebook killer.


There's always Fidonet lol

--
regards.

Thinkpad T60p 2.33Ghz 2GB SXGA+

Jabber IM: dekkz...@jabber.hot-chilli.net


signature.asc
Description: PGP signature

Re: Federated, decentralised communication on the internet

[Richard Hector]

On 23/03/18 11:31, Dan Purgert wrote:
> Richard Hector wrote:
>> On 23/03/18 01:17, Greg Wooledge wrote:
>>> [...]
>>> RFC 1594 : A Fully Qualified
>>> Domain Name (FQDN) is a domain name that includes all higher level
>>> domains relevant to the entity named.  If you think of the DNS as a
>>> tree-structure with each node having its own label, a Fully Qualified
>>> Domain Name for a specific node would be its label followed by the
>>> labels of all the other nodes between it and the root of the tree.
>>>
>>> For example, for a host, a FQDN would include the string that
>>> identifies the particular host, plus all domains of which the host is
>>> a part up to and including the top-level domain (the root domain is
>>> always null).
>>
>> Thanks - Having read that paragraph of the RFC, it doesn't seem to
>> require any particular number of levels, only that all that exist are
>> present.
>>
>> Richard
> 
> It requires two "levels"
> 
>  1. the TLD itself
>  2. the named host
> 
> Therefore, "com." (that is, the TLD 'com') is not a valid FQDN. However,
> "a.com." (that is, the host 'a' on the 'com' TLD) is a valid FQDN.

That's not what I see in the RFC. The DNS only seems to care about a
tree of nodes with labels, not whether a particular node represents a
host or a network or something else. So if the node in question has the
label "com", and "All the other nodes" consist of just the root domain
(with the null label), that should be sufficient. Even just the null
label followed by (empty list) should be enough. What you say may well
be what was intended, but it doesn't seem specific to me.

I realise practical considerations may be different, but I don't see any
more requirement than that in that RFC.

Richard



signature.asc
Description: OpenPGP digital signature

Re: Federated, decentralised communication on the internet

[Miles Fidelman]

On 3/22/18 7:06 PM, dekks herton wrote:


On 03/21, Miles Fidelman wrote:

On 3/21/18 11:48 AM, Charlie Gibbs wrote:


On 21/03/18 01:00 AM, to...@tuxteam.de wrote:


My problem with "social networks" is that they're monopolies. 
Imagine popping down to the local pub for a pint and a bit of 
conversation, only to find that it's part of a huge chain run by a 
transnational conglomerate.  I much prefer the Usenet model, 
although web sites that let you leave messages come pretty close. 
What I don't like are those web sites that make you log in through 
Facebook in order to post.  Since I don't have a Facebook account 
and never will, such sites will have to do without my pearls of 
wisdom.  :-)


Maybe we should move back to USENET.  It worked pretty well, and it's 
still going strong in some quarters.  Add some global identity & 
reputation management, and the ability to set up lots of small 
newsgroups - and we'd have one hell of a Facebook killer.


There's always Fidonet lol

Does Fidonet still live?  I just checked fidonet.org and a lot of the 
links (like the node status one) go to odd places.  Fidonet.us seems to 
be current, but no list of active nodes.  Sigh...


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Federated, decentralised communication on the internet

[Dan Purgert]

Richard Hector wrote:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --xzXHS3VVn10PcTmOrOWirzNfIdRO84rgl
> Content-Type: multipart/mixed; boundary="Wlh5om7AxfFwwkNI2fav87yEOngrEELuZ";
>  protected-headers="v1"
> From: Richard Hector 
> To: debian-user@lists.debian.org
> Message-ID: <70d1e443-073a-16d7-f14c-89d5d2be1...@walnut.gen.nz>
> Subject: Re: Federated, decentralised communication on the internet
> References: <20180219162356.GA4712@alum>
> <19022018180243.2ced26b8f...@desktop.copernicus.org.uk>
> <20180222175818.GA12408@alum>
> <23022018142458.08644849f...@desktop.copernicus.org.uk>
> <20180320220747.GA14927@alum> <85muz2z7iw.fsf...@benfinney.id.au>
> <20180321195347.GD7863@alum> <20180321202144.3oxfe5puynsf5...@eeg.ccf.org>
> <3d20dce8-38ee-dbac-e8a5-c13b79f84...@walnut.gen.nz>
> 
> <20180322121746.w4yx77mpmwlmf...@eeg.ccf.org>
> 
> 
> In-Reply-To: 
>
> --Wlh5om7AxfFwwkNI2fav87yEOngrEELuZ
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> On 23/03/18 11:31, Dan Purgert wrote:
>> Richard Hector wrote:
>>> On 23/03/18 01:17, Greg Wooledge wrote:
 [...]
 RFC 1594 : A Fully Qualified
 Domain Name (FQDN) is a domain name that includes all higher level
 domains relevant to the entity named.  If you think of the DNS as a
 tree-structure with each node having its own label, a Fully Qualified=
>
 Domain Name for a specific node would be its label followed by the
 labels of all the other nodes between it and the root of the tree.

 For example, for a host, a FQDN would include the string that
 identifies the particular host, plus all domains of which the host is=
>
 a part up to and including the top-level domain (the root domain is
 always null).
>>>
>>> Thanks - Having read that paragraph of the RFC, it doesn't seem to
>>> require any particular number of levels, only that all that exist are
>>> present.
>>>
>>> Richard
>>=20
>> It requires two "levels"
>>=20
>>  1. the TLD itself
>>  2. the named host
>>=20
>> Therefore, "com." (that is, the TLD 'com') is not a valid FQDN. However=
> ,
>> "a.com." (that is, the host 'a' on the 'com' TLD) is a valid FQDN.
>
> That's not what I see in the RFC. The DNS only seems to care about a
> tree of nodes with labels, not whether a particular node represents a
> host or a network or something else. So if the node in question has the
> label "com", and "All the other nodes" consist of just the root domain
> (with the null label), that should be sufficient. Even just the null
> label followed by (empty list) should be enough. What you say may well
> be what was intended, but it doesn't seem specific to me.

You seem to be considering a "node" as representing more than it
actually is -- a node cannot simultaneously be "a named entity" AND ALSO
a grouping. 

I suppose we can consider a FQDN to be somewhat like a mailing address:

"country" is the root (though unlike DNS, it's "optional" information -
  if not specified "the country of origin" is assumed)
"zipcode" is the TLD
"state" is the domain
"city" is a subdomain
"street address" is another subdomain
"addressed individual" is the entity.


This isn't a valid address:

USA

Nor is anything up to and including

123 Main Street
Anytown, Anystate  90210

Which is why all of your bulk mail is sent to something like

Current Resident
your_address
your_city, your_state zipcode

Likewise, "com" is not a FQDN, since it doesn't name a specific entity
that is part of the "com" top-level domain.  

On the other hand, "lists.debian.org" is fully qualified for the
specific host "lists" of the "debian" domain of the "org" TLD. However,
"lists.debian" is not a FQDN, as it does not ultimately point to a valid
TLD.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Missing Shared Object File for ffmpeg

[Dan Norton]

On Wed, 21 Mar 2018 12:46:06 -0500
David Wright  wrote:

> On Tue 20 Mar 2018 at 21:29:49 (-0400), Dan Norton wrote:
> > On Tue, 20 Mar 2018 18:35:48 -0500
> > David Wright  wrote:
> >   
> > > On Tue 20 Mar 2018 at 18:41:55 (-0400), Dan Norton wrote:  
> > > > On Tue, 20 Mar 2018 13:42:24 -0500
> > > > David Wright  wrote:
> > > > 
> > > > > On Tue 20 Mar 2018 at 13:47:42 (-0400), Dan Norton wrote:
> > > > > > On Tue, 20 Mar 2018 12:59:21 -0400
> > > > > > Greg Wooledge  wrote:
> > > > > >   
> > > > > > > On Tue, Mar 20, 2018 at 12:18:05PM -0400, Dan Norton
> > > > > > > wrote:  
> > > > > > > > >  * The output of "apt policy ffmpeg".
> > > > > > > > 
> > > > > > > > ffmpeg:
> > > > > > > >   Installed: 7:3.2.10-1~deb9u1
> > > > > > > >   Candidate: 7:3.2.10-1~deb9u1
> > > > > > > >   Version table:
> > > > > > > >  *** 7:3.2.10-1~deb9u1 500
> > > > > > > > 500 http://debian.gtisc.gatech.edu/debian
> > > > > > > > stretch/main amd64 Packages 
> > > > > > > > 500 http://security.debian.org/debian-security
> > > > > > > > stretch/updates/main amd64 Packages 
> > > > > > > > 100 /var/lib/dpkg/status
> > > > > > > > 
> > > > > > > > >  * The output of "aptitude why libopenal1".
> > > > > > > > 
> > > > > > > > i   ffmpegDepends libavdevice57 (>= 7:3.2.10)
> > > > > > > > i A libavdevice57 Depends libopenal1 (>=
> > > > > > > > 1.14)   
> > > > > > >   
> > > > > > > >From these, it looks like you have the stretch version of
> > > > > > > >ffmpeg, and
> > > > > > > a libopenal1 dependency that can be satisfied by the
> > > > > > > stretch version of libopenal1.
> > > > > > > 
> > > > > > > If libopenal1 is not actually installed, then something is
> > > > > > > very wrong. Is it possible that you have the package
> > > > > > > "installed", but something else removed the library
> > > > > > > file?  In that case, just reinstall the package:
> > > > > > > 
> > > > > > > apt-get --reinstall install libopenal1
> > > > > > >   
> > > > > > 
> > > > > > That did it - thanks, Greg! 
> > > > > > 
> > > > > > But what does this do that apt purge/install of ffmpeg does
> > > > > > not?  
> > > > > 
> > > > > You posted:
> > > > > 
> > > > > # apt purge ffmpeg
> > > > > # apt autoremove
> > > > > # apt install ffmpeg
> > > > > 
> > > > > but you didn't show your working. You should check out what
> > > > > happened by looking at /var/log/apt/history.log to see if
> > > > > libopenal1 was affected by this command sequence. For a start,
> > > > > other packages might depend on libopenal1, preventing its
> > > > > auto-removal.   
> > > > 
> > > > The broken system was installed in December 2017. Looking at
> > > > all the logs in /var/log/apt/history* (extracting the ones that
> > > > were archived) and running:
> > > > dan@deb9:~/apt.logs$ grep -rnw '.' -e 'libopenal1' | less
> > > > ...there is one hit, other than today's --reinstall and that is
> > > > an install:
> > > > 
> > > > Start-Date: 2017-12-17  21:29:03
> > > > Commandline: /usr/sbin/synaptic
> > > > Requested-By: dan (1200)
> > > > Install: [...]
> > > > libopenal1:amd64 (1:1.17.2-4+b2, automatic),  # e pluribus unum
> > > > [...]
> > > > 
> > > > > Then of course there's the investigation of why it wasn't
> > > > > installed correctly in the first place, and what was happening
> > > > > during the "several attempts" at installing ffmpeg.
> > > > > 
> > > > 
> > > > Apparently nothing during these attempts involved libopenal1,
> > > > according to the logs in /var/log/apt/ - is there anywhere else
> > > > that could shed light on this?
> > > 
> > > Is it still marked as Automatic? Particularly if you try to
> > > install it, it will lose that flag (all this is IIRC). Further
> > > use of that command sequence would have no effect in that case.
> > >   
> > 
> > root@deb9:~# apt search libopenal1
> > Sorting... Done
> > Full Text Search... Done
> > libopenal1/stable,now 1:1.17.2-4+b2 amd64 [installed,automatic]
> > [...]
> >   
> > > The dependency is via another package. I've found that removing a
> > > package doesn't always reach down to all the Automatic packages
> > > beneath it. This is easily demonstrated by installing a package
> > > with multiple dependencies (in depth) and then immediately purging
> > > it.
> > > 
> > > But none of this gets down to the root of the problem (why the
> > > installed package didn't provide the library). Perhaps it might
> > > be worth occasionally running
> > > # debsums -l
> > > # debsums -ca
> > > to check things over. There's also dpkg -V.
> > >   
> > 
> > root@deb9:~# debsums -l
> > root@deb9:~# 
> > 
> > root@deb9:~# debsums -ca 2>/home/dan/debsums.out
> > /etc/lvm/lvm.conf
> > ...producing 958.9 kB of missing file messages in debsums.out, none
> > mention libopenal1.  
> 
> Interesting difference between your systems and mine:
> 
> wheezy:
> 
> # debsums -l
> # debsums -ca
> /etc/apt-cacher

Re: Federated, decentralised communication on the internet

[Miles Fidelman]

On 3/22/18 7:14 PM, Richard Hector wrote:


On 23/03/18 11:31, Dan Purgert wrote:

Richard Hector wrote:

On 23/03/18 01:17, Greg Wooledge wrote:

[...]
RFC 1594 : A Fully Qualified
Domain Name (FQDN) is a domain name that includes all higher level
domains relevant to the entity named.  If you think of the DNS as a
tree-structure with each node having its own label, a Fully Qualified
Domain Name for a specific node would be its label followed by the
labels of all the other nodes between it and the root of the tree.

For example, for a host, a FQDN would include the string that
identifies the particular host, plus all domains of which the host is
a part up to and including the top-level domain (the root domain is
always null).

Thanks - Having read that paragraph of the RFC, it doesn't seem to
require any particular number of levels, only that all that exist are
present.

Richard

It requires two "levels"

  1. the TLD itself
  2. the named host

Therefore, "com." (that is, the TLD 'com') is not a valid FQDN. However,
"a.com." (that is, the host 'a' on the 'com' TLD) is a valid FQDN.

That's not what I see in the RFC. The DNS only seems to care about a
tree of nodes with labels, not whether a particular node represents a
host or a network or something else. So if the node in question has the
label "com", and "All the other nodes" consist of just the root domain
(with the null label), that should be sufficient. Even just the null
label followed by (empty list) should be enough. What you say may well
be what was intended, but it doesn't seem specific to me.

I realise practical considerations may be different, but I don't see any
more requirement than that in that RFC.

Christ, why are we still discussing this.  (And what does it have to do 
with the original question about "Federated, decentralised communication 
on the internet?"  ... which was originally a question about how 
"hostname" is used by Debian)  But...


An FQDN defines the location of an entity in the DNS tree.  For a host - 
which is what we've been discussing, and generally what one is talking 
about when talking about FQDN's an FQDN consists of both a hostname AND 
a domain name.  (Again, in the Linux context, one is generally making 
the distinction between "hostname," "network name," and "fully qualified 
domain name" - often in the context of setting up a machine, or the 
"hostname" and "dnsdomainname" commands, "hostname --fqdn", or the files 
where such information is stored.)


When it comes to hosts, it is generally understood that the FQDN 
consists of both the hostname and domainname, and an awful lot of 
protocol specs cite (and quote) https://tools.ietf.org/html/rfc1983 - 
the "Internet Users' Glossary" which says...


   Fully Qualified Domain Name (FQDN)
  The FQDN is the full name of a system, rather than just its
  hostname.  For example, "venera" is a hostname and
  "venera.isi.edu" is an FQDN.  See also: hostname, Domain Name
  System.


Now, arguably, "." is an FQDN specifying the very top of the DNS tree, 
and "com" (or "com.") specifies the top of the com domain - but who 
really cares.  Particularly since the whole discussion started around 
fully qualified HOST names.


Another common definition of an FQDN is that it uniquely identifies a 
node in the DNS tree.  By that view "." is the FQDN for the top of the 
tree, and "com" (or "com." is the top of the .com domain - but who 
really cares, except for pedantic purposes.   There aren't any 
nameservers that resolve "." or "com" or "mil" - implying that there are 
no records in the system for them (maybe there should be, but that's 
another question for another day).


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: domain names, was: hostname

[David Wright]

On Thu 22 Mar 2018 at 20:26:26 (+), Brian wrote:
> On Thu 22 Mar 2018 at 12:44:53 -0500, David Wright wrote:
> 
> [...]
> 
> > Here are my points, as it's a month since I made them. I didn't
> > quite answer the question as posed.
> > 
> > --✄--
> > 
> > > that as well as being asked to supply a hostname I've also been asked
> > > to supply a domain value.
> > >
> > > What, on a home LAN, is that used for?
> > 
> > Nothing, with the possible exceptions of:
> > 
> > . avoiding this message at boot up:
> >   Mon Feb 19 04:58:38 2018: [] Starting MTA:hostname --fqdn did not 
> > return a fully qualified name,
> >   Mon Feb 19 04:58:38 2018: dc_minimaldns will not work. Please fix your 
> > /etc/hosts setup.
> > 
> > . satisfying a broken smarthost¹,
> > 
> > . causing some discussion here.
> > 
> > --✄--
> > 
> > My last point may become less true over time because, as I already
> > just posted, there is now an authoritative answer: If you don't
> > know what to put, put home, corp, or mail, as you wish. They are
> > guaranteed never to become TLDs in the future.
> 
> The d-i prompt says:
> 
>  > The domain name is the part of your Internet address to the right of your
>  > host name.  It is often something that ends in .com, .net, .edu, or .org.
>  > If you are setting up a home network, you can make something up, but make
>  > sure you use the same domain name on all your computers.
> 
> There you are: a home user can just invent something. mybrilliantdomain.com
> would do.

It's out of date advice. I'll post the reference again.
https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail
"Resolved (2018.02.04.12), the Board directs the President and CEO, or
his designee(s), that the applications for .CORP, .HOME, and .MAIL
should not proceed and, to account for the unforeseen impact to
application processing, the Board directs the President and CEO to,
upon withdrawal of the remaining applications for .CORP, .HOME, and
.MAIL, provide the applicants a full refund of the New gTLD Program
application fee of $185,000."

> Why agonise over it.

I don't. Others do. It appeared to worry Greg when he posted
https://lists.debian.org/debian-user/2018/02/msg00169.html

> Whatever is chosen goes into /etc/hosts.
> 
> A long time ago, the advice was:
> 
>  > Please enter your domain name or leave this field empty if you don't have
>  > a domain.

which still works.

> > Currently I have an empty string. When I next reorganise my network
> > here to include bridging, I might consider using .home (it's the
> > most appropriate). It affords me no particular advantage as far as
> > I can see, but I remain open to persuasion that it has some use.
> > What exactly, though? (Still a genuine question, but keep off email
> > or we're in danger of getting in a loop.)
> 
> An empty string is fine. Just do it; you will be happy with it.

I was. Others weren't.¹

> > I'm not convinced that I, and many in my situation, would be better
> > off running a mail server rather than having an organisation run a
> > smarthost to do it on my behalf. (They also take care of incoming mail
> > by running an IMAP server.)
> 
> Nobody has really tried to convince you that running a mail server is
> better for *you*.

I don't know about that. "You don't talk to people except through an
intermediary? I prefer to know what happens to the mails I send."
And others trying to convince me to make a change that might be
necessary were I running a mail server.¹

> (You actually do run a mail server but use it for relaying, not sending
> directly. Greg Wooledge's posts are very informative. Please try to see
> the distinctions).

A bit late to say that. If there are ambiguities in what I have
written, point them out without patronising.

How about the term Mail Submission Agent. Would that make you happier?

> > I think the political discussion arises here because people don't
> > recognise that just contributing to this list makes one unusual in
> > itself (and I include myself in that). There may be divers diverse
> > reasons to run a mail server, but count me out along with many others.
> 
> Ben Finney's post really got to you, didn't it?
> 
>   https://lists.debian.org/debian-user/2018/03/msg00738.html

Only in as much as the post implied I was arbitrarily denying people
from doing something and demanding their reasons for wanting to do it.
I don't know if this was because Ben hadn't been following the thread
last month, but I can see that without the context of our previous
conversation, it might be possible to take a different meaning from
my paragraph. Why are you worried about it?

¹ This is the second time in two months. In January I revealed that I
use IPv6 to make temporary local connections, was scolded for it and
told that I should be using IPv4 instead. After following all their
proffered instructions, it was evident that there was a lot more work
involved in doing it their way compared with the simp

Re: domain names, was: hostname

[David Wright]

On Thu 22 Mar 2018 at 22:17:02 (-), Dan Purgert wrote:
> David Wright wrote:
> > On Thu 22 Mar 2018 at 08:58:43 (-0400), Greg Wooledge wrote:
> >> [...]
> >> An SMTP receiver SHOULD validate the recipient address right here,
> >> right now.  It SHOULDN'T just accept everything and then figure out
> >> whether it's deliverable later -- that enables joe-job spam.
> >
> > How is it meant to do that. If it's relaying, the system it's
> > eventually going to send the message to might not even be
> > running just now. Email is store and forward, isn't it?
> 
> If it's *relaying*, it is not *receiving*; there's a subtle but key
> difference there.  At most, a relay will likely validate 
> 
>  
>  - source (host or user) is allowed to relay via me.
>  - destination is a FQDN
> 
> The closest that a relay will "store-and-forward" is in essence similar
> to if your roommate (significant other, etc.) is going out ... you say
> "hey, since you're gonna go past the mailbox, mind dropping these in
> there for me?".  That is, it will only "store" the message long enough
> to dump it off at the intended recipient (as defined by the MX Host for
> the target domain).

I took "receiver" to mean the sense used here:
"Message transfer can occur in a single connection between two MTAs, or
in a series of hops through intermediary systems. A receiving SMTP
server may be the ultimate destination, an intermediate "relay" (that
is, it stores and forwards the message) or a "gateway" (that is, it
may forward the message using some protocol other than SMTP). Each hop
is a formal handoff of responsibility for the message, whereby the
receiving server must either deliver the message or properly report
the failure to do so."
https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

Some of us remember when emails passed through several gateways and
could take a couple of days to reach their destination. We used to
spend our time juggling addresses containing multiple ::, @, and %
delimiters, with hops through JANET (which at that time wrote its
addresses backwards), EARN, BITNET and Inmarsat, all kicked off by
pasting the message into a Telex on BT Gold. Academic institutions
could only afford to link up through Inmarsat a couple of times a
day at most. I could only afford BT Gold (out of hours) because a
friend managed an experimental comms project at university. This
was how it was in the mid-late 1980s.

> > [...]
> >
> > My last point may become less true over time because, as I already
> > just posted, there is now an authoritative answer: If you don't
> > know what to put, put home, corp, or mail, as you wish. They are
> > guaranteed never to become TLDs in the future.
> 
> They're as guaranteed to "not" become as TLD as much as ".local" or
> ".me" or ".tech" were guaranteed to "not" be a TLD in the 1990s.

Perhaps this was pre-ICANN? Do you have a reference? Or a contact inside
ICANN that knows something nobody else knows about resolution 2018.02.04.12.

> > I'm not convinced that I, and many in my situation, would be better
> > off running a mail server rather than having an organisation run a
> > smarthost to do it on my behalf. (They also take care of incoming mail
> > by running an IMAP server.)
> 
> Ultimately it depends on how far you trust your ISP.  Cox is pretty good
> (at least they were when I was in their service area).  TWC/Spectrum was
> generally good, but they could break hard.  AT&T (Yahoo) is completely
> useless.
> 
> Also, by running your own mailserver, you are not bound to your ISPs (or
> google's, etc.) size limits / ads / etc.  For example, my parents can
> send me 50MB emails (old and refuse to learn dropbox / owncloud for pics
> of their grandkids ... so they send mails, and I put them where they
> belong).

Yes, it's tedious that Cox sends a marketing letter every week expounding
their TV service. Oh, you didn't mean that? Which ads do you mean?

Cheers,
David.

Re: Federated, decentralised communication on the internet

[Richard Hector]

On 23/03/18 13:55, Dan Purgert wrote:
> Richard Hector wrote:

>>
>> On 23/03/18 11:31, Dan Purgert wrote:
>>> Richard Hector wrote:
 On 23/03/18 01:17, Greg Wooledge wrote:
> [...]
> RFC 1594 : A Fully Qualified
> Domain Name (FQDN) is a domain name that includes all higher level
> domains relevant to the entity named.  If you think of the DNS as a
> tree-structure with each node having its own label, a Fully Qualified=
>>
> Domain Name for a specific node would be its label followed by the
> labels of all the other nodes between it and the root of the tree.
>
> For example, for a host, a FQDN would include the string that
> identifies the particular host, plus all domains of which the host is=
>>
> a part up to and including the top-level domain (the root domain is
> always null).

 Thanks - Having read that paragraph of the RFC, it doesn't seem to
 require any particular number of levels, only that all that exist are
 present.

 Richard
>>> =20
>>> It requires two "levels"
>>> =20
>>>  1. the TLD itself
>>>  2. the named host
>>> =20
>>> Therefore, "com." (that is, the TLD 'com') is not a valid FQDN. However=
>> ,
>>> "a.com." (that is, the host 'a' on the 'com' TLD) is a valid FQDN.
>>
>> That's not what I see in the RFC. The DNS only seems to care about a
>> tree of nodes with labels, not whether a particular node represents a
>> host or a network or something else. So if the node in question has the
>> label "com", and "All the other nodes" consist of just the root domain
>> (with the null label), that should be sufficient. Even just the null
>> label followed by (empty list) should be enough. What you say may well
>> be what was intended, but it doesn't seem specific to me.
> 
> You seem to be considering a "node" as representing more than it
> actually is -- a node cannot simultaneously be "a named entity" AND ALSO
> a grouping.

A node is a point in a tree. It has a (possibly null) label, and may or
may not represent a host. Fair?

> I suppose we can consider a FQDN to be somewhat like a mailing address:
> 
> "country" is the root (though unlike DNS, it's "optional" information -
>   if not specified "the country of origin" is assumed)
> "zipcode" is the TLD
> "state" is the domain
> "city" is a subdomain
> "street address" is another subdomain
> "addressed individual" is the entity.

I wouldn't necessarily count the addressed individual as part of the
address.

> This isn't a valid address:
> 
> USA

Probably not, unless the USPS or whoever is responsible decides it is,
which they could.

> Nor is anything up to and including
> 
> 123 Main Street
> Anytown, Anystate  90210

I would say that is (as long as it exists), and would assume mail would
arrive there. What happens after that is up to whoever clears the
mailbox. But obviously an email address requires a local part.

> Likewise, "com" is not a FQDN, since it doesn't name a specific entity
> that is part of the "com" top-level domain.

It currently doesn't. But that's just because there's none of the common
'entity' records. If the admin added an A record or an MX record or
something, it would.

> On the other hand, "lists.debian.org" is fully qualified for the
> specific host "lists" of the "debian" domain of the "org" TLD. However,
> "lists.debian" is not a FQDN, as it does not ultimately point to a valid
> TLD.

Agreed (currently)

Richard




signature.asc
Description: OpenPGP digital signature

Re: Federated, decentralised communication on the internet

[Richard Hector]

On 23/03/18 14:44, Miles Fidelman wrote:
> Christ,

Richard :-)

> why are we still discussing this.  (And what does it have to do
> with the original question about "Federated, decentralised communication
> on the internet?"  ... which was originally a question about how
> "hostname" is used by Debian)

Agreed. Apologies for the deviation.

>  But...
> 
> An FQDN defines the location of an entity in the DNS tree.  For a host -
> which is what we've been discussing, and generally what one is talking
> about when talking about FQDN's an FQDN consists of both a hostname AND
> a domain name.  (Again, in the Linux context, one is generally making
> the distinction between "hostname," "network name," and "fully qualified
> domain name" - often in the context of setting up a machine, or the
> "hostname" and "dnsdomainname" commands, "hostname --fqdn", or the files
> where such information is stored.)
> 
> When it comes to hosts, it is generally understood that the FQDN
> consists of both the hostname and domainname, and an awful lot of
> protocol specs cite (and quote) https://tools.ietf.org/html/rfc1983 -
> the "Internet Users' Glossary" which says...
> 
>Fully Qualified Domain Name (FQDN)
>   The FQDN is the full name of a system, rather than just its
>   hostname.  For example, "venera" is a hostname and
>   "venera.isi.edu" is an FQDN.  See also: hostname, Domain Name
>   System.

Another reference, thanks. Still not specific.

> Now, arguably, "." is an FQDN specifying the very top of the DNS tree,
> and "com" (or "com.") specifies the top of the com domain - but who
> really cares.  Particularly since the whole discussion started around
> fully qualified HOST names.

This is my point. And AFAIK DNS would happily accept an A record for
com, and probably . too. (I haven't tried it in BIND; I should ...)

> Another common definition of an FQDN is that it uniquely identifies a
> node in the DNS tree.  By that view "." is the FQDN for the top of the
> tree, and "com" (or "com." is the top of the .com domain - but who
> really cares, except for pedantic purposes.

When talking about specs and RFCs (which maybe only I was), surely
pedantic purposes are what it's all about?

>  There aren't any
> nameservers that resolve "." or "com" or "mil" - implying that there are
> no records in the system for them (maybe there should be, but that's
> another question for another day).

There might not be A,  or MX records, but there are certainly
servers, and they serve at least SOA and NS (and RRSIG) records for all
3 of those.

Again, apologies for the aside that got a bit carried away.

Richard



signature.asc
Description: OpenPGP digital signature