Re: [S-mailx] ERROR prompt
Hi Stephen, > Well, the "problem", such as it is, is that I am getting the error > marker, but there is no entry in the error log. That should be a > "can't happen" - the error marker is only supposed to appear when > something is added to the log. But it appears to be happening. Could a debugger help provide a stack backtrace from the function which modifies the variable which later triggers the ‘there were some errors’ message? Perhaps Steffen could point you to the place to set the breakpoint. -- Cheers, Ralph.
Re: [S-mailx] viewing a single email file
Hi Viktor, A email in a file in a Maildir directory has the same format as a file in an MH mail folder so you may want to look for mail user-agents that can handle MH folders, e.g. ‘mhshow -file foo’. IIRC, GNU mailutils can also cope. -- Cheers, Ralph.
[S-mailx] 14.9.14: Entered Headers Echod Back.
Hi, I've just upgraded package s-nail on Arch Linux from 14.9.13-2 to 14.9.14-1. ‘mail $LOGNAME’ still prompts for the Subject field, good, but then echoes it back along with the To field. Why? 1 $ mail $LOGNAME 2 Subject: foo 3 To: ralph 4 Subject: foo 5 bar 6 . 7 $ I type ‘foo’ on line 2, and lines 5 and 6. I do not expect lines 3 and 4 to be printed. -- Cheers, Ralph.
Re: [S-mailx] Gmail not able to decode the encoded "Subject:" field value
Hi Martin, > ['origin=3DDebian,codename=3Dstretch,label=3DDebian-Se=curity'] ... > charset.body_encoding = email.charset.QP ... > What might cause this? The quoted-printable encoding can be undone with `recode /qp'. -- Cheers, Ralph.
Re: [S-mailx] Fwd: false positive
Hi Steffen, > Be liberal in what you expect but strict in what you produce Postel's Law is fitting for the 1970s. Now it just causes problems. That experience shows that there are negative long-term consequences to interoperability if an implementation applies Postel's advice. Correcting the problems caused by divergent behavior in implementations can be difficult or impossible. ― https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 -- Cheers, Ralph.
Re: [S-mailx] Fwd: false positive
Hi Steffen, > I guess to satisfy this service i have to reinstantiate the MX record > that has been there before Russell Bell started sending to the > resolved CNAME instead of the CNAME itself. But you don't have to satisfy this broken service that knowingly and wilfully violates RFCs and yet, it seems, does not lobby the IETF for a new RFC to amend the widely followed policy. To bow to their diktat lessens the value of all RFCs. The mailing list works fine for those of us following the RFC. -- Cheers, Ralph.
Re: [S-mailx] Fwd: false positive
##- Please type your reply above this line -## You are registered as a CC on this support request (15233). Reply to this email to add a comment to the request. *Ralph Corderoy* Mar 27, 6:32 PM EDT Hi Rachel, Thanks for your responses, and trying to keep the mailing list in the loop. I appreciate it takes time on your side and we're in no hurry. I'm more than happy to just be in contact with someone that knows how to have the issue examined, whatever the outcome. I've dealt with quite a few companies over the years in trying to report possible problems and NeverBounce is doing well in comparison with many of them! -- Cheers, Ralph. *Rachel* (NeverBounce) Mar 27, 5:05 PM EDT Hello, Thank you for your patience as our team has requested some additional time to review this matter. Once the team has followed up, I will be sure to send any and all information obtained your way. I do apologize if this ticketing system does not CC the appropriate team members (this has happened in the past). I have included them in this send. Thank you again and have a wonderful day! All the best, Rachel Attachment(s) Screen Shot 2019-03-27 at 2.05.09 PM.png <https://neverbounce.zendesk.com/attachments/token/PBgpCAFiLGFxU29YzoWTlqa76/?name=Screen+Shot+2019-03-27+at+2.05.09+PM.png> *Rachel* (NeverBounce) Mar 27, 9:26 AM EDT Request #15234 <https://neverbounce.zendesk.com/hc/requests/15234> "Fwd: [S-mailx] Fwd: false positive" was closed and merged into this request. Last comment in request #15234 <https://neverbounce.zendesk.com/hc/requests/15234>: Hello! Please forward it to your engineers. Maybe tell them to reread RFC 5321. Thank you. - Forwarded message from Ralph Corderoy ra...@inputplus.co.uk - Date: Wed, 27 Mar 2019 10:24:08 + From: Ralph Corderoy ra...@inputplus.co.uk Subject: Re: [S-mailx] Fwd: false positive To: Rachel supp...@neverbounce.com Cc: SZÉPE Viktor vik...@szepe.net, s-mailx@lists.sdaoden.eu Hi Rachel, There's discussion on the s-mailx@lists.sdaoden.eu mailing list about a support reply from neverbounce.com. (Please keep s-mailx@lists.sdaoden.eu CC'd.) From: "Rachel (NeverBounce)" supp...@neverbounce.com To: Viktor Szépe vik...@szepe.net Subject: Re: false positive Date: Tue, 26 Mar 2019 19:40:15 +0100 ... We did have the chance to review the email in question, and it appears the domain is not configured properly, which is why the email is being marked as invalid. For delivering s-mailx@lists.sdaoden.eu, the DNS entries are $ dig +nocomment @8.8.8.8 lists.sdaoden.eu. ; <<>> DiG 9.13.7 <<>> +nocomment @8.8.8.8 lists.sdaoden.eu. ; (1 server found) ;; global options: +cmd ;lists.sdaoden.eu. IN A lists.sdaoden.eu. 14399 IN CNAME sdaoden.eu. sdaoden.eu. 14399 IN A 217.144.132.164 ;; Query time: 52 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Mar 27 10:12:48 GMT 2019 ;; MSG SIZE rcvd: 75 $ RFC 5321, Simple Mail Transfer Protocol, says https://tools.ietf.org/html/rfc5321#section-5 The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. lists.sdaoden.eu has no MX record, but does have a CNAME for sdaoden.eu and so that should be then treated as the initial name. sdaoden.eu has no MX record. This is also covered in that section of RFC 5321: If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. Thus sdaoden.eu is to be treated as an MX RR record. A lookup on that gives the A record for 217.144.132.164. That IP address is the one to connect to. Perhaps NeverBounce are getting confused with this part: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. So an MX RR's value can't resolve to a CNAME, but the implicit one above doesn't, it gives an A. It's perfectly valid, and explicitly covered above, for the lookup desiring an MX to find a CNAME. Please can you re-appraise NeverBounce's RFC compliance. Thanks. Steffen, don't change you DNS configuration. It's correct and helps flush out problems like this that may be affecting NeverBounce's treatment of other addresses. -- Cheers, Ralph. - End forwarded message - SZÉPE Viktor, webes alkalmazás üzemeltetés / Running your application https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md ~~~ ügyelet/hotline: +36-20-4242498 s..
Re: [S-mailx] Fwd: false positive
Hi Rachel, There's discussion on the s-mailx@lists.sdaoden.eu mailing list about a support reply from neverbounce.com. (Please keep s-mailx@lists.sdaoden.eu CC'd.) > > > From: "Rachel (NeverBounce)" > > > To: Viktor Szépe > > > Subject: Re: false positive > > > Date: Tue, 26 Mar 2019 19:40:15 +0100 ... > > > We did have the chance to review the email in question, and it > > > appears the domain is not configured properly, which is why the > > > email is being marked as invalid. For delivering s-mailx@lists.sdaoden.eu, the DNS entries are $ dig +nocomment @8.8.8.8 lists.sdaoden.eu. ; <<>> DiG 9.13.7 <<>> +nocomment @8.8.8.8 lists.sdaoden.eu. ; (1 server found) ;; global options: +cmd ;lists.sdaoden.eu. IN A lists.sdaoden.eu. 14399 IN CNAME sdaoden.eu. sdaoden.eu. 14399 IN A 217.144.132.164 ;; Query time: 52 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Mar 27 10:12:48 GMT 2019 ;; MSG SIZE rcvd: 75 $ RFC 5321, Simple Mail Transfer Protocol, says https://tools.ietf.org/html/rfc5321#section-5 The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. lists.sdaoden.eu has no MX record, but does have a CNAME for sdaoden.eu and so that should be then treated as the initial name. sdaoden.eu has no MX record. This is also covered in that section of RFC 5321: If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. Thus sdaoden.eu is to be treated as an MX RR record. A lookup on that gives the A record for 217.144.132.164. That IP address is the one to connect to. Perhaps NeverBounce are getting confused with this part: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. So an MX RR's value can't resolve to a CNAME, but the implicit one above doesn't, it gives an A. It's perfectly valid, and explicitly covered above, for the lookup desiring an MX to find a CNAME. Please can you re-appraise NeverBounce's RFC compliance. Thanks. Steffen, don't change you DNS configuration. It's correct and helps flush out problems like this that may be affecting NeverBounce's treatment of other addresses. -- Cheers, Ralph.
Re: [S-mailx] Not a joke: how to avoid 42
Hi Steffen, > \if [ $s == 42 ] >\echo 'Second 42, sleeping a second' >\sleep 1 >\xcall on-compose-leave > \end > \if [ $m == 42 ] >\vput vexpr res - 10#$s 60 >\vput vexpr res - 0 $res >\echo 'Minute 42, sleeping '$res' seconds' >\sleep $res >\xcall on-compose-leave > \end Strictly speaking, these need to loop as the sleep may last longer than planned. Even then, there's a race condition between the test and the execution. I think some timezones can be 30 minutes off the hour so it may still be 42 minutes from the recipient's point of view? Is avoiding the 42nd ordinal day of the year left as an exercise for the reader? :-) -- Cheers, Ralph.
Re: [S-mailx] messages to s-mailx list; date format
Hi SZÉPE, > > If not MX for foo.com exists then foo.com's port 25 is contacted > > directly, so an MX for foo.com defined as foo.com seems unnecessary. > > Excuse me, I object! > If you do internet mailing in the 21st century you *should* add an MX > record (and use SPF, DKIM and DMARC) I assume that's just your subjective preference rather than an RFC, or similar, recommendation? https://en.wikipedia.org/wiki/Mx_record#History_of_fallback_to_address_record says RFC 5321 still states the fallback. I don't recall that using A instead of MX stops SPF, etc. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] messages to s-mailx list; date format
Hi Steffen, > Then problem on my side, i should add an MX entry for > lists.sdaoden.eu which points to lists.sdaoden.eu not sdaoden.eu. > My knowledge of DNS is a bit rusty. Mine too. $ dig +nocomment lists.sdaoden.eu. mx ... lists.sdaoden.eu. 14312 IN CNAME sdaoden.eu. sdaoden.eu. 14312 IN MX 10 sdaoden.eu. sdaoden.eu. 14312 IN A 217.144.132.164 If not MX for foo.com exists then foo.com's port 25 is contacted directly, so an MX for foo.com defined as foo.com seems unnecessary. If lists.sdaoden.eu should remain as is and not be translated to sdaoden.eu then I'd suggest making it a A record for the same IP address. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] Proper formatting of date for From lines
Hi russell, > I just read asctime's man page and looked at time.h. When > they describe day-of-month they use them unpadded and mention nothing > about padding. What is the standard to which you refer? When I run > 'date', it returns unpadded day-of-month. There's POSIX, http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html, that might always be available as a local man page, e.g. asctime(3p). -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] EOF in Type-Ahead Becomes NUL.
Hi Steffen, > > On running this command, I type the four characters ‘bar\n’, and > > then Ctrl-D, my TTY's EOF character, before the three seconds have > > elapsed. It appears thus, with ‘␣’ being the cursor. > > > > $ sleep 3; mail -s foo $LOGNAME > > bar > > ␣ > > > > As mail runs, it changes to > > > > $ sleep 3; mail -s foo $LOGNAME > > bar > > bar > > ^@␣ > > I presume you have no*ignoreeof* and no*asksend* set. $ cat ~/.mailrc unset askcc unset asksend set encoding=8bit set sendcharsets=utf-8 set dot set sendwait set line-editor-disable set stealthmua=noagent $ > I wonder whether you would be helped with a shell alias that sets > *line-editor-disable* in addition, it would release the system from > quite some unnecessary burdens in this case. I see it is set. > > Despite my EOF, no shell prompt appears so I type another EOF. And > > then two more. Only then does mail exit and my $PS1 appear. > > Yes, in raw terminal mode VEOF has no meaning actually. Agreed. But as a user I shouldn't need to know that it's switched to raw mode. mail(1) used to be happy taking the TTY's EOF. > > The email that arrives has the null byte suggested by the ‘^@’. > > If you input a NUL byte we will not mangle you. Good. I did not input a NUL. As I said above, it was `bar\n' and Ctrl-D. And raw mode doesn't turn Ctrl-D into NUL. Here, I type `abc' Ctrl-D `def', wait for the `.', then Enter and Ctrl-D. $ (trap '' TTOU; old=`stty -g`; stty raw; sleep 3; stty $old; printf .) & od -c abc^Ddef. 000 a b c 004 d e f \n 010 $ The Ctrl-D correctly appears as EOT, as I'd expect in raw mode. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
[S-mailx] EOF in Type-Ahead Becomes NUL.
Hi, s-nail 14.9.11-1 on Arch Linux. On running this command, I type the four characters ‘bar\n’, and then Ctrl-D, my TTY's EOF character, before the three seconds have elapsed. It appears thus, with ‘␣’ being the cursor. $ sleep 3; mail -s foo $LOGNAME bar ␣ As mail runs, it changes to $ sleep 3; mail -s foo $LOGNAME bar bar ^@␣ Despite my EOF, no shell prompt appears so I type another EOF. And then two more. Only then does mail exit and my $PS1 appear. $ sleep 3; mail -s foo $LOGNAME bar bar ^@$ In total, one EOF before mail runs, three after. The email that arrives has the null byte suggested by the ‘^@’. $ sed -n \$p `mhpath .` YmFyCgA= $ sed -n \$p `mhpath .` | base64 -d | od -c 000 b a r \n \0 005 $ Type-ahead in the TTY has long been a Unix advantage. mail's notions of line-editing is getting in the way. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] minor error in s-nail configuration step
Hi Steffen,
> > > if [ -x "${path}/${pname}" ]; then
> > >echo "${path}/${pname}"
> >
> > This could really do with the `test -f' I pointed out as otherwise
> > it will be unhappy with my compiler collection under
> > /usr/local/bin/cc.
>
> This i do not understand?
$ mkdir cc
$ test -x cc
$ echo $?
0
$ test -f cc && test -x cc
$ echo $?
1
$
autoconf's configure wants -f and -x.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Re: [S-mailx] minor error in s-nail configuration step
Hi Steffen,
> if [ -x "${path}/${pname}" ]; then
>echo "${path}/${pname}"
This could really do with the `test -f' I pointed out as otherwise it
will be unhappy with my compiler collection under /usr/local/bin/cc.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Re: [S-mailx] minor error in s-nail configuration step
Hi Steffen, > We use command -v, which should not return something for which no > executable bit is set? $ >/tmp/foo $ PATH=/tmp:$PATH bash -c 'command -v foo' /tmp/foo $ >/tmp/ls $ PATH=/tmp:$PATH bash -c 'command -v ls' /usr/bin/ls $ -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] behave:lreply_futh_rth_etc test error
Hi, Steffen wrote: > Then again: > > $ pacman -S shellcheck > resolving dependencies... > looking for conflicting packages... > > Packages (13) ghc-8.0.2-3 haskell-json-0.9.1-8 haskell-mtl-2.2.1-7 > haskell-parsec-3.1.11-4 haskell-primitive-0.6.2.0-2 > haskell-quickcheck-2.10.0.1-1 haskell-random-1.1-7 > haskell-regex-base-0.93.2-27 haskell-regex-tdfa-1.2.2-5 > haskell-syb-0.7-1 haskell-text-1.2.2.2-2 > haskell-tf-random-0.5-11 shellcheck-0.4.6-6 > > Total Download Size:45.71 MiB > Total Installed Size: 468.23 MiB Yes, I uninstalled shellcheck from Arch Linux when its dependencies switched to this behemoth. Disks have a steady state of full, as Ken Thompson observed, and mine's no different. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] behave:lreply_futh_rth_etc test error
Hi Viktor, > > ['p', 'r', 'i', 'n', 't', 'f', ' ', "'", 'H', 'e', 'l', 'l', 'o', > > '\\', '"', '\\', 'n', "'"] ... > > It's the «\\» before the «\"» causing the problem; it's > > unspecified. One ends up with printf seeing «\"» and my printf(1p) > > says > > > > The interpretation of a followed by any other > > sequence of characters is unspecified. > > > > Without it, I get consistent results. > > > > $ bash -c "printf 'Hello\"\n'" > > Hello" > > $ bash -c "printf 'Hello\"\n'" | sha1sum > > f8edb41250edb3fea02ea9cb68488b123773b559 - > > $ dash -c "printf 'Hello\"\n'" | sha1sum > > f8edb41250edb3fea02ea9cb68488b123773b559 - > > Using b/dash -c ".." to switch shell is very misleading. Inside > double-quotes escaped characters loose their backslashes! Well, that's not quite true, as I showed above. > Please try with one file each shell: Or just paste this line into each shell. It's from the Python list above. printf 'Hello\"\n' It shows the same problem. The correct line to paste is printf 'Hello"\n' -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] behave:lreply_futh_rth_etc test error
Hi Steffen, > ?0[steffen@wales nail.git]$ dash -c "printf 'Hello\\\"\n'" > Hello\" > ?0[steffen@wales nail.git]$ bash -c "printf 'Hello\\\"\n'" > Hello" > > I should have double quoted LF as \\n $ python -c ' > import sys > print([c for c in sys.argv[1]]) > ' "printf 'Hello\\\"\n'" ['p', 'r', 'i', 'n', 't', 'f', ' ', "'", 'H', 'e', 'l', 'l', 'o', '\\', '"', '\\', 'n', "'"] $ It's the «\\» before the «\"» causing the problem; it's unspecified. One ends up with printf seeing «\"» and my printf(1p) says The interpretation of a followed by any other sequence of characters is unspecified. Without it, I get consistent results. $ bash -c "printf 'Hello\"\n'" Hello" $ bash -c "printf 'Hello\"\n'" | sha1sum f8edb41250edb3fea02ea9cb68488b123773b559 - $ dash -c "printf 'Hello\"\n'" | sha1sum f8edb41250edb3fea02ea9cb68488b123773b559 - -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] behave:lreply_futh_rth_etc test error
Hi Steffen, > It either is a bug in dash's builtin (?) printf(1) or i have used too > many quotes but which everybody except dash's printf gets right. What's the line causing problems? Heirloom sh is also handy for testing portability. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-mailx] Duplicate request for password, never succeeds
Hi Steffen,
> - memcpy(>url_path.s, "/INBOX", sizeof("/INBOX"));
> + memcpy(>url_path.s[i], "/INBOX", sizeof("/INBOX"));
That looks like it could just be strcpy(3) to save the reader checking
both string literals are the same.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
__
S-nail-users@lists.sourceforge.net
Re: [S-mailx] s-nail 14.9.0 prints warnings and segfaults when $HOME is not writable
Hi Stefan, > > The previous versions (14.8.16 and earlier) did neither print these > > warnings nor segfaulted. > > I consider these new verifications an improvement, you need to > redirect standard error to /dev/null to get rid of those But this discards all errors. `foo 2> >(grep -v '^foo: bar$' >&2)' avoids this, but is tedious, and breaks any synchronisation that foo might do by flushing of stdout and stderr. > (The idea is that we now catch things when they get set as necessary, > and can use them without further tests from then on. That sounds like a race condition. :-) Especially in a long-lived program. What later operations don't bother error checking because $HOME is not writable, for example? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [S-nail] Pasting Text into mail(1) Gives "[ERR_TOO_LONG]" Completion.
Hi Steffen, > > So it seems there's tab completion of filenames in the midst of > > writing an email. That seems of rare use, but a source of frequent > > annoyance. How is it disabled? > > Not at all. In v14.9, however, you will be able to re-`bind' the > tabulator expansion for compose mode. Let me see... ah ja, works: > > ?0[steffen@wales nail.git]$ ./s-nail -RSnoeditalong \ > -X "bind compose \$'\\t' RALPH@" That gave me a clue. `set line-editor-disable' in .mailrc helps. The TTY's erase, werase, and kill suffice for me, and if not there's `~e'. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot __ S-nail-users@lists.sourceforge.net
Re: [S-nail] shortcut personal +INBOX.Personal broken
Hi Steffen,
> + soll = (i > 0 && cbuf[i - 1] == '/');
> + if(which_protocol(cbuf) == PROTO_IMAP){
> + bool_t hpath;
> +
> + hpath = (strcmp(cbuf, protbase(cbuf)) != 0);
> + res = str_concat_csvl(, cbuf, (hpath || soll ? "" : "/"),
> + [1], NULL)->s;
> + }else
> + res = str_concat_csvl(, cbuf, (soll ? "" : "/"), [1],
> NULL)->s;
It occurs to me that the two assignments to res are nearly identical.
Perhaps
bool_t hpath;
soll = i > 0 && cbuf[i - 1] == '/';
hpath = which_protocol(cbuf) == PROTO_IMAP &&
strcmp(cbuf, protbase(cbuf)) != 0;
res = str_concat_csvl(, cbuf, (soll || hpath ? "" : "/"), [1],
NULL)->s;
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
__
S-nail-users@lists.sourceforge.net
Re: [S-nail] Wait for Forked sendmail to Finish.
Hi Steffen, > > I had a look and don't think so for my case. I'm using script(1) to > > capture my interaction with mail(1) in case of problems, but > > otherwise I do want the normal interactive experience. ... > [-] Add *typescript-mode*, set it for -# I can see it's handy, but I still won't be using it for this case since I'm interested in what I did at a TTY to trigger any mail(1) SEGV that may result, thus I'm happy with deciphering control codes and line-editing noise afterwards. :-) Not that I've had a SEGV for a while now! -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot __ S-nail-users@lists.sourceforge.net
[S-nail] Wait for Forked sendmail to Finish.
Hi, s-nail 14.8.10-1. I'm running mail(1) with script(1) and there's a race between mail forking so the child can run sendmail, the parent mail doesn't wait for the child, and script seeing the parent mail has finished and stopping. A SIGHUP can stop sendmail being run. syslog shows no entries for the mail and it's lost. Most of the time, it works fine, but, especially for small emails, the mail doesn't get sent and there's no diagnostic. I looked for a `no fork, stay in foreground' option, but didn't spot anything. Suggestions welcome. :-) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot __ S-nail-users@lists.sourceforge.net
Re: [S-nail] S-nail v14.9.0-pre1 preview on [master] (backward incompatible!)
Hi Steffen, > It turned out we have a general problem on at least Sun Solaris, where > +00C1 a.k.a. \u00C1 will be happily iconv(3)d to "?", i.e., i can > happily iconv_open(3) from UTF-8 (128,172 characters) to ISO 646 > a.k.a. US-ASCII (128 characters). What's iconv(3)'s return value for that case? It's a non-identical conversion so I'd expect it to bump the return value. > i know that POSIX doesn't specify such an error You might find http://austingroupbugs.net/view.php?id=1007 of interest. Doesn't help today, though. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Possible bug in s-nail on timestamp of Dec 31
Hi Donald, > How do you post correctly. Explain top posting so I can avoid doing > it. https://en.wikipedia.org/wiki/Posting_style should explain. In brief, it's common to keep just the pertinent bits of the email you're replying to, "quote" those, I use "> " as do many others, and then intersperse your reply between those quotes, using them for context to give clarification and avoiding repeating their content. But really, people should be forgiving of newcomers that are seeking help and don't understand the local conventions. :-) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Possible bug in s-nail on timestamp of Dec 31
Hi Donald, BTW, I suspect the "Dec 31" are in 1969 and the time was zero seconds past the Unix epoch, viewed offset by a negative timezone. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Possible bug in s-nail on timestamp of Dec 31
Hi Donald, > > How do you "configure the way the headline is displayed with the > > variable of the same name[1]" In the s-nail.rc file? All I want to > > get is a correct timestamp for my messages instead of Dec 31. Does this help? $ mail mail version v14.8.10. Type ? for help. "/var/spool/mail/ralph": 3 messages 3 unread >U 1 Ralph Corderoy Thu Sep 15 15:03 14/471 U 2 Ralph Corderoy Thu Sep 15 15:03 14/471 U 3 Ralph Corderoy Thu Sep 15 15:03 14/471 ? set datefield='%Y-%m-%d %T %z %a' ? set headline='%>%a%m %-18f %29d %4l/%-5o %i%-s' ? h >U 1 Ralph Corderoy 2016-09-15 15:03:25 +0100 Thu 14/471 U 2 Ralph Corderoy 2016-09-15 15:03:27 +0100 Thu 14/471 U 3 Ralph Corderoy 2016-09-15 15:03:28 +0100 Thu 14/471 headline needed altering to use a wider width for %d else datefield's conversion was truncated. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Possible bug in s-nail on timestamp of Dec 31
Hi Donald, > See my other email for a printout. Us other list members don't have access to what you sent back to the list before. If you still have the original, please forward the text to the list. Cheers, Ralph. -- __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Format of ~/dead.letter isn't mbox.
Hi Steffen, > Interesting: You are right in that the standard explicitly requires > the From_ line to be written. I found http://pubs.opengroup.org/onlinepubs/7908799/xcu/mail.html that says dead.letter is trampled every time, but nothing about the format. And http://pubs.opengroup.org/onlinepubs/009695399/utilities/mailx.html that again says it's trampled, but it's mbox format. > I have rewritten it!, and now we at least produce the From_ line which > makes this an MBOX. It is still not compliant because we don't > produce any header lines, maybe i can do something about that before > v14.9 and will fix it up, but i can't promise that. Don't forget the From-munging; I couldn't find a recent relevant change on https://git.sdaoden.eu/cgit/s-nail.git/log/?h=crawl when I looked. (http://qmail.org./man/man5/mbox.html is a good overview of the mbox formats.) Cheers, Ralph. -- __ S-nail-users@lists.sourceforge.net
[S-nail] Format of ~/dead.letter isn't mbox.
Evening all, The ~/dead.letter created by s-nail's mail(1) isn't mbox format. It's just a catenation of email bodies over time. This means subject, etc., are lost when a user INTRs twice, and it's tedious to pull the file apart and back into emails. Old memories had me believe ~/dead.letter was mbox format, allowing simple splitting on /^From /, but I don't think this BSD mail program has done that in s-nail's lineage? I've certainly experienced mbox-format ~/dead.letters, and see sendmail(8) also writes to the file, and is probably not alone. I've checked sendmail/deliver.c's mailfile() and it writes mbox; "putfromline". So I guess I'm asking if anyone knows the history of this discrepancy? Both have a BSD heritage. mbox format is arguably better than cat'd bodies, so s-nail could grow an option to use that format. By default? But I'm more interested in any archaeology folks have. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- __ S-nail-users@lists.sourceforge.net
Re: [S-nail] S-nail first impression
Hi steffen, > It's all true what you say, but fetchmail set that standard No it didn't. libc's rexec(3) parsed .netrc far before fetchmail was created. GNU inetutils for ftp(1) ditto. > Yes. But no: also because it is explicitly documented as > > · As a non-portable extension some widely-used programs support > shell-style comments: if an input line starts, after any amount > of white‐space, with a number sign ‘#’, then the rest of the line > is ignored. It's not an extension. It fails to parse a valid .netrc. Linefeed isn't special in the token-separating; it's the same as a space, tab, or comma. It's a non-portable incompatibility. Perhaps the documentation should state that instead? Cheers, Ralph. -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j __ S-nail-users@lists.sourceforge.net
Re: [S-nail] S-nail first impression
Hi, I wrote: > Eric Schmidt cooked up ~/.netrc as part of the Berkeley Network, and > it has no comment character. http://web.mit.edu/usrdoc/misc/berknet/netintro.n is the original definition. I find GNU's inetutils-1.9.4's ftp/ruserpass.c seems to stick to that: no explicit comment character, allows comma as separator not just whitespace, double-quoted string, etc. machine "who needs a comment character anyway" Cheers, Ralph. -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j __ S-nail-users@lists.sourceforge.net
Re: [S-nail] sign conditionally
Hi Rudolf, > is it possible, when using S/MIME, to sign the mail only sometimes? > (Mostly, it is redundant, only sometimes it's really wanted.) Are you aware of `asksign' in mail(1)? Also, smime-sign-cert-USER@HOST means it can be turned on for particualar `From:', or `Sender:', addresses. Cheers, Ralph. -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z __ S-nail-users@lists.sourceforge.net
[S-nail] realloc Abort when Entering Subject.
Hi, s-nail 14.8.8-1. 5ecb39d3c90888d58f1028990a1dc3843ad163fe /usr/bin/mail I was entering the Subject when prompted, and corrected a typo using backspace and replacing the deleted characters, as I continued typing, the error appeared. I've replaced the a-z characters I typed with abc... for privacy, but the `+' and spacing are the same. $ mail foo Subject: + abcdefg hijkl mnopq*** Error in `mail': realloc(): invalid next size: 0x02196f50 *** === Backtrace: = /usr/lib/libc.so.6(+0x6f364)[0x7fdb61423364] /usr/lib/libc.so.6(+0x74d96)[0x7fdb61428d96] /usr/lib/libc.so.6(+0x77e09)[0x7fdb6142be09] /usr/lib/libc.so.6(realloc+0x139)[0x7fdb6142d1b9] mail[0x40dada] srealloc mail[0x455525] tty_readline mail[0x41b2d1] readline_input mail[0x41b55e] n_input_cp_addhist mail[0x421923] grab_headers mail[0x4168f4] collect mail[0x44cc7e] mail1 mail[0x44da8e] mail mail[0x407242] main /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fdb613d4710] mail[0x4077f9] _start === Memory map: 0040-00475000 r-xp 08:01 281144 /usr/bin/mail 00675000-00676000 r--p 00075000 08:01 281144 /usr/bin/mail 00676000-00677000 rw-p 00076000 08:01 281144 /usr/bin/mail 00677000-00687000 rw-p 00:00 0 0216e000-021b rw-p 00:00 0 [heap] 7fdb5800-7fdb58021000 rw-p 00:00 0 7fdb58021000-7fdb5c00 ---p 00:00 0 7fdb5fc48000-7fdb5fc5e000 r-xp 08:01 262082 /usr/lib/libgcc_s.so.1 7fdb5fc5e000-7fdb5fe5d000 ---p 00016000 08:01 262082 /usr/lib/libgcc_s.so.1 7fdb5fe5d000-7fdb5fe5e000 rw-p 00015000 08:01 262082 /usr/lib/libgcc_s.so.1 7fdb5fe5e000-7fdb5fe69000 r-xp 08:01 261838 /usr/lib/libnss_files-2.23.so 7fdb5fe69000-7fdb60068000 ---p b000 08:01 261838 /usr/lib/libnss_files-2.23.so 7fdb60068000-7fdb60069000 r--p a000 08:01 261838 /usr/lib/libnss_files-2.23.so 7fdb60069000-7fdb6006a000 rw-p b000 08:01 261838 /usr/lib/libnss_files-2.23.so 7fdb6006a000-7fdb6007 rw-p 00:00 0 7fdb6007-7fdb60252000 r--p 08:01 319616 /usr/lib/locale/locale-archive 7fdb60252000-7fdb6026a000 r-xp 08:01 261742 /usr/lib/libpthread-2.23.so 7fdb6026a000-7fdb60469000 ---p 00018000 08:01 261742 /usr/lib/libpthread-2.23.so 7fdb60469000-7fdb6046a000 r--p 00017000 08:01 261742 /usr/lib/libpthread-2.23.so 7fdb6046a000-7fdb6046b000 rw-p 00018000 08:01 261742 /usr/lib/libpthread-2.23.so 7fdb6046b000-7fdb6046f000 rw-p 00:00 0 7fdb6046f000-7fdb60483000 r-xp 08:01 261845 /usr/lib/libresolv-2.23.so 7fdb60483000-7fdb60682000 ---p 00014000 08:01 261845 /usr/lib/libresolv-2.23.so 7fdb60682000-7fdb60683000 r--p 00013000 08:01 261845 /usr/lib/libresolv-2.23.so 7fdb60683000-7fdb60684000 rw-p 00014000 08:01 261845 /usr/lib/libresolv-2.23.so 7fdb60684000-7fdb60686000 rw-p 00:00 0 7fdb60686000-7fdb60689000 r-xp 08:01 270448 /usr/lib/libkeyutils.so.1.5 7fdb60689000-7fdb60888000 ---p 3000 08:01 270448 /usr/lib/libkeyutils.so.1.5 7fdb60888000-7fdb60889000 r--p 2000 08:01 270448 /usr/lib/libkeyutils.so.1.5 7fdb60889000-7fdb6088a000 rw-p 3000 08:01 270448 /usr/lib/libkeyutils.so.1.5 7fdb6088a000-7fdb60896000 r-xp 08:01 270514 /usr/lib/libkrb5support.so.0.1 7fdb60896000-7fdb60a95000 ---p c000 08:01 270514 /usr/lib/libkrb5support.so.0.1 7fdb60a95000-7fdb60a96000 r--p b000 08:01 270514 /usr/lib/libkrb5support.so.0.1 7fdb60a96000-7fdb60a97000 rw-p c000 08:01 270514 /usr/lib/libkrb5support.so.0.1 7fdb60a97000-7fdb60a9a000 r-xp 08:01 270143 /usr/lib/libcom_err.so.2.1 7fdb60a9a000-7fdb60c99000 ---p 3000 08:01 270143 /usr/lib/libcom_err.so.2.1 7fdb60c99000-7fdb60c9a000 r--p 2000 08:01 270143 /usr/lib/libcom_err.so.2.1 7fdb60c9a000-7fdb60c9b000 rw-p 3000 08:01 270143 /usr/lib/libcom_err.so.2.1 7fdb60c9b000-7fdb60cc9000 r-xp 08:01 270527 /usr/lib/libk5crypto.so.3.1 7fdb60cc9000-7fdb60ec8000 ---p 0002e000 08:01 270527 /usr/lib/libk5crypto.so.3.1 7fdb60ec8000-7fdb60eca000 r--p 0002d000
Re: [S-nail] Temporary restrictions with new builtin line editor on [next]
Hi, Martin wrote: > What I (and a colleague of mine) never understood: what's the point > of the s-nail line-editor? Being new to the list, I've been wondering that too. ~e and ~v are available. ~h lets one cursor through the field. And if it is wanted, aren't there's BSD-compatible libraries that provide GNU readline-like behaviour? Cheers, Ralph. -- __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Core Dump when Backspacing in Mail Body.
Hi Steffen, > > $ LC_ALL=C MAILRC=/dev/null valgrind ./bin/s-nail -n $USER > > ==1153== Memcheck, a memory error detector > > ==1153== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > > ==1153== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copy\ > > right info > > ==1153== Command: ./bin/s-nail -n ralph > > ==1153== > > sdfkjslfkjsfsdfklj ldsfkSubject: lkdjflkjsdlfkj lkdfj lksdjf lksd\ > > jf lkjsdf==1153== Invalid read of size 8 > > That really drives me mad now, i've even had lines of i guess > several thousand bytes. What are you doing? ^_^ I only typed what you can see, with some Backspaces thrown in along the way, so 150 bytes at most. I can't recreate it though, so it looks like a more rare problem than the earlier one you released a fix for. Cheers, Ralph. -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Core Dump when Backspacing in Mail Body.
Hi Steffen, > > $ LC_ALL=C MAILRC=/dev/null valgrind mail -n $USER > > Valgrind i've never used, though... :( The default, like I've used, is a good help without even reading the man page. The program under test runs more slowly, but valgrind is checking every memory access against its model of what's been allocated, written to, etc. Many errors with memory in C don't cause obvious problems a lot of the time; valgrind notices them every time. :-) Cheers, Ralph. -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 __ S-nail-users@lists.sourceforge.net
Re: [S-nail] Pasting into mail(1) in X terminal Truncates to One Line.
Hi steffen,
> > An strace(1) shows read(2)s of one byte consuming the first line,
> > including the LF. ioctl(2)s and signal handling are then done. The
> > next read of stdin sees Ctrl-D, the terminal's EOF character, and no
> > more reads are attempted.
The ioctl are
ioctl(0, TCSETSF, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCSETSF, {B38400 opost isig -icanon -echo ...}) = 0
and I think TCSETSF is the same as tcsetattr(0, TCSAFLUSH, ...) and that
"discard pending input" -- tty_ioctl(4). Note sure why the EOF follows,
but it's a clue.
Cheers, Ralph.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
__
S-nail-users@lists.sourceforge.net
[S-nail] Pasting into mail(1) in X terminal Truncates to One Line.
Hi, Arch Linux, s-nail 14.8.6-2, xfce4-terminal or xterm. Running `mail $USER' in the terminal, entering a subject when prompted, and then pasting a dozen lines or so results in just the first of those getting into the body of the email. The method of pasting doesn't affect the outcome. An strace(1) shows read(2)s of one byte consuming the first line, including the LF. ioctl(2)s and signal handling are then done. The next read of stdin sees Ctrl-D, the terminal's EOF character, and no more reads are attempted. Cheers, Ralph. -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 __ S-nail-users@lists.sourceforge.net
