Re: mail relaying
On Jun 22 you wrote:
> Hello,
>
> On Thu, Jun 21, 2012 at 05:06:40PM -0700, jeremy
> bentham wrote:
> > instant "connection refused", with either smtp
> > or smtps, ssl_starttls yes or no.
>
> I've checked ports on mail.eskimo.com with nmap:
> > PORT STATESERVICE
> > 25/tcp open smtp
> > 465/tcp closed smtps
> > 587/tcp filtered submission
> > 2525/tcp open unknown
nmap; something else I see I don't have installed; I'm learning
other stuff here
{-;
> So you should rather try
> "smtp://u...@mail.eskimo.com:25"
> "smtp://u...@mail.eskimo.com:2525"
> "smtps://u...@mail.eskimo.com:2525"
These result in tls-related errors after the afore-mentioned
10-minute wait.
I managed to get through to a knowledgable person at eskimo.com
and he thinks my problem is that, currently, the mailserver
doesn't support ssl at all.
However, when I set ssl_starttls to "no" it merely changes the
error message.
Searching TFM for tls doesn't reveal anything else that looks
relevant; is there something Double Top Secret?
btw, thanks for your time.
--
Dave Williams
d...@eskimo.com
Re: mutt deletes attachement before libreoffice tries to open it
On Fri, Jun 22, 2012 at 11:27:23AM -0700, Gary Johnson wrote: > On 2012-06-22, Luis Mochan wrote: > > > But that would defeat the purpose of the copy which is to have a > > > stable file for LibreOffice to read while allowing mutt to wipe and > > > delete its temporary file. A hard link would work if it wasn't that > > > mutt wipes the file before unlinking it. > > > > > > > I guess not. If I understand correctly, the file will remain alive > > while its link count of the file is possitive. Even if mutt deletes > > (it's link), the other link (and the file) will survive. > > Yes, but mutt overwrites the contents of the file with zeros first > (what I meant by wiping), leaving the other link pointing to a file > full of zeros, and leaving LibreOffice with nothing useful to read. > Got it. Anyway, what is the rationale for wiping the file contents? Security? Regards, Luis -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Apdo. Postal 48-3, 62251 | (*)/\/ \ Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Re: mutt deletes attachement before libreoffice tries to open it
On 2012-06-22, David Champion wrote: > * On 22 Jun 2012, Gary Johnson wrote: > > > > But that would defeat the purpose of the copy which is to have a > > stable file for LibreOffice to read while allowing mutt to wipe and > > delete its temporary file. A hard link would work if it wasn't that > > mutt wipes the file before unlinking it. > > The last time I worried about this, mutt didn't zero out temporary files > before unlinking them. If it does that now then hard links are not a > solution. The last time I looked at this was a few years ago, so mutt's behavior could well have changed in the mean time. I just assumed it still did that. It seemed like an unusual, deliberate design decision that was not likely to change. Regards, Gary
Re: mutt deletes attachement before libreoffice tries to open it
* On 22 Jun 2012, Gary Johnson wrote: > > But that would defeat the purpose of the copy which is to have a > stable file for LibreOffice to read while allowing mutt to wipe and > delete its temporary file. A hard link would work if it wasn't that > mutt wipes the file before unlinking it. The last time I worried about this, mutt didn't zero out temporary files before unlinking them. If it does that now then hard links are not a solution. If only every OS had a modern filesystem with copy on write available at the file level to unprivileged users. Maybe a COW shim (FUSE?) using sparse backing store of rewritten blocks over an arbitrary backend fs -- David Champion • d...@uchicago.edu • IT Services • University of Chicago
Re: mutt deletes attachement before libreoffice tries to open it
On 2012-06-22, Luis Mochan wrote: > > But that would defeat the purpose of the copy which is to have a > > stable file for LibreOffice to read while allowing mutt to wipe and > > delete its temporary file. A hard link would work if it wasn't that > > mutt wipes the file before unlinking it. > > > > I guess not. If I understand correctly, the file will remain alive > while its link count of the file is possitive. Even if mutt deletes > (it's link), the other link (and the file) will survive. Yes, but mutt overwrites the contents of the file with zeros first (what I meant by wiping), leaving the other link pointing to a file full of zeros, and leaving LibreOffice with nothing useful to read. Regards, Gary
Re: mutt deletes attachement before libreoffice tries to open it
> But that would defeat the purpose of the copy which is to have a > stable file for LibreOffice to read while allowing mutt to wipe and > delete its temporary file. A hard link would work if it wasn't that > mutt wipes the file before unlinking it. > I guess not. If I understand correctly, the file will remain alive while its link count of the file is possitive. Even if mutt deletes (it's link), the other link (and the file) will survive. Regards, Luis
Re: mutt deletes attachement before libreoffice tries to open it
David, Thanks for the suggestion! Luis On Fri, Jun 22, 2012 at 12:50:02PM -0500, David Champion wrote: > * On 22 Jun 2012, Luis Mochan wrote: > > I guess a solution used for browsing html attachments (discussed > > here some time ago; see attached perl script) may be adapted for > > running libreoffice. The main idea would be to make a copy of the > > file, send it to libreoffice and sleep a short time before returning > > to mutt, > > I usually recommend hard linking (not symbolic linking!) over copying, > if possible. > > -- > David Champion • d...@uchicago.edu • IT Services • University of Chicago -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Apdo. Postal 48-3, 62251 | (*)/\/ \ Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Re: mutt deletes attachement before libreoffice tries to open it
On 2012-06-22, David Champion wrote: > * On 22 Jun 2012, Luis Mochan wrote: > > I guess a solution used for browsing html attachments (discussed > > here some time ago; see attached perl script) may be adapted for > > running libreoffice. The main idea would be to make a copy of the > > file, send it to libreoffice and sleep a short time before returning > > to mutt, > > I usually recommend hard linking (not symbolic linking!) over copying, > if possible. But that would defeat the purpose of the copy which is to have a stable file for LibreOffice to read while allowing mutt to wipe and delete its temporary file. A hard link would work if it wasn't that mutt wipes the file before unlinking it. Regards, Gary
Re: mutt deletes attachement before libreoffice tries to open it
* On 22 Jun 2012, Luis Mochan wrote: > I guess a solution used for browsing html attachments (discussed > here some time ago; see attached perl script) may be adapted for > running libreoffice. The main idea would be to make a copy of the > file, send it to libreoffice and sleep a short time before returning > to mutt, I usually recommend hard linking (not symbolic linking!) over copying, if possible. -- David Champion • d...@uchicago.edu • IT Services • University of Chicago
Re: previous-entry / next-entry at one entry per key press
* Cameron Simpson [120622 08:58]: > On 21Jun2012 13:24, John Magolske wrote: > | Ok, I gave this a try...checking to make sure my modified terminfo > | is being read: > | > | % TERM=$TERM-mutt > | % echo $TERM > | screen.linux-mutt > | % infocmp $TERM | grep kMSG > | il=\E[%p1%dL, il1=\E[L, ind=^J, is2=\E)0, kMSG=\EOC\EOC, > | > | Then launched mutt with `TERM=$TERM-mutt mutt` ...but it didn't work. > | I saw the same behavior as before -- holding down in the pager > | zips through a rapid succession of messages. > > Did you check the value of $TERM within mutt? For example by opening a > subshell and echoing it and your infocmp command? Yes, I checked this in a subshell within the mutt instance launched via `TERM=$TERM-mutt mutt` and got the same response: Shell command: echo $TERM screen.linux-mutt Shell command: infocmp $TERM | grep kMSG il=\E[%p1%dL, il1=\E[L, ind=^J, is2=\E)0, kMSG=\EOC\EOC, John -- John Magolske http://B79.net/contact
Re: mutt deletes attachement before libreoffice tries to open it
Thanks Chris! You're right (it was a fast translation from Spanish). Regards, Luis On Sat, Jun 23, 2012 at 04:57:04AM +1200, Chris Bannister wrote: > On Fri, Jun 22, 2012 at 09:38:10AM -0500, Luis Mochan wrote: > > # DESCRIPTION > > # Runs a browser on a copy of a file, and sleeps for a while > > # before deleting it. It solves the problem that mutt may delete > > # the file too fast. > > IMHO, change "fast" to "soon". The *speed* of deletion is not the issue > but *when* it is deleted. > > -- > "If you're not careful, the newspapers will have you hating the people > who are being oppressed, and loving the people who are doing the > oppressing." --- Malcolm X -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Apdo. Postal 48-3, 62251 | (*)/\/ \ Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Re: mutt deletes attachement before libreoffice tries to open it
On Fri, Jun 22, 2012 at 09:38:10AM -0500, Luis Mochan wrote: > # DESCRIPTION > # Runs a browser on a copy of a file, and sleeps for a while > # before deleting it. It solves the problem that mutt may delete > # the file too fast. IMHO, change "fast" to "soon". The *speed* of deletion is not the issue but *when* it is deleted. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X
Re: mutt deletes attachement before libreoffice tries to open it
I guess a solution used for browsing html attachments (discussed
here some time ago; see attached perl script) may be adapted for
running libreoffice. The main idea would be to make a copy of the
file, send it to libreoffice and sleep a short time before returning
to mutt,
Regards,
Luis
On Fri, Jun 22, 2012 at 10:52:08AM -0300, Marcelo Laia wrote:
> Hi
>
> 2012/6/22 steve :
> > Have you found a solution?
>
> Unfortunately, no!
>
>
> --
> Marcelo Luiz de Laia
--
o
W. Luis Mochán, | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\
Apdo. Postal 48-3, 62251 | (*)/\/ \
Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
#!/usr/bin/env perl
use warnings;
use strict;
# SYNOPSIS
# mutt_browse file
#
# DESCRIPTION
# Runs a browser on a copy of a file, and sleeps for a while
# before deleting it. It solves the problem that mutt may delete
# the file too fast.
# EXAMPLE
# To use a sensible browser to view HTML attachments from mutt, add the
# following line to the .mailcap file.
#
# text/html; /path/to/mutt_browse %s
#
# AUTHOR
# Luis Mochan
# Shamelessly adapted from mutt_netscape by
# Gary A. Johnson
#
# WARNING
# This program has been tested in a Debian system
# The temporal file is created in the /tmp directory
#
# Variables to be customized
#
# template filename for temporal file
my $template="muttX";
# Path to desired browser. Under Debian sensible-browser defaults to
# my prefered browser, but an explicit choice such as chrome,
# iceweasel, etc. may be used here.
my $browser="/usr/bin/sensible-browser";
# Delay to give time for browser to read file before it is destroyed
my $delay=3; #in seconds
#
# End of customizations
use File::Temp qw(tempfile);
die <<"EOF" unless @ARGV==1;
Usage $0 file
to run a sensible-browser over copy of file
EOF
die "Can't read $ARGV[0]" unless -r $ARGV[0];
my ($fh, $fname) = tempfile($template, DIR=>"/tmp", SUFFIX=>".html",
UNLINK=>1);
open IN, "<", $ARGV[0];
while(){
print $fh $_;
}
close $fh;
system $browser, $fname;
sleep $delay;
Re: mutt deletes attachement before libreoffice tries to open it
Hi 2012/6/22 steve : > Have you found a solution? Unfortunately, no! -- Marcelo Luiz de Laia
Re: previous-entry / next-entry at one entry per key press
On 21Jun2012 13:24, John Magolske wrote: | Ok, I gave this a try...checking to make sure my modified terminfo | is being read: | | % TERM=$TERM-mutt | % echo $TERM | screen.linux-mutt | % infocmp $TERM | grep kMSG | il=\E[%p1%dL, il1=\E[L, ind=^J, is2=\E)0, kMSG=\EOC\EOC, | | Then launched mutt with `TERM=$TERM-mutt mutt` ...but it didn't work. | I saw the same behavior as before -- holding down in the pager | zips through a rapid succession of messages. I intend a longer response soon but lack the time now. Particular to the above, that sequence ends up with running mutt with TERM=$TERM-mutt-mutt assuming it is exactly as written. Maybe: muttTERM=$TERM-mutt TERM=$muttTERM mutt Did you check the value of $TERM within mutt? For example by opening a subshell and echoing it and your infocmp command? Also, I don't know how sophisticated the curses "recognise long key sequences" code is; my here suggestion may be fatally flawed anyway. -- Cameron Simpson
Re: mutt deletes attachement before libreoffice tries to open it
Hi, Le 26-04-2012, à 08:07:42 -0300, Marcelo Luiz de Laia (marcelol...@gmail.com) a écrit : > On Thu, 26 Apr 2012, Jostein Berntsen wrote: > > > It seems like most of your entries are bound to openoffice(soffice) instead > > of libreoffice. Try to change all entries to libreoffice instead. > > > > Jostein > > > > Thank you very much, but, it dosen't solve that problem. > > If libreoffice is alread running, I coundn't open the attachment. I fell on your post while searching the web for a solution to the exact same issue than yours. This problem arises only when trying to open a document with libreoffice while libreoffice is already opened. Have you found a solution? I'm running mutt 1.5.21 on Debian wheezy. Thank you. Best regards, Steve
Re: mail relaying
Hello, On Thu, Jun 21, 2012 at 05:06:40PM -0700, jeremy bentham wrote: > instant "connection refused", with either smtp > or smtps, ssl_starttls yes or no. I've checked ports on mail.eskimo.com with nmap: > PORT STATESERVICE > 25/tcp open smtp > 465/tcp closed smtps > 587/tcp filtered submission > 2525/tcp open unknown So you should rather try "smtp://u...@mail.eskimo.com:25" "smtp://u...@mail.eskimo.com:2525" "smtps://u...@mail.eskimo.com:2525" -- With best regards, xrgtn signature.asc Description: Digital signature
