MESSAGE
| DATE | 2017-11-04 |
| FROM | ruben safir
|
| SUBJECT | Subject: [Learn] Fwd: Problem with bash and signal trapping
|
From learn-bounces-at-nylxs.com Sat Nov 4 01:09:47 2017
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www.mrbrklyn.com (www.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id 455E4163F54;
Sat, 4 Nov 2017 01:09:47 -0400 (EDT)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from [10.0.0.62] (unknown [10.0.0.62])
by mrbrklyn.com (Postfix) with ESMTP id 2723A160876
for ; Sat, 4 Nov 2017 01:09:45 -0400 (EDT)
References:
<11891240.uLZWGnKmhe-at-PointedEars.de>
<2050609.ElGaqSPkdT-at-PointedEars.de>
To: "learn-at-nylxs.com"
From: ruben safir
X-Forwarded-Message-Id:
<11891240.uLZWGnKmhe-at-PointedEars.de>
<2050609.ElGaqSPkdT-at-PointedEars.de>
Message-ID: <97b0042f-b9e8-4a05-bc00-4523707765b2-at-mrbrklyn.com>
Date: Sat, 4 Nov 2017 01:09:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2050609.ElGaqSPkdT-at-PointedEars.de>
Content-Type: multipart/mixed; boundary="------------9A68575689919C026738DBBB"
Content-Language: en-US
Subject: [Learn] Fwd: Problem with bash and signal trapping
X-BeenThere: learn-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"
This is a multi-part message in MIME format.
--------------9A68575689919C026738DBBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Problem with bash and signal trapping"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Problem with bash and signal trapping"
Path: reader2.panix.com!panix!news.linkpendium.com!news.linkpendium.com!news.snarked.org!xmission!nnrp.xmission!.POSTED.shell.xmission.com!not-for-mail
From: gazelle-at-shell.xmission.com (Kenny McCormack)
Newsgroups: comp.unix.shell
Subject: Problem with bash and signal trapping
Date: Sat, 28 Oct 2017 14:46:41 +0000 (UTC)
Organization: The official candy of the new Millennium
Message-ID:
Injection-Date: Sat, 28 Oct 2017 14:46:41 +0000 (UTC)
Injection-Info: news.xmission.com; posting-host="shell.xmission.com:166.70.8.4";
logging-data="22944"; mail-complaints-to="abuse-at-xmission.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: gazelle-at-shell.xmission.com (Kenny McCormack)
Xref: panix comp.unix.shell:263670
The context: Assume you have a program that catches signals (specifically
the interrupt signal) but takes a while to exit once the signal is caught.
I.e., assume that it does some cleanup or somethng like that, then exits.
In the example shown below, the part of this sluggish program is being
played by a 'bash -c ...' construct.
Now consider:
$ nl flizzle
1 #!/bin/bash
2
3
4 p() {
5 echo "About to sleep 10 seconds..."
6 sleep 10
7 echo "Done with sleeping..."
8 }
9 echo "Press ^C when you are ready..."
10 trap p INT
11 bash -c 'trap : INT
12 sleep 65000
13 echo "Caught signal - now sleeping for 20 seconds..."
14 sleep 20;echo "Done!"'
15 trap INT
16 # rest of script here...
$ ./flizzle
Press ^C when you are ready...
^CCaught signal - now sleeping for 20 seconds...
{ There is a 20 second delay here... }
Done!
About to sleep 10 seconds...
{ There is a 10 second delay here... }
Done with sleeping...
$
Now, the issue is that the function p() doesn't execute until *after* the
'bash -c ...' construct has exited - that is, after the 20 seconds has
elapsed. This is not what I want. I think that p() should execute as soon
as the interrupt signal has occurred. Why should it be delayed?
Is there any workaround?
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Re: Problem with bash and signal trapping"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Problem with bash and signal trapping"
Path: reader2.panix.com!panix!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "David W. Hodgins"
Newsgroups: comp.unix.shell
Subject: Re: Problem with bash and signal trapping
Date: Sat, 28 Oct 2017 12:45:19 -0400
Organization: A noiseless patient Spider
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="d9f3059ac4ca0b9e9b2434bfa8a1b020";
logging-data="19764"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX1+9ce7DS2ncOaaaN4oLLPF3cN9w5vcjvYw="
User-Agent: Opera Mail/12.16 (Linux)
Cancel-Lock: sha1:TXaOOMKXKy3DQJnMwFKgYuc6UKM=
Xref: panix comp.unix.shell:263674
On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack wrote:
> Now, the issue is that the function p() doesn't execute until *after* the
> 'bash -c ...' construct has exited - that is, after the 20 seconds has
> elapsed. This is not what I want. I think that p() should execute as soon
> as the interrupt signal has occurred. Why should it be delayed?
See man bash, starting with the section SIGNALS.
> Is there any workaround?
Put the command into the background, and use the wait builtin command,
which bash can trap the signal for. Either use the trailing " &" or see
the section Coprocesses in man bash, for some info.
Regards, Dave Hodgins
--
Change dwhodgins-at-nomail.afraid.org to davidwhodgins-at-teksavvy.com for
email replies.
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Re: Problem with bash and signal trapping"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Problem with bash and signal trapping"
Path: reader2.panix.com!panix!news.linkpendium.com!news.linkpendium.com!news.snarked.org!xmission!nnrp.xmission!.POSTED.shell.xmission.com!not-for-mail
From: gazelle-at-shell.xmission.com (Kenny McCormack)
Newsgroups: comp.unix.shell
Subject: Re: Problem with bash and signal trapping
Date: Sun, 29 Oct 2017 02:38:57 +0000 (UTC)
Organization: The official candy of the new Millennium
Message-ID:
References:
Injection-Date: Sun, 29 Oct 2017 02:38:57 +0000 (UTC)
Injection-Info: news.xmission.com; posting-host="shell.xmission.com:166.70.8.4";
logging-data="13780"; mail-complaints-to="abuse-at-xmission.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: gazelle-at-shell.xmission.com (Kenny McCormack)
Xref: panix comp.unix.shell:263676
In article ,
David W. Hodgins wrote:
>On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack wrote:
>
>> Now, the issue is that the function p() doesn't execute until *after* the
>> 'bash -c ...' construct has exited - that is, after the 20 seconds has
>> elapsed. This is not what I want. I think that p() should execute as soon
>> as the interrupt signal has occurred. Why should it be delayed?
>
>See man bash, starting with the section SIGNALS.
Yeah, OK. Seems like a bug, but it is documented.
>> Is there any workaround?
>
>Put the command into the background, and use the wait builtin command,
>which bash can trap the signal for. Either use the trailing " &" or see
>the section Coprocesses in man bash, for some info.
That doesn't work, because the job run with & (or coproc) is protected from
keyboard interrupts, which defeats the whole purpose.
The solution turns out to be to write a C helper program, that is
(roughly/pseudo-code):
/* Top level program that spawns a sub-program */
if (fork()) { wait(0);return 0; }
execlp(...)
The idea is that you run this program and it spawns the program you want to
run, then waits for it to finish. Either the subprogram exits or the user
hits ^C, which kills the top level program (which is stuck in wait()), but the
spawned program is allowed to continue running (it also having received the
interrupt signal, but continues running for awhile). Once the top-level
program exits, you're back in the shell script and can do whatever you need
to do, without having to wait for the sub-program completing.
Note that conceptually, this would have to be a C program, but I ended up
using another (non-standard) tool to do it, avoiding the need for yet
another dippy little C util...
--
Modern Conservative: Someone who can take time out from flashing her
wedding ring around and bragging about her honeymoon to complain that a
fellow secretary who keeps a picture of her girlfriend on her desk is
"flauting her sexuality" and "forcing her lifestyle down our throats".
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Re: Problem with bash and signal trapping"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Problem with bash and signal trapping"
Path: reader2.panix.com!panix!goblin2!goblin.stu.neva.ru!feeder.erje.net!2.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "David W. Hodgins"
Newsgroups: comp.unix.shell
Subject: Re: Problem with bash and signal trapping
Date: Sat, 28 Oct 2017 22:50:56 -0400
Organization: A noiseless patient Spider
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="da936681a5ad54a5a5c668791683fc04";
logging-data="27476"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX18PhdGmcsrRHQG+fd9g3IqQM9/vR4drdpw="
User-Agent: Opera Mail/12.16 (Linux)
Cancel-Lock: sha1:hE6Wc8Jkq6bCKHANXivVqsNSVXs=
Xref: panix comp.unix.shell:263677
On Sat, 28 Oct 2017 22:38:57 -0400, Kenny McCormack wrote:
> In article ,
> David W. Hodgins wrote:
>> On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack wrote:
>>
>>> Now, the issue is that the function p() doesn't execute until *after* the
>>> 'bash -c ...' construct has exited - that is, after the 20 seconds has
>>> elapsed. This is not what I want. I think that p() should execute as soon
>>> as the interrupt signal has occurred. Why should it be delayed?
>>
>> See man bash, starting with the section SIGNALS.
>
> Yeah, OK. Seems like a bug, but it is documented.
>
>>> Is there any workaround?
>>
>> Put the command into the background, and use the wait builtin command,
>> which bash can trap the signal for. Either use the trailing " &" or see
>> the section Coprocesses in man bash, for some info.
>
> That doesn't work, because the job run with & (or coproc) is protected from
> keyboard interrupts, which defeats the whole purpose.
Have the bash script trap the int signal, and then have it send a
more forceful signal such as sigterm to the background process.
Regards, Dave Hodgins
--
Change dwhodgins-at-nomail.afraid.org to davidwhodgins-at-teksavvy.com for
email replies.
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Re: Problem with bash and signal trapping"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Problem with bash and signal trapping"
Path: reader2.panix.com!panix!goblin3!goblin.stu.neva.ru!news.mb-net.net!open-news-network.org!.POSTED.38.237.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch!not-for-mail
From: Thomas 'PointedEars' Lahn
Newsgroups: comp.unix.shell
Subject: Re: Problem with bash and signal trapping
Date: Sun, 29 Oct 2017 04:36:27 +0100
Organization: PointedEars Software (PES)
Message-ID: <11891240.uLZWGnKmhe-at-PointedEars.de>
References:
Reply-To: Thomas 'PointedEars' Lahn
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
Injection-Info: gwaiyur.mb-net.net; posting-host="38.237.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch:178.197.237.38";
logging-data="26228"; mail-complaints-to="abuse-at-open-news-network.org"
User-Agent: KNode/4.14.2
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg==
X-User-ID: U2FsdGVkX19roSxwshFiFYJIB7MXQxCexwtkc0VvS9A4nyFM/d/ocQ==
X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89-at-H46O$ASoW&?s}.k+&.Cancel-Lock: sha1:qvcor0E45TsSCWaLtybcXkIlc5s=
Xref: panix comp.unix.shell:263679
David W. Hodgins wrote:
> Change dwhodgins-at-nomail.afraid.org to davidwhodgins-at-teksavvy.com for
> email replies.
Do you realize that the unnecessary hassle you create, and the violations
you commit with this are completely pointless?
--
PointedEars
Twitter: -at-PointedEars2
Please do not cc me. /Bitte keine Kopien per E-Mail.
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Re: Problem with bash and signal trapping"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Problem with bash and signal trapping"
Path: reader2.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "David W. Hodgins"
Newsgroups: comp.unix.shell
Subject: Re: Problem with bash and signal trapping
Date: Sun, 29 Oct 2017 01:55:46 -0400
Organization: A noiseless patient Spider
Message-ID:
References:
<11891240.uLZWGnKmhe-at-PointedEars.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="da936681a5ad54a5a5c668791683fc04";
logging-data="16333"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX1/vFpAwJCcDdFGomc7D18MPvH6dj3wj/Gc="
User-Agent: Opera Mail/12.16 (Linux)
Cancel-Lock: sha1:lmmk4MIWFeU+W8ZUWUxdCoy1NWk=
Xref: panix comp.unix.shell:263680
On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn wrote:
> David W. Hodgins wrote:
>> Change dwhodgins-at-nomail.afraid.org to davidwhodgins-at-teksavvy.com for
>> email replies.
> Do you realize that the unnecessary hassle you create, and the violations
> you commit with this are completely pointless?
I set up nomail.afraid.org back when the swen email worm harvested usenet
from addresses. It's currently set to the ip address 127.212.212.212 with
the mx record pointing to a spamtrap used by http://www.uceprotect.net/
I changed if from 127.0.0.1 to 127.212.212.212, back at some point when
someone asked me to prove I controlled the hostname's address.
As I setup the host name, it doesn't violate any standards or terms of
service, that I'm aware of.
While spammers could easily harvest the address from the sig, so far
they have not been doing so, while the from address does get quite a
bit of spam, which I can confirm from the uceprotect logs.
Regards, Dave Hodgins
--
Change dwhodgins-at-nomail.afraid.org to davidwhodgins-at-teksavvy.com for
email replies.
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Re: Problem with bash and signal trapping"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Problem with bash and signal trapping"
Path: reader2.panix.com!panix!goblin2!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Aragorn
Newsgroups: comp.unix.shell
Subject: Re: Problem with bash and signal trapping
Date: Sun, 29 Oct 2017 11:36:14 +0100
Organization: A noiseless patient Spider
Message-ID:
References: <11891240.uLZWGnKmhe-at-PointedEars.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
Injection-Date: Sun, 29 Oct 2017 10:36:11 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="7356abb7911c6d3e8a15cdcc4f0359d7";
logging-data="10701"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX1/tiNMCjSyIJCoLwcP35/V7"
User-Agent: KNode/4.14.10
Cancel-Lock: sha1:KrHEG+0fBQki2Urjd7t60X8sEIw=
Xref: panix comp.unix.shell:263681
On Sunday 29 October 2017 06:55, David W. Hodgins conveyed the following
to comp.unix.shell...
> On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn
> wrote:
>
>> David W. Hodgins wrote:
>>> Change dwhodgins-at-nomail.afraid.org to davidwhodgins-at-teksavvy.com for
>>> email replies.
>
>> Do you realize that the unnecessary hassle you create, and the
>> violations you commit with this are completely pointless?
>
> [...]
>
> While spammers could easily harvest the address from the sig, so far
> they have not been doing so, while the from address does get quite a
> bit of spam, which I can confirm from the uceprotect logs.
Don't mind Mr. Lahn, Dave. He's an incredibly anal bully who thinks he
owns Usenet and who single-handedly defined the rules of conduct in this
newsgroup.
I've already long added him to my killfile, and so have many others.
--
With respect,
= Aragorn =
--------------9A68575689919C026738DBBB
Content-Type: message/rfc822;
name="Re: Problem with bash and signal trapping"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
filename="Re: Problem with bash and signal trapping"
Path: reader2.panix.com!panix!goblin3!goblin.stu.neva.ru!news.mb-net.net!open-news-network.org!.POSTED.38.237.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch!not-for-mail
From: Thomas 'PointedEars' Lahn
Newsgroups: comp.unix.shell
Subject: Re: Problem with bash and signal trapping
Date: Mon, 30 Oct 2017 14:00:12 +0100
Organization: PointedEars Software (PES)
Message-ID: <2050609.ElGaqSPkdT-at-PointedEars.de>
References: <11891240.uLZWGnKmhe-at-PointedEars.de>
Reply-To: Thomas 'PointedEars' Lahn
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
Injection-Info: gwaiyur.mb-net.net; posting-host="38.237.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch:178.197.237.38";
logging-data="31991"; mail-complaints-to="abuse-at-open-news-network.org"
User-Agent: KNode/4.14.2
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg==
X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89-at-H46O$ASoW&?s}.k+&.Cancel-Lock: sha1:s4M+708ccIZmv/BbUz0+4g+l9O0=
X-User-ID: U2FsdGVkX1+KwXjxHY6IYVmMjpUqdYSDRIaMsEgwx9zCmrRCLKrMaA==
Xref: panix comp.unix.shell:263684
David W. Hodgins wrote:
> On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn
> wrote:
Attribution _line_, not attribution novel.
>> David W. Hodgins wrote:
>>> Change dwhodgins-at-nomail.afraid.org to davidwhodgins-at-teksavvy.com for
>>> email replies.
>> Do you realize that the unnecessary hassle you create, and the violations
>> you commit with this are completely pointless?
>
> I set up nomail.afraid.org back when the swen email worm harvested usenet
> from addresses. It's currently set to the ip address 127.212.212.212 with
> the mx record pointing to a spamtrap used by http://www.uceprotect.net/
> I changed if from 127.0.0.1 to 127.212.212.212, back at some point when
> someone asked me to prove I controlled the hostname's address.
ACK. Sorry, it was late/early; I should have checked more carefully which
I usually do.
Maybe you have misunderstood that person. In fact, you do _not_ need to
be in control of the host’s DNS records. (I certainly do not own WEB.DE :))
> As I setup the host name, it doesn't violate any standards or terms of
> service, that I'm aware of.
RFC 5536, § 3.1.2 ? RFC 5322, § 3.6.2 ? § 3.4:
| […]
| A mailbox receives mail. […]
,-
|
| · Sender Address
|
| The e-mail addresses given in "From:", "Reply-To:", and "Sender:"
| SHOULD be yours (i.e. you should be entitled to use it) and
| SHOULD be valid (= should not bounce because of invalidity).
But:
,----
| $ host -t MX nomail.afraid.org
| nomail.afraid.org mail is handled by 10 nirvana.admins.ws.
|
| $ telnet -- nirvana.admins.ws smtp
| Trying 217.23.49.208...
| Connected to nirvana.admins.ws.
| Escape character is '^]'.
| 220 nirvana.admins.ws ESMTP Service UCEPROTECT V4.4 ready for you
| HELO […]
| 250 nirvana.admins.ws pleased to meet you, […]
| MAIL FROM:
| 250 Sender , OK
| RCPT TO:
| 550 Access denied: 550 (V4.4-RULE-0616) We have no user dwhodgins-at-nomail.afraid.org, please call your recipient if you are in doubt of the correct spelling.
| 421 Service no longer available for you, closing transmission channel
| Connection closed by foreign host.
`----
(JFYI: Using “invalid” instead as allowed by your provider will let you
end up in my killfile automagically.)
I have written a shell script to check e-mail addresses automagically,
but presently it cannot handle an unsupported VRFY command followed by
a MAIL FROM or RCPT TO command denied because of that command order.
(So posting its output for this "address" would be pointless as this
server denies the RCPT TO then.)
> While spammers could easily harvest the address from the sig, so far
> they have not been doing so, while the from address does get quite a
> bit of spam, which I can confirm from the uceprotect logs.
See RFC 5322, § 3.6.2 and
for *proper* solutions.
--
PointedEars
Twitter: -at-PointedEars2
Please do not cc me. /Bitte keine Kopien per E-Mail.
--------------9A68575689919C026738DBBB
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Learn mailing list
Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn
--------------9A68575689919C026738DBBB--
|
|
