info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem with bash and signal trapping
49 views
Skip to first unread message
Kenny McCormack
Oct 28, 2017, 10:46:44 AM10/28/17
to
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
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
David W. Hodgins
Oct 28, 2017, 12:45:30 PM10/28/17
to
On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack <gaz...@shell.xmission.com> 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.
> 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?
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 dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.
Kenny McCormack
Oct 28, 2017, 10:38:59 PM10/28/17
to
In article <op.y8tvhtj...@hodgins.homeip.net>,
>> 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".
David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack <gaz...@shell.xmission.com> 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.
>On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack <gaz...@shell.xmission.com> 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.
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".
David W. Hodgins
Oct 28, 2017, 10:51:14 PM10/28/17
to
On Sat, 28 Oct 2017 22:38:57 -0400, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <op.y8tvhtj...@hodgins.homeip.net>,
> David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>> On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack <gaz...@shell.xmission.com> 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
> In article <op.y8tvhtj...@hodgins.homeip.net>,
> David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>> On Sat, 28 Oct 2017 10:46:41 -0400, Kenny McCormack <gaz...@shell.xmission.com> 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.
more forceful signal such as sigterm to the background process.
Thomas 'PointedEars' Lahn
Oct 28, 2017, 11:36:33 PM10/28/17
to
David W. Hodgins wrote:
> Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
> email replies.
Do you realize that the unnecessary hassle you create, and the violations
> Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
> email replies.
you commit with this are completely pointless?
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. /Bitte keine Kopien per E-Mail.
David W. Hodgins
Oct 29, 2017, 1:55:55 AM10/29/17
to
On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> David W. Hodgins wrote:
>> Change dwho...@nomail.afraid.org to davidw...@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
> David W. Hodgins wrote:
>> Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
>> email replies.
> Do you realize that the unnecessary hassle you create, and the violations
> you commit with this are completely pointless?
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
--
Aragorn
Oct 29, 2017, 6:36:15 AM10/29/17
to
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
> <Point...@web.de> wrote:
>
>> David W. Hodgins wrote:
>>> Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
>>> email replies.
>
>> Do you realize that the unnecessary hassle you create, and the
>> violations you commit with this are completely pointless?
>
> [...]
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 =
to comp.unix.shell...
> On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
>
>> David W. Hodgins wrote:
>>> Change dwho...@nomail.afraid.org to davidw...@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
> 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.
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 =
Thomas 'PointedEars' Lahn
Oct 30, 2017, 9:00:16 AM10/30/17
to
David W. Hodgins wrote:
> On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
Attribution _line_, not attribution novel.
> On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
<https://www.netmeister.org/news/learn2quote1.html>
>> David W. Hodgins wrote:
>>> Change dwho...@nomail.afraid.org to davidw...@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.
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.
| […]
| A mailbox receives mail. […]
,-<http://www.eternal-september.org/index.php?showpage=terms>
|
| · 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:<Point...@web.de>
| 250 Sender <Point...@web.de>, OK
| RCPT TO:<dwho...@nomail.afraid.org>
| 550 Access denied: 550 (V4.4-RULE-0616) We have no user dwho...@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.)
<ObShell>
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.)
</ObShell>
> 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.
<http://www.interhack.net/pubs/munging-harmful/>
for *proper* solutions.
Kenny McCormack
Oct 30, 2017, 9:40:58 AM10/30/17
to
In article <op.y8uni6b...@hodgins.homeip.net>,
posting - but it didn't seem to work, so I abandoned the idea. I'm happy
with my current solution, so all's well.
Note: One thing I learned early on in shell scripting is that the &
facility for "backgrounding" a process is fraught with weirdness. Yes, it
is classical Unix, and in the old days, it was all we had, so we made do,
but it is rarely useable in the modern world.
--
A 70 year old man who watches 6 hours of TV a day, plays a lot of golf
and seems to always be in Florida is a retiree, not a president.
David W. Hodgins <dwho...@nomail.afraid.org> wrote:
...
>Have the bash script trap the int signal, and then have it send a
>more forceful signal such as sigterm to the background process.
I thought about that - and did some tests in that vein before my previous
>more forceful signal such as sigterm to the background process.
posting - but it didn't seem to work, so I abandoned the idea. I'm happy
with my current solution, so all's well.
Note: One thing I learned early on in shell scripting is that the &
facility for "backgrounding" a process is fraught with weirdness. Yes, it
is classical Unix, and in the old days, it was all we had, so we made do,
but it is rarely useable in the modern world.
--
A 70 year old man who watches 6 hours of TV a day, plays a lot of golf
and seems to always be in Florida is a retiree, not a president.
Ivan Shmakov
Oct 31, 2017, 3:05:45 PM10/31/17
to
>>>>> David W Hodgins <dwho...@nomail.afraid.org> writes:
For no good reason, I'll still try to explain it myself.
There's a summary at the bottom, BTW.]
If I'm to hazard a guess, the NNTP protocol makes it easier
(bandwidth-wise) to gather addresses from the header (via the
HEAD command) than from the article as a whole. It's easier
still to retrieve the contents of certain headers -- including
From: and Message-ID: -- using XOVER, which may make them more
vulnerable to harvesting than the other parts of the article.
(And which may also explain why there're occasionally attempts
to deliver mail to Message-ID: identifiers like they were email
addresses.)
Now, other than sending spam, the From: address may be used to
send a Usenet participant an email. In my experience, however,
that rarely happens. As such, From: in Usenet currently serves
as the means to identify a poster -- not to start an email
conversation. Hence, there's little (if any) reason to use for
it an address of a mailbox that one's going to actually read.
From here, we can consider several alternatives.
First of all, AFAICT, there's a consensus that using someone's
else address in From: -- or even just a domain you don't have
permission to use for that purpose -- is plainly harmful, as
that opens that third party to network abuse. In particular,
RFC 5322 (3.6.2) reads:
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. [...]
Another option is to use an address that's invalid and will
remain invalid for the foreseeable future. An address with
a domain part ending in the standard (RFC 2606) reserved
".invalid" TLD name is just such a domain, and while the domain
was initially (1999) intended to be used only in documentation,
its use is expressly allowed by RFC 5537 (3.4):
Contrary to [RFC5322], which implies that the mailbox or mailboxes in
the From header field should be that of the poster or posters, a
poster who does not, for whatever reason, wish to use his own mailbox
MAY use any mailbox ending in the top-level domain ".invalid"
[RFC2606].
Unless the MTA (MSA) is badly misconfigured, any mail to such an
address will be rejected immediately, and the user trying to
send it will be notified of the issue, making it possible for
him or her to try other means to contact the article's author.
One another choice is to use a "temporary" email, typically
valid for several days or weeks. It has the convenience that
the article's author can readily be contacted when the
discussion is still active, yet the address would be more or
less useless for long-term abuse.
It's also possible to use an address associated with a
"spamtrap," which has the advantage of automatically marking
spam sources for other users. The obvious downside (and one
associated with spamtraps and similar measures in general) is
that a honest mistake by a single user of a given MTA may lead
to an automatic blacklising of that same MTA, effectively
resulting in a DoS (however short-term) for all its users.
Finally, it's also possible to use a valid address pointing to a
mailbox that simply is never read, and perhaps does not even
have any actual storage (as in: redirected to /dev/null.)
AFAICT, such use would be in line with RFC 5322 (3.4):
A mailbox receives mail. It is a conceptual entity that does not
necessarily pertain to file storage. For example, some sites may
choose to print mail on a printer and deliver the output to the
addressee's desk.
Also, the use of such addresses is common in email proper, for
instance they're used to deliver important information to
clients of many Internet services (say, ToU changes, low balance
notifications, etc.)
A summary follows.
Use of someone's else address or domain:
* may be harmful to that third party;
* expressly disallowed ("SHOULD NOT") by RFC 5322 (3.4);
* may fail to provide clear indication that the recipient cannot
be reached.
Use of an ".invalid" address:
* expressly allowed ("MAY") by RFC 5537 (3.4);
* common Usenet practice;
* provides clear indication that the recipient cannot be reached.
Use of a spamtrap address:
* may fail to provide clear indication that the recipient cannot
be reached.
* may result in an inadvertent DoS due to a honest mistake on
the part of the user trying to contact the article's author
via email.
Use of a temporary address:
* no obvious issues with Internet standards compliance;
* messages are either delivered, or there's a clear indication
that the recipient can no longer be reached.
Use of a /dev/null address:
* no obvious issues with Internet standards compliance;
* no indication that the recipient cannot be reached that way.
--
FSF associate member #7257 http://am-1.org/~ivan/
>>>>> On Sat, 28 Oct 2017 23:36:27 -0400, Thomas 'PointedEars' Lahn wrote:
>>>>> David W. Hodgins wrote:
>>> Change dwho...@nomail.afraid.org to davidw...@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
>>>>> David W. Hodgins wrote:
>>> Change dwho...@nomail.afraid.org to davidw...@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
> 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.
[I'm pretty sure that there's a FAQ or dozen that cover this.
> 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.
For no good reason, I'll still try to explain it myself.
There's a summary at the bottom, BTW.]
If I'm to hazard a guess, the NNTP protocol makes it easier
(bandwidth-wise) to gather addresses from the header (via the
HEAD command) than from the article as a whole. It's easier
still to retrieve the contents of certain headers -- including
From: and Message-ID: -- using XOVER, which may make them more
vulnerable to harvesting than the other parts of the article.
(And which may also explain why there're occasionally attempts
to deliver mail to Message-ID: identifiers like they were email
addresses.)
Now, other than sending spam, the From: address may be used to
send a Usenet participant an email. In my experience, however,
that rarely happens. As such, From: in Usenet currently serves
as the means to identify a poster -- not to start an email
conversation. Hence, there's little (if any) reason to use for
it an address of a mailbox that one's going to actually read.
From here, we can consider several alternatives.
First of all, AFAICT, there's a consensus that using someone's
else address in From: -- or even just a domain you don't have
permission to use for that purpose -- is plainly harmful, as
that opens that third party to network abuse. In particular,
RFC 5322 (3.6.2) reads:
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. [...]
Another option is to use an address that's invalid and will
remain invalid for the foreseeable future. An address with
a domain part ending in the standard (RFC 2606) reserved
".invalid" TLD name is just such a domain, and while the domain
was initially (1999) intended to be used only in documentation,
its use is expressly allowed by RFC 5537 (3.4):
Contrary to [RFC5322], which implies that the mailbox or mailboxes in
the From header field should be that of the poster or posters, a
poster who does not, for whatever reason, wish to use his own mailbox
MAY use any mailbox ending in the top-level domain ".invalid"
[RFC2606].
Unless the MTA (MSA) is badly misconfigured, any mail to such an
address will be rejected immediately, and the user trying to
send it will be notified of the issue, making it possible for
him or her to try other means to contact the article's author.
One another choice is to use a "temporary" email, typically
valid for several days or weeks. It has the convenience that
the article's author can readily be contacted when the
discussion is still active, yet the address would be more or
less useless for long-term abuse.
It's also possible to use an address associated with a
"spamtrap," which has the advantage of automatically marking
spam sources for other users. The obvious downside (and one
associated with spamtraps and similar measures in general) is
that a honest mistake by a single user of a given MTA may lead
to an automatic blacklising of that same MTA, effectively
resulting in a DoS (however short-term) for all its users.
Finally, it's also possible to use a valid address pointing to a
mailbox that simply is never read, and perhaps does not even
have any actual storage (as in: redirected to /dev/null.)
AFAICT, such use would be in line with RFC 5322 (3.4):
A mailbox receives mail. It is a conceptual entity that does not
necessarily pertain to file storage. For example, some sites may
choose to print mail on a printer and deliver the output to the
addressee's desk.
Also, the use of such addresses is common in email proper, for
instance they're used to deliver important information to
clients of many Internet services (say, ToU changes, low balance
notifications, etc.)
A summary follows.
Use of someone's else address or domain:
* may be harmful to that third party;
* expressly disallowed ("SHOULD NOT") by RFC 5322 (3.4);
* may fail to provide clear indication that the recipient cannot
be reached.
Use of an ".invalid" address:
* expressly allowed ("MAY") by RFC 5537 (3.4);
* common Usenet practice;
* provides clear indication that the recipient cannot be reached.
Use of a spamtrap address:
* may fail to provide clear indication that the recipient cannot
be reached.
* may result in an inadvertent DoS due to a honest mistake on
the part of the user trying to contact the article's author
via email.
Use of a temporary address:
* no obvious issues with Internet standards compliance;
* messages are either delivered, or there's a clear indication
that the recipient can no longer be reached.
Use of a /dev/null address:
* no obvious issues with Internet standards compliance;
* no indication that the recipient cannot be reached that way.
--
FSF associate member #7257 http://am-1.org/~ivan/
Bit Twister
Oct 31, 2017, 7:16:19 PM10/31/17
to
On Tue, 31 Oct 2017 19:05:40 +0000, Ivan Shmakov wrote:
>
> Finally, it's also possible to use a valid address pointing to a
> mailbox that simply is never read, and perhaps does not even
> have any actual storage (as in: redirected to /dev/null.)
Then there is something like mouse-potato.com which I use.
>
> Finally, it's also possible to use a valid address pointing to a
> mailbox that simply is never read, and perhaps does not even
> have any actual storage (as in: redirected to /dev/null.)
I contacted the domain owner and was told feel free to use it.
Go ahead check the ip address via
ping -c1 -w1 mouse-potato.com
Ian Zimmerman
Nov 1, 2017, 11:29:25 AM11/1/17
to
On 2017-10-31 19:05, Ivan Shmakov wrote:
> One another choice is to use a "temporary" email, typically valid
> for several days or weeks. It has the convenience that the article's
> author can readily be contacted when the discussion is still active,
> yet the address would be more or less useless for long-term abuse.
How is this commonly implemented? Is it the domain or local-part that
> One another choice is to use a "temporary" email, typically valid
> for several days or weeks. It has the convenience that the article's
> author can readily be contacted when the discussion is still active,
> yet the address would be more or less useless for long-term abuse.
becomes invalid?
If it's the domain, it means periodic change to DNS configuration is
required, including the associated nuisances such as restarting the name
server.
If it's the local-part, the MX host will still get the spam, even if
just to deliver it to the black hole.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.
Thomas 'PointedEars' Lahn
Nov 1, 2017, 11:45:29 AM11/1/17
to
for the domain mouse-potato.com) is irrelevant, even though it constitutes
network abuse[1], and the domain is already contained in an RFC² blacklist
(includes the blacklists of the former RFC Ignorant) for several reasons:
<http://rfc-clueless.org/lookup/mouse-potato.com>
For e-mail, the output of one of
dig mouse-potato.com MX
host -t MX mouse-potato.com
nslookup -querytype=MX mouse-potato.com
is relevant instead:
<https://en.wikipedia.org/wiki/List_of_DNS_record_types>
AISB:
,----
| $ chkmadd -v BitTw...@mouse-potato.com
| chkmadd 0.1.6.2014122021a -- (C) 2003-2014 Thomas Lahn <Point...@web.de>
| Distributed under the terms of the GNU General Public License (GPL).
| See COPYING file or <http://www.fsf.org/copyleft/gpl.html> for details.
| Report bugs to <chk...@PointedEars.de>.
|
| Using chkmadd server pe.de
|
| chkmadd 0.1.5.2006061200 -- (C) 2003-2006 Thomas Lahn <Point...@web.de>
| Distributed under the terms of the GNU General Public License (GPL).
| See COPYING file or <http://www.fsf.org/copyleft/gpl.html> for details.
| Report bugs to <chk...@PointedEars.de>.
|
| E-mail address(es) to check:
| BitTw...@mouse-potato.com
|
| Verifying <BitTw...@mouse-potato.com>...
| Mail exchanger(s) for mouse-potato.com:
| mouse-potato.com mail is handled by 10 mail.mouse-potato.com.
|
| chkmadd.exp 0.1.7.20120303
| Copyright (C) 2004-2012 Thomas Lahn <Point...@web.de>
| Distributed under the terms of the GNU General Public License (GPL).
| See COPYING file or <http://www.fsf.org/copyleft/gpl.html> for details.
| Report bugs to <chk...@PointedEars.de>.
|
| spawn telnet -- mail.mouse-potato.com smtp
| Trying 127.0.0.1...
| Connected to mail.mouse-potato.com.
| Escape character is '^]'.
| 220 […] ESMTP Postfix (Debian/GNU)
| VRFY BitTw...@mouse-potato.com
| 252 2.0.0 BitTw...@mouse-potato.com
| MAIL FROM:<BitTw...@mouse-potato.com>
| 503 5.5.1 Error: send HELO/EHLO first
| HELO […]
| 250 […]
| MAIL FROM:<BitTw...@mouse-potato.com>
| 250 2.1.0 Ok
| RCPT TO:<BitTw...@mouse-potato.com>
| 250 2.1.5 Ok
| RSET
| 250 2.0.0 Ok
| QUIT
| 221 2.0.0 Bye
| Connection closed by foreign host.
|
| <BitTw...@mouse-potato.com>
|
| is most certainly an e-mail address.
`----
However, that this is not actually a mailbox that you read, is anti-social.
Thus, after your postings had already been scored down due to your lack of
real name, and your demonstration of repeated cluelessness, your "address"
has now been added to my killfile.
*PLONK*
F’up2 poster
______
[1] <https://en.wikipedia.org/wiki/Reserved_IP_addresses> pp.
Thomas 'PointedEars' Lahn
Nov 1, 2017, 12:08:15 PM11/1/17
to
Ian Zimmerman wrote in <news:comp.unix.shell>:
> On 2017-10-31 19:05, Ivan Shmakov wrote:
>> One another choice is to use a "temporary" email, typically valid
>> for several days or weeks. It has the convenience that the article's
>> author can readily be contacted when the discussion is still active,
>> yet the address would be more or less useless for long-term abuse.
>
> How is this commonly implemented? Is it the domain or local-part that
> becomes invalid?
local-part (AFAIK). But it would be better (and easier) if it were just
spam-filtered, which is entirely possible and even built into many *free*
Web mail accounts these days.
Usenet is not a real-time communications medium, and it is not a good idea
if the author of a posting, that may be only found in news archives, cannot
be contacted/identified anymore after a time that *they* had once
determined. Archives also do not necessarily keep the Reply-To header field
(easily accessible), so it is a lame excuse to post with a valid Reply-To
but an invalid From.
> If it's the domain, it means periodic change to DNS configuration is
> required, including the associated nuisances such as restarting the name
> server.
Which is why this is not done (AFAIK).
> If it's the local-part, the MX host will still get the spam, even if
> just to deliver it to the black hole.
If after a time there is no mailbox with that name, then the *receiving* MX
will have to deal with the sending MX’s *request*, but will deny it at the
RCPT TO command (as I have showed), so it will _not_ see the spam message.
IOW, the e-mail *bounces*; it is *reported* as *not deliverable* to the
sender by the *sending* MX in a corresponding e-mail.
The “black hole” approach is *another* approach, where the mailbox is
(claimed to be) existing, and the message is *accepted* (but thrown away),
and does *not* bounce.
All approaches that are not using spam filters only (and optionally
honeypots), are *at least* *anti-social*.
Common spam-filtered e-mail accounts usually use blacklisting against known
spammers or spam-supporting providers, and greylisting for the rest: The
first attempt at sending the message and subsequent attempts until after
some time are rejected, subsequent attempts by the same sender after that
time are accepted. Greylisting may be limited to specific sending MXs.
<http://www.interhack.net/pubs/munging-harmful/>
F’up2 <news:news.admin.net-abuse.misc>
> On 2017-10-31 19:05, Ivan Shmakov wrote:
>> One another choice is to use a "temporary" email, typically valid
>> for several days or weeks. It has the convenience that the article's
>> author can readily be contacted when the discussion is still active,
>> yet the address would be more or less useless for long-term abuse.
>
> How is this commonly implemented? Is it the domain or local-part that
> becomes invalid?
spam-filtered, which is entirely possible and even built into many *free*
Web mail accounts these days.
Usenet is not a real-time communications medium, and it is not a good idea
if the author of a posting, that may be only found in news archives, cannot
be contacted/identified anymore after a time that *they* had once
determined. Archives also do not necessarily keep the Reply-To header field
(easily accessible), so it is a lame excuse to post with a valid Reply-To
but an invalid From.
> If it's the domain, it means periodic change to DNS configuration is
> required, including the associated nuisances such as restarting the name
> server.
> If it's the local-part, the MX host will still get the spam, even if
> just to deliver it to the black hole.
will have to deal with the sending MX’s *request*, but will deny it at the
RCPT TO command (as I have showed), so it will _not_ see the spam message.
IOW, the e-mail *bounces*; it is *reported* as *not deliverable* to the
sender by the *sending* MX in a corresponding e-mail.
The “black hole” approach is *another* approach, where the mailbox is
(claimed to be) existing, and the message is *accepted* (but thrown away),
and does *not* bounce.
All approaches that are not using spam filters only (and optionally
honeypots), are *at least* *anti-social*.
Common spam-filtered e-mail accounts usually use blacklisting against known
spammers or spam-supporting providers, and greylisting for the rest: The
first attempt at sending the message and subsequent attempts until after
some time are rejected, subsequent attempts by the same sender after that
time are accepted. Greylisting may be limited to specific sending MXs.
<http://www.interhack.net/pubs/munging-harmful/>
F’up2 <news:news.admin.net-abuse.misc>
Kaz Kylheku
Nov 1, 2017, 2:06:28 PM11/1/17
to
On 2017-11-01, Ian Zimmerman <i...@no-use.mooo.com> wrote:
> On 2017-10-31 19:05, Ivan Shmakov wrote:
>
>> One another choice is to use a "temporary" email, typically valid
>> for several days or weeks. It has the convenience that the article's
>> author can readily be contacted when the discussion is still active,
>> yet the address would be more or less useless for long-term abuse.
>
> How is this commonly implemented? Is it the domain or local-part that
> becomes invalid?
>
> If it's the domain, it means periodic change to DNS configuration is
> required, including the associated nuisances such as restarting the name
> server.
I wrote a throw-away mail alias system called Tamarind.
> On 2017-10-31 19:05, Ivan Shmakov wrote:
>
>> One another choice is to use a "temporary" email, typically valid
>> for several days or weeks. It has the convenience that the article's
>> author can readily be contacted when the discussion is still active,
>> yet the address would be more or less useless for long-term abuse.
>
> How is this commonly implemented? Is it the domain or local-part that
> becomes invalid?
>
> If it's the domain, it means periodic change to DNS configuration is
> required, including the associated nuisances such as restarting the name
> server.
The source is here:
http://www.kylheku.com/cgit/tamarind/tree/
It's written in TXR/TXR Lisp.
It runs as a CGI service on my web server, providing a UI
for managing throw-away e-mail aliases.
The README file provides an overview and installation notes
geared toward Apache + Exim running on Debian.
Authentication in the Web UI can use IMAP, or talk to a SASL auth daemon
directly (saslauthd).
> If it's the local-part, the MX host will still get the spam, even if
> just to deliver it to the black hole.
get the spam. :)
The MX host will still get TCP connections; but it can reject
them; i.e. do an SMTP non-delivery bounce.
If your idea of success in fighting spam is my "MX host never gets a TCP
connection from a spammer", I'm afraid that is not very realistic.
Bit Twister
Nov 1, 2017, 3:34:10 PM11/1/17
to
On Wed, 01 Nov 2017 16:45:24 +0100, Thomas 'PointedEars' Lahn wrote:
> Bit Twister wrote:
>
>> On Tue, 31 Oct 2017 19:05:40 +0000, Ivan Shmakov wrote:
>> Then there is something like mouse-potato.com which I use.
>> I contacted the domain owner and was told feel free to use it.
>>
>> Go ahead check the ip address via
>> ping -c1 -w1 mouse-potato.com
>
> The IP address that is displayed by this command (127.0.0.1, the “A” record
> for the domain mouse-potato.com) is irrelevant,
It is relevant to showing where an email would be routed.
> Bit Twister wrote:
>
>> On Tue, 31 Oct 2017 19:05:40 +0000, Ivan Shmakov wrote:
>> Then there is something like mouse-potato.com which I use.
>> I contacted the domain owner and was told feel free to use it.
>>
>> Go ahead check the ip address via
>> ping -c1 -w1 mouse-potato.com
>
> The IP address that is displayed by this command (127.0.0.1, the “A” record
> for the domain mouse-potato.com) is irrelevant,
> even though it constitutes network abuse[1],
from a node to 127.0.0.1 will be routed to the node's loop back
ip. and would not make it to the router let alone the network.
> Thus, after your postings had already been scored down due to your lack of
> real name, and your demonstration of repeated cluelessness, your "address"
> has now been added to my killfile.
>
> *PLONK*
tiny bit.
Ian Zimmerman
Nov 2, 2017, 12:18:23 PM11/2/17
to
On 2017-11-01 18:06, Kaz Kylheku wrote:
> I wrote a throw-away mail alias system called Tamarind.
>
> The source is here:
>
> http://www.kylheku.com/cgit/tamarind/tree/
>
> It's written in TXR/TXR Lisp.
Very interesting, I'll take a look, even though I don't plan installing
> I wrote a throw-away mail alias system called Tamarind.
>
> The source is here:
>
> http://www.kylheku.com/cgit/tamarind/tree/
>
> It's written in TXR/TXR Lisp.
TXR soon ;-)
> > If it's the local-part, the MX host will still get the spam, even if
> > just to deliver it to the black hole.
>
> By that reasoning, if it's the domain part, the DNS system will still
> get the spam. :)
unlike MTA logs. Another is DNS adds much less to my consumed bandwidth
which I have to pay for.
> The MX host will still get TCP connections; but it can reject
> them; i.e. do an SMTP non-delivery bounce.
> If your idea of success in fighting spam is my "MX host never gets a
> TCP connection from a spammer", I'm afraid that is not very realistic.
Kaz Kylheku
Nov 2, 2017, 1:02:03 PM11/2/17
to
On 2017-11-02, Ian Zimmerman <i...@no-use.mooo.com> wrote:
> On 2017-11-01 18:06, Kaz Kylheku wrote:
>
>> I wrote a throw-away mail alias system called Tamarind.
>>
>> The source is here:
>>
>> http://www.kylheku.com/cgit/tamarind/tree/
>>
>> It's written in TXR/TXR Lisp.
>
> Very interesting, I'll take a look, even though I don't plan installing
> TXR soon ;-)
>
>> > If it's the local-part, the MX host will still get the spam, even if
>> > just to deliver it to the black hole.
>>
>> By that reasoning, if it's the domain part, the DNS system will still
>> get the spam. :)
>
> One difference is that I almost never have to pore over named logs;
> unlike MTA logs.
I don't look through my MTA logs (or, very rarely so, to investigate
> On 2017-11-01 18:06, Kaz Kylheku wrote:
>
>> I wrote a throw-away mail alias system called Tamarind.
>>
>> The source is here:
>>
>> http://www.kylheku.com/cgit/tamarind/tree/
>>
>> It's written in TXR/TXR Lisp.
>
> Very interesting, I'll take a look, even though I don't plan installing
> TXR soon ;-)
>
>> > If it's the local-part, the MX host will still get the spam, even if
>> > just to deliver it to the black hole.
>>
>> By that reasoning, if it's the domain part, the DNS system will still
>> get the spam. :)
>
> One difference is that I almost never have to pore over named logs;
> unlike MTA logs.
some very specific problem). I have a script monitoring the log to
dynamically ban IP addresses (similar to "fail2ban").
If a throwaway mail alias is disabled by the user, any rejection of
mails for that alias is definitely not a false positive; there is no
reason to look for evidence of it any logs.
> Another is DNS adds much less to my consumed bandwidth
> which I have to pay for.
unresolveable address isn't that expensive. It occurs when the remote
host issues a "RCPT to:", before "DATA". None of the mail bulk has
been received; just a little bit of SMTP chat has taken place.
The DNS thing is simply not practical for most people: the "little guy"
running his own mailing list on a dynamic DNS home setup.
I have one domain. I can log in to the domain registering company and
manage a few host names through a manual web UI. Actually, that is not
relevant, because I think I can have only one MX record!
I have close to sixty throwaway e-mail aliases currently.
When I create one, it *instantly* goes live; I can do that just
before finishing some transaction with an e-commerce site,
and the alias will get their confirmation e-mail.
If I could have sixty different domains and MX records, chances
are that they would not become instantly live, even if there was an API
from the DNS provider to create them.
Ian Zimmerman
Nov 3, 2017, 2:28:08 PM11/3/17
to
On 2017-11-02 17:01, Kaz Kylheku wrote:
> > One difference is that I almost never have to pore over named logs;
> > unlike MTA logs.
>
> I don't look through my MTA logs (or, very rarely so, to investigate
> some very specific problem). I have a script monitoring the log to
> dynamically ban IP addresses (similar to "fail2ban").
>
> If a throwaway mail alias is disabled by the user, any rejection of
> mails for that alias is definitely not a false positive; there is no
> reason to look for evidence of it any logs.
The former case was my point, not the latter. When I do have to look at
> > One difference is that I almost never have to pore over named logs;
> > unlike MTA logs.
>
> I don't look through my MTA logs (or, very rarely so, to investigate
> some very specific problem). I have a script monitoring the log to
> dynamically ban IP addresses (similar to "fail2ban").
>
> If a throwaway mail alias is disabled by the user, any rejection of
> mails for that alias is definitely not a false positive; there is no
> reason to look for evidence of it any logs.
the log, the presence of all the spam connections will make it very hard
to read.
> I have one domain. I can log in to the domain registering company and
> manage a few host names through a manual web UI. Actually, that is not
> relevant, because I think I can have only one MX record!
think you can still only have one MX per domain.
Thomas 'PointedEars' Lahn
Nov 10, 2017, 5:04:55 PM11/10/17
to
Kaz Kylheku wrote:
> […] I think I can have only one MX record!
You are wrong. In fact, as with some other DNS records of the same type,
one certainly _can_ have multiple MX records (optionally with different
priority value) for the same domain; aside from load balancing, they are
used for avoiding spam.
[It is considered both too costly and too obvious for spammers to try
all MXes of a domain (duplicate e-mails would be a clear sign of spam),
especially as waiting times may be incurred. Which is why chkmadd(1),
which never actually sends e-mail, tries *all* MX records before it
considers an an e-mail-address-like string not an e-mail address.]
> […] I think I can have only one MX record!
You are wrong. In fact, as with some other DNS records of the same type,
one certainly _can_ have multiple MX records (optionally with different
priority value) for the same domain; aside from load balancing, they are
used for avoiding spam.
[It is considered both too costly and too obvious for spammers to try
all MXes of a domain (duplicate e-mails would be a clear sign of spam),
especially as waiting times may be incurred. Which is why chkmadd(1),
which never actually sends e-mail, tries *all* MX records before it
considers an an e-mail-address-like string not an e-mail address.]
0 new messages