[no subject]
-- ent- XR
Fyi: this list, screen-users, just had it's subject [tag] and footer removed
The Free Software Foundation has changed the GNU Mailman settings on this list. The short version is that any subject prefix or message footer has been removed, allowing us to turn off DMARC from munging. Any list administrator for this list is free to change these settings back, instructions are below. The change is to better deal with increased adoption of the DMARC email standard. The default Mailman settings were causing messages sent from users with strict DMARC policy domains like yahoo.com to be rejected when sent to list subscribers by Mailman. See the end of this email for a technical overview of DMARC and DKIM. There are two main ways to fix the issue by changing Mailman list settings. The first option, and the preferable way for discussion lists, is what we call the "unmodified message fix." There are Mailman list settings which modify the messages by adding a subject prefix (e.g. [list-name]) or a footer. Modifying the message breaks DKIM message signatures and thus DMARC, so we just turn those off. Many lists are already this way and there is no change for them. Instead of using the subject prefix to identify a list, subscribers should use the List-Id, To, and Cc headers. List footer information can also be be put in the welcome email to subscribers and the list information page by list administrators. We changed the default for new lists to send unmodified messages, and are now updating existing discussion lists to the new default. We emailed all list administrators and moderators and Savannah group admins to allow them to opt in to the alternate fix before we made this change. However, not all lists had a valid administrator contact. The second option is for lists which want or need to continue to modify the message, for example with subject prefix or footer settings. In this case we turn on a Mailman list setting called dmarc_moderation_action: "Munge From". With this, if a strict DMARC sender sends to the list, we alter the headers of that message like so: A message sent to the list: From: Anne Example Person Is modified by Mailman and sent to subscribers as: From: Anne Example Person via Alist Reply-To: Anne Example Person Without going into all of the details, here's a few points about why we concluded the unmodified message fix is better for discussion lists. Email clients don't all treat munged messages the same way as unmunged, and humans read these headers so it can confuse people, causing messages not to be sent to the expected recipients. GNU Mailman has an option to do "Munge From" always, but does not recommend using it[1]. While we're not bound by what others do, it's worth noting that other very large free software communities like Debian GNU/Linux have adopted the unmodified message fix[2]. The unmodified messages fix avoids breaking DKIM cryptographic signatures, which show the message was authorized by the signing domain and seems like a generally good security practice. Tools to manage patches, for example patchew, use the from field and are tripped up by from munging. For any Mailman list administrator who wants to change or look over the relevant settings: The dmarc_moderation_action setting is under "Privacy Options" subsection "Sender Filters". The only options that should be selected are "Accept" or "Munge From", along with corresponding changes to the subject_prefix option under "General Options", and msg_footer is under "Non-digest options". If no list administrators or moderators are around for this list, anyone should feel free to try to track them down or figure out who should become one and explain in detail by replying to sysad...@gnu.org. Please be patient, this process may take several weeks. Please send any questions that should be public to mail...@gnu.org. For private ones, just reply to sysad...@gnu.org. For the general announcement of these changes, please read https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html and https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html A short DMARC technical overview: DMARC policy is a DNS txt record at a _dmarc subdomain. For example: $ host -t txt _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:address@hidden;;; The only important thing there for our purpose is p=reject. p=reject means that conforming mail servers that receive mail with a from header of *@yahoo.com will reject that email unless it was either 1. sent from Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM signature[5] is a public key cryptographic signature of the email body and some headers included in the message header "DKIM-Signature". A verified DKIM signature means that email body and signed headers have not been modified. Comprehensive resources about DMARC tend to downplay or ignore its problems, b
[no subject]
My s5 is having a problem with flash all seen ___ screen-users mailing list screen-users@gnu.org https://lists.gnu.org/mailman/listinfo/screen-users
(no subject)
It would be really cool if gnu-screen could receive mouse wheel events
and translate them to Command-Esc and ^Y or ^E as appropriate.
Possibly it could be more intelligent about handling mouse wheel events
when *already* in copy mode (^A^[).
There could be a switch for users to decide whether they want their
mouse events passed to the app or used by screen.
At work, I'm using AutoHotkey (anyone tied to windows on the desktop will
probably benefit from AutoHotkey, or a program like it. Look it up) to
sent something else than the default 'escape' code when I press keys on
the numberpad area of my keyboard. e.g. PgUp becomes esc[NumpadPgUp].
On the screen side, I catch these pseudo-escape codes and do something
interesting with them. Examples:
...
# escape sequences from the keypad.
bindkey ^[[NumpadPgUp] eval copy stuff \^u\ # page-up goes to copy mode
bindkey ^[[NumpadPgDn] eval copy # page-down goes to copy mode
bindkey -m ^[[NumpadPgUp] stuff ^u # page-up sends page-up in copy mode
bindkey -m ^[[NumpadPgDn] stuff ^d # page-down sends page-down in copy mode
bindkey ^[[NumLock] stuff \033
bindkey ^[[NumpadEnter] stuff \012
bindkey ^[[NumpadClear] screen
bindkey ^[[NumpadRight] next
bindkey ^[[NumpadLeft] prev
bindkey ^[[NumpadDown] focus down
bindkey ^[[NumpadUp] focus up
bindkey ^[[NumpadDiv] eval split fit
bindkey ^[[NumpadMult] eval only split split split select 0
fit focus down select 1 fit focus down select 2 fit focus
down select 3 fit focus down
bindkey ^[[NumpadSub] remove
bindkey ^[[NumpadAdd] eval only fit
bindkey ^[[NumpadHome] stuff -
bindkey ^[[NumpadEnd] stuff +
bindkey ^[[NumpadIns] stuff conf t\012
bindkey ^[[NumpadDel] stuff end\012
# other
bindkey ^[[Pause] suspend
bindkey ^[[PrintScreen] detach
bindkey ^? stuff ^h
bindkey \033^M command #
bindkey \033` command # alt-`
escape # no more ctrl-a to get to command mode
bindkey ^[^[[5~ eval copy stuff \^u\ # alt-page-up goes to copy mode
bindkey ^[^[[6~ eval copy # alt-page-down goes to copy mode
bindkey -m ^[^[[5~ stuff ^u # alt-page-up sends page-up in copy mode
bindkey -m ^[^[[6~ stuff ^d # alt-page-down sends page-down in copy mode
...
For historical reasons (Can't type properly and on original PCs had to use
the editing keys all the time. They were on the numpad only, so never used
'numlock'. New PCs come with separate editing keys, but already too used
to type numbers without keypad.), I don't use the keys on the numpad in my
normal work, so I have 17-keys to use for macros like this. Now, to scroll
with the mouse, I've just extended this to make ctrl-scrollwheel send the
same pseudo escape codes as pg-up/down do:
(autohotkey snippet)
GroupAdd UNIX, ahk_class PuTTY
GroupAdd UNIX, ahk_class VNCviewer
GroupAdd UNIX, ahk_class cygwin/x
#IfwinActive ahk_group UNIX
^WheelUp::
SendInput {escape}[NumpadPgUp]
return
^WheelDown::
SendInput {escape}[NumpadPgDn]
return
Pieter
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
On Oct 10, 2007, at 5:19 AM, Christian Ebert wrote: AFAIR ncurses shipped with MacOS X is an old version that doesn't have a screen-256color entry. What gives: $ infocmp screen-256color If you get an error, the cleanest solution is to install a recent ncurses version (fink's is not new enough either, don't know about MacPorts). okay. so... it works! i'm not sure what happened, but my current configuration is working - good colours in screen. i've got termcapinfo xterm ti@:te@ defscrollback 4242#Will be handled localy attrcolor b .I termcapinfo xterm-color 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' defbce on startup_message off in my .screenrc and, the pertinent bits of my .vimrc set antialias set t_Co=256 set background=dark and it's working great. thanks for all the help people. ps. i did up upgrade my screen to the latest macports version too - 4.0.3. cheers. a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
(no subject)
hi all, first post to the list- i've scanned the archives and seen that others have had issues getting 256 colors under screen as well - this is the issue i'm having. i'm running the 'xterm-colortest' found here: http://frexx.de/xterm-256-notes/ http://frexx.de/xterm-256-notes/data/xterm-colortest and it works correctly in my terminal (iTerm on OSX). however, when i start screen the colors are binned into nearest neighbor or something like that. here is my .screenrc cfp:~ cat .screenrc termcapinfo xterm ti@:te@ defscrollback 1#Will be handled localy ### http://frexx.de/xterm-256-notes/ # terminfo and termcap for nice 256 color terminal # allow bold colors - necessary for some reason attrcolor b .I # tell screen how to set colors. AB = background, AF=foreground termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' # erase background with current bg color defbce on any thoughts on how to fix this issue? kind regards. a @ http://codeforpeople.com/ -- share your knowledge. it's a way to achieve immortality. h.h. the 14th dalai lama ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
On Tue, Oct 09, 2007 at 11:08:02AM EDT, ara.t.howard wrote: hi all, first post to the list- i've scanned the archives and seen that others have had issues getting 256 colors under screen as well - this is the issue i'm having. i'm running the 'xterm-colortest' found here: http://frexx.de/xterm-256-notes/ http://frexx.de/xterm-256-notes/data/xterm-colortest and it works correctly in my terminal (iTerm on OSX). however, when i start screen the colors are binned into nearest neighbor or something like that. here is my .screenrc cfp:~ cat .screenrc termcapinfo xterm ti@:te@ defscrollback 1#Will be handled localy ### http://frexx.de/xterm-256-notes/ # terminfo and termcap for nice 256 color terminal # allow bold colors - necessary for some reason attrcolor b .I # tell screen how to set colors. AB = background, AF=foreground termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' # erase background with current bg color defbce on any thoughts on how to fix this issue? kind regards. IIRC .. you first need to have a version of screen that supports 256 colors _and_ specify --enable-colors256 when you ./configure it prior to compile. AFAIK 256-color support is not the default. If you didn't compile screen yourself -- if you are running a binary distribution such as debian stable for instance .. it probably was not enabled by the package maintainer. Not sure if there's a way you can check on the configure options from the binary. Another thing is that you are going to need to have screen point to a terminfo entry that supports 256 colors. I do the latter with the following .screenrc statement: termscreen-256color-bce Even if this turns out not to be necessary (?) to run your 256-color test from a shell successfully, you will need a correct terminfo entry for screen-mode apps that use it to determine the capabilities of the underlying terminal anyway (mutt, vim, eg.) I can't look into the details of my setup right now but I think the above is all there is to it. HTH Thanks, cga ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
On Oct 9, 2007, at 11:22 AM, cga2000 wrote: IIRC .. you first need to have a version of screen that supports 256 colors _and_ specify --enable-colors256 when you ./configure it prior to compile. right. the Portfile on OSX does indeed specify this option to configure Another thing is that you are going to need to have screen point to a terminfo entry that supports 256 colors. I do the latter with the following .screenrc statement: termscreen-256color-bce how odd, with that in my .screenrc i get the following error on startup: TERMCAP, line 20, col 1, terminal 'screen-256color-bce': Illegal character (expected alphanumeric or @%*!#) - ^J cfp:~ cat .screenrc termcapinfo xterm ti@:te@ defscrollback 4242#Will be handled localy ### http://frexx.de/xterm-256-notes/ # terminfo and termcap for nice 256 color terminal # allow bold colors - necessary for some reason attrcolor b .I # tell screen how to set colors. AB = background, AF=foreground # erase background with current bg color defbce off term screen-256color-bce termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' Even if this turns out not to be necessary (?) to run your 256-color test from a shell successfully, you will need a correct terminfo entry for screen-mode apps that use it to determine the capabilities of the underlying terminal anyway (mutt, vim, eg.) well i think that's okay since every works in straight iterm or terminal, it's only under screen where things be hosed. cheers. a @ http://codeforpeople.com/ -- it is not enough to be compassionate. you must act. h.h. the 14th dalai lama ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 -- it is not enough to be compassionate. you must act. h.h. the 14th dalai lama The philosophers have only interpreted the world, in various ways. The point, however, is to change it. -- Karl Marx, Eleven Theses on Feuerbach - -- *** FULL-SPECTRUM DOMINANCE! *** * BOYCOTT BOURGEOIS MASS-MEDIA: * McNews: UNfair UNbalanced * * Get mediaworx for your group/Internet/pirate tv/radio station! * Critical endorsement only Most sites need donations *** * http://www.venezuelaenvideos.com Venezuela en Videos * * http://www.actupny.org/divatv DIVA TV * Che Guevara audio, songs * * http://www.sancristobal.cult.cu/sitios/Che/Index.HTM videos * * http://www.videonetwork.org i-Contact Video Network * * http://citizen.nfb.ca/onf/info?did=901 NFB film on Guatemala * * http://www.revolutionvideo.org Revolution Video * * http://www.revolutionvideo.org/alavio Grupo Alivio [Argentina] * ** Capitalism lives on borrowed time: the ultimate carry trade ** GPG fingerprint = 2E7F 2D69 4B0B C8D5 07E3 09C3 5E8D C4B4 461B B771 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHDDyXXo3EtEYbt3ERAjlvAJ4nqyIZGcf0Msrn42JXICw1B5VbLwCfUFuv bts2aUe9pmjfZWB7lseybDg= =X/+w -END PGP SIGNATURE- ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
On 5/29/07, cga2000 [EMAIL PROTECTED] wrote: My preference would be for half-page scrolling via Ctrl-U and Ctrl-D (same as in vim) and good mnemonics as any. The vi keys Ctrl-F and Ctrl-B for forward and backward a screenful work also. I often use the Ctrl-Y and Ctrl-E keys as well, far more convenient since they scroll up and down regardless of cursor position. -- Andy Harrison ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
On Wed, May 30, 2007 at 11:52:02AM EDT, Andy Harrison wrote: On 5/29/07, cga2000 [EMAIL PROTECTED] wrote: My preference would be for half-page scrolling via Ctrl-U and Ctrl-D (same as in vim) and good mnemonics as any. The vi keys Ctrl-F and Ctrl-B for forward and backward a screenful work also. I often use the Ctrl-Y and Ctrl-E keys as well, far more convenient since they scroll up and down regardless of cursor position. Thanks Andy, Actually I'd never really thought about it but half-page scrolling via Ctrl-U Ctrl-D works out of the box. Sorry I misunderstood the OP's intentions .. and failed to notice this thread was a bit stale. Thanks, cga ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
On 2/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The current scrolling interface to GNU Screen is not particularly simple to use, and neither so to understand. The reason is that this mode is mainly designed to move around text, and not scroll the window, which is just a side effect. Would a patch integrating easier scrolling, say, by the Linux-style SHIFT+PG??, be welcome? Leslie ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users -- .!# RichardBronosky #!. ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
Sounds very convenient. I'd like to see this. Please submit a patch if you have one. On 2/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The current scrolling interface to GNU Screen is not particularly simple to use, and neither so to understand. The reason is that this mode is mainly designed to move around text, and not scroll the window, which is just a side effect. Would a patch integrating easier scrolling, say, by the Linux-style SHIFT+PG??, be welcome? Leslie ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users -- .!# RichardBronosky #!. ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
(no subject)
The current scrolling interface to GNU Screen is not particularly simple to use, and neither so to understand. The reason is that this mode is mainly designed to move around text, and not scroll the window, which is just a side effect. Would a patch integrating easier scrolling, say, by the Linux-style SHIFT+PG??, be welcome? Leslie ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: (no subject)
Pardon me while I daydream for a second... - A dedicated OSX screen terminal client, it could be configured to bounce the dock icon when a bell is received or a monitored window changed. Similarly, in Windows or contemporary unix desktops like Gnome, tasktray icons could flash or otherwise indicate alerts from a screen backend. - On OSX, other clients could be created dedicated to just monitoring or controlling a screen backend session instance. For example, a process could monitor screen and make Growl notifications that a bell was received in window X. Or a Konfabulator widget (lol, Tiger dashboard widget) could monitor screen windows. - Whatever protocol that spans between the front-end and back-end is tunnel-able over SSH. Clients are optionally linked with ssh libraries and can tunnel themselves. - The architecture and protocols could be designed to fully mesh backends, so that for example backend instance A (securely) connected to B and C; B to A and C; C to A and B.. then by connecting to any of the backends, the client would be aware of any windows in all the instances (permission permitting of course). Again, just daydreaming. :) On Apr 4, 2005, at 12:59 PM, Xavier Nicollet wrote: Le 11 janvier 2005 à 11:43, jmartin a écrit: I've also contemplated separating out the display logic from the backend pty logic into more of a client-server model to achieve two goals: first, to build non-terminal front-ends, like a tabbed terminal emulator in X, or an OSX Cocoa tabbed terminal; second, to securely (ssh?) interconnect screen backends, so that you could bridge two (or more) hosts running screen, and switching between screens on different hosts would be transparent. Great ! I don't know if it would be very easy with the current screen codebase. -- Xavier Nicollet http://nicollet.jeru.org/ ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
