Re: Is mutt really handicapped?

2002-03-08 Thread Simon White

On 07-Mar-02 at 16:26, Michael P. Soulier's inspired musing was thus :
 Who uses the arrow keys?? hjkl man...

As someone who can actually touch type and without looking at the keys even,
it has always seemed stupid for vi to use hjkl, since this forces my hand out
of the home position, where my fingers will be on jkl; 

I learned to touch type by quite literally forcing myself. I have used a PC
keyboard for 16 years and one day decided it was stupid to be in front of a
keyboard all day and not to try to type properly. Sure, it's slower to begin
with, but now I can type much faster.

-- 
|-Simon White   # GIMPS current unit progress: 31.22% #-|
|-Internet Services Manager #  http://www.mersenne.org/prime.htm #-|
|-MTDS S.A. 14, rue 16 novembre:-Pd-;  tel: +212.3.737.4861-|
|-Rabat, Kingdom of Morocco  Cyberneckin'  fax: +212.3.737.4863-|



Re: About the language for the mutt config tool

2002-03-08 Thread Erika Pacholleck

[08.03.02 00:03 +0100] Marco Fioretti -- :
 About this particular project: let's just do it in whatever language
 the majority of the volunteers is ALREADY proficient with, not with the one
 which the majority of the list thinks better for any reason.

I do not agree to this, one thing I would ask you to consider:

Take a language which you can expect to be present on minimal systems.
Otherwise you might end up in dependencies which are no advantage for
mutt. One of the advantages of console progs is that they do not need
hundreds of extra languages installed to get them going.

Speaking of installing a distro (which most beginners would do) those
are already blown up enough, now imagine you would for example need
a jre just for the mutt config tool .. -- speaking of compiling mutt
yourself (which more experienced would do but which does not mean that
they understand all the muttrc values) is even worse if (often seen)
the documentation does not mention all dependencies. And as a result of
that, it might happen that a user of netscape/kde/pine.. who has heard
of mutts capabilities and wants to try that, will stay with his old
one because the only alternate to those depencies would be vim+manual.

Viewing from this point, perl would be a good choice and as far as I
saw from former postings it might turn out to become perl.
-- 
Erika Pacholleck [EMAIL PROTECTED]
mutters: insert vowels of last name



Re: About the language for the mutt config tool

2002-03-08 Thread Marco Fioretti

 [08.03.02 00:03 +0100] Marco Fioretti -- :
  About this particular project: let's just do it in whatever language
  ..
 I do not agree to this, one thing I would ask you to consider:

 Take a language which you can expect to be present on minimal systems.

Why, yes, of course! I was giving that for granted because we were speaking of console 
tools, and I assumed (wrongly) it meant the same
thing

Marco Fioretti





Re: About the language for the mutt config tool

2002-03-08 Thread John Buttery

On Fri, Mar 08, 2002 at 09:54:11AM +0100, Erika Pacholleck wrote:
[08.03.02 00:03 +0100] Marco Fioretti -- :
 About this particular project: let's just do it in whatever language
 the majority of the volunteers is ALREADY proficient with, not with the one
 which the majority of the list thinks better for any reason.

I do not agree to this, one thing I would ask you to consider:

Take a language which you can expect to be present on minimal systems.
Otherwise you might end up in dependencies which are no advantage for
mutt. One of the advantages of console progs is that they do not need
hundreds of extra languages installed to get them going.

Speaking of installing a distro (which most beginners would do) those
are already blown up enough, now imagine you would for example need
a jre just for the mutt config tool .. -- speaking of compiling mutt
yourself (which more experienced would do but which does not mean that
they understand all the muttrc values) is even worse if (often seen)
the documentation does not mention all dependencies. And as a result of
that, it might happen that a user of netscape/kde/pine.. who has heard
of mutts capabilities and wants to try that, will stay with his old
one because the only alternate to those depencies would be vim+manual.

Viewing from this point, perl would be a good choice and as far as I
saw from former postings it might turn out to become perl.
-- 
Erika Pacholleck [EMAIL PROTECTED]
mutters: insert vowels of last name

  I agree with this logic; there's nothing that this shell script needs
to do that can't be done with a Bourne shell script.  That's the one
interpreter you're always guaranteed to have.  Now, having said that, I
would imagine that most systems that have mutt installed will also have
perl... :)

-- 

 John Buttery
 (Web page temporarily unavailable)




msg25189/pgp0.pgp
Description: PGP signature


Re: use another email address

2002-03-08 Thread Heiko Heil

On Thu, Mar 07, 2002 at 05:26:18PM -0600, Knute wrote:
 [...]
   macro index F5 'compose\n set my_hdr From: [EMAIL PROTECTED]enter'

macro index f5 :my_hdr From: Tux Tucker [EMAIL PROTECTED]\n
-- 
Cheers,
Heiko Heil



msg25190/pgp0.pgp
Description: PGP signature


Re: About the language for the mutt config tool

2002-03-08 Thread Dan Boger

On Fri, Mar 08, 2002 at 12:03:56AM +0100, Marco Fioretti wrote:
 So, what language do the volunteers know better?

I'll defenitly help if it's in perl, and will probably be useless in
python.

:)

-- 
Dan Boger
[EMAIL PROTECTED]



msg25191/pgp0.pgp
Description: PGP signature


Re: From: header quotes

2002-03-08 Thread David T-G

Eduardo --

...and then [EMAIL PROTECTED] said...
% 
% On Thu, Mar 07, 2002 at 03:51:57PM -0500, David T-G wrote:
%  
%  variables, unset MAILNAME and try writing a From: line with my_hdr and
%  see what you get.
...
% folder-hook ~/users/mutt my_hdr From: Eduardo Gargiulo [EMAIL PROTECTED]
% 
% in my .muttrc. When i run mutt and write a message, i can see this
% header, but wen i send the message (like this) the MAILNAME part of the
% From header disapear. How can i fix this?

Hmmm...  I'm not using it so I don't know why it should be necessary for
you, but you might try setting $realname to see what you get.


% 
% ~ejg


:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg25192/pgp0.pgp
Description: PGP signature


Re: About the language for the mutt config tool

2002-03-08 Thread darren chamberlain

I'm going to reply to a bunch of messages all at once.  I'm
attaching my first quick attempt at a configuration script; I've
called mutt-makeconfig, for lack of a better name.   It's very
brute force, but it works.  The config is very basic, enough to
get the bare minimum of personalized part of the process done
(ie, it sets realname, from, alternates, editor, folder,
mbox_type, print_command, and sendmail).  It's written in perl,
uses only standard (5.00505+) modules, and runs reasonably fast.
The options it takes are --muttrc (where it should write the
file, default /tmp/muttrc-$USER) and --color (a useless option to
make it purty).

And, just so everyone knows, I'm not really attached to the
script, they way it does things, the language it's written in, or
the choice of colors on the screen, so spare no flames. :)

Quoting Will Yardley [EMAIL PROTECTED] in 
[EMAIL PROTECTED]:
 regarding cvs space, i've never setup a cvs pserver before; i'm
 assuming this will be the easiest way to offer anonymous CVS
 access.  i doubt it's that hard to setup though.

Anonymous CVS access is not enough, because the folks working on
it will need write access; that means user accounts.  If we make
it a sourceforge project, then all the hard work is handled for
us, at least in that department.

Quoting Michael Maibaum [EMAIL PROTECTED] in 
[EMAIL PROTECTED]:
 That is OK for read access, dubious for write access(which
 should be by ssh probably), add a cvs module to the mutt.newbie
 project at sourceforge?

This was my thought, either attach ourselves to the mutt-newbie
project or start a new project on sourceforge.

Quoting Erika Pacholleck [EMAIL PROTECTED] in [EMAIL PROTECTED]:
 Take a language which you can expect to be present on minimal
 systems.  Otherwise you might end up in dependencies which are
 no advantage for mutt. One of the advantages of console progs
 is that they do not need hundreds of extra languages installed
 to get them going.

Yes.  Similarly:

Quoting John Buttery [EMAIL PROTECTED] in [EMAIL PROTECTED]:
 I agree with this logic; there's nothing that this shell script
 needs to do that can't be done with a Bourne shell script.
 That's the one interpreter you're always guaranteed to have.

I agree entirely.  sh is the most likely candidate, if we are
going for it to run absolutely everywhere (I'd say awk would be
the second, followed by perl).  The script I've written doesn't
too (too many) Perl-ish things and should be strightforward to
port to whatever languagewe decide to use, if that's what is
wanted.

(darren)

--
The Feynman Problem   1) Write down the problem.
Solving Algorithm 2) Think real hard.
  3) Write down the answer.


#!/usr/bin/perl

# --
# $Id$
# --
# Inital version by darren chamberlain [EMAIL PROTECTED]
# --

use strict;
use vars qw| $VERSION |;

use Sys::Hostname;  # To determine the hostname
use Text::Wrap;

# --
# Set defaults and local (script-level) variables.
# --
$VERSION = sprintf %d.%02d, q$Revision: 1.1 $ =~ /(\d+)\.(\d+)/;
my $Muttrc = /tmp/muttrc-$ENV{USER};
my $help_only = undef;

# Normally, doing colors this way is kinda dumb; ANSI::Term and friends
# were designed to do this, but I wanted to ensure that no external
# modules were needed here.  Besides, you have to explicitly ask for
# color, so by default nothing bad will happen.
my $color = undef;
my $red   = ;
my $blue  = ;
my $green = ;
my $norm  = ;

# $ENV{COLUMNS} is some sh magic.  COLUMNS is usually only defined when
# running under X, but we rely on it a little later, so we define
# it if it isn't already defined.  Note that this does not propogate
# outwards to the parent process, so we're OK here.
$Text::Wrap::columns = $ENV{COLUMNS} ||= 80;

# --
# Get command line options, using the standard Getopt::Long module.
# --
use Getopt::Long;
GetOptions(
muttrc=s = \$Muttrc,
color!   = \$color,
help!= \$help_only,
);

# Perhaps nocolor should be the default?
if (defined $color) {
$red   = ;
$blue  = ;
$green = ;
$norm  = ;
}

my @config = ();# Lines that will become the config file
my %env = ();   # Elements that will become the values

# ==
# main
# ==
populate_from_environment(\%env);

# --
# This is the banner, our short introduction to 

Re: How to display texts encoded in UTF-8?

2002-03-08 Thread Roman Neuhauser

 Date: Sat, 2 Mar 2002 08:34:50 +0800
 From: Charles Jie [EMAIL PROTECTED]
 To: mutt [EMAIL PROTECTED]
 Subject: How to display texts encoded in UTF-8?
 
 Hi,
 
 My linux box has locale zh_TW.Big5 (Traditional Chinese). I have the
 following settings in .muttrc and it works well in most of the cases.
 
 set charset=big5
 charset-hook  big5  # for the mail missing 'charset'
 
 But from time to time, I may get mail from MUA that encodes in UTF-8.
 Then the pager would fail to display.
 
 Could anybody give a hand? I can not find solution in manual.txt.

Hi Charles,

this is what I get when I grep my .muttrc for 'charset':

set charset = iso-8859-2
set send_charset = us-ascii:iso-8859-2:utf-8

and utf-8 messages are displayed just fine. Makes me think you
should be looking elsewhere. Sorry for not having an answer.

-- 
FreeBSD 4.4-STABLE
5:02PM up 8 days, 18:10, 9 users, load averages: 0.03, 0.02, 0.00



Re: About the language for the mutt config tool

2002-03-08 Thread Mike Erickson

* darren chamberlain ([EMAIL PROTECTED]) wrote:
 I'm going to reply to a bunch of messages all at once.  I'm
 attaching my first quick attempt at a configuration script; I've
 called mutt-makeconfig, for lack of a better name.   It's very
 brute force, but it works.  The config is very basic, enough to
 get the bare minimum of personalized part of the process done
 (ie, it sets realname, from, alternates, editor, folder,
 mbox_type, print_command, and sendmail).  It's written in perl,
 uses only standard (5.00505+) modules, and runs reasonably fast.
 The options it takes are --muttrc (where it should write the
 file, default /tmp/muttrc-$USER) and --color (a useless option to
 make it purty).

I think a major improvement would be to store the configuration file
(sorry for the buzzword) metainfo seperately.

Have a parsable file containg the options, possible values, and
description. This will make adding new configuration directives much
easier than writing (and reusing) code for each one. Opinions?

 And, just so everyone knows, I'm not really attached to the
 script, they way it does things, the language it's written in, or
 the choice of colors on the screen, so spare no flames. :)

IT SUCKS! :)

 Quoting Will Yardley [EMAIL PROTECTED] in 
[EMAIL PROTECTED]:
  regarding cvs space, i've never setup a cvs pserver before; i'm
  assuming this will be the easiest way to offer anonymous CVS
  access.  i doubt it's that hard to setup though.
 
 Anonymous CVS access is not enough, because the folks working on
 it will need write access; that means user accounts.  If we make
 it a sourceforge project, then all the hard work is handled for
 us, at least in that department.

sf.net was /made/ for this sort of project. It seems a shame not to use
it.

[...]
 I agree entirely.  sh is the most likely candidate, if we are
 going for it to run absolutely everywhere (I'd say awk would be
 the second, followed by perl).  The script I've written doesn't
 too (too many) Perl-ish things and should be strightforward to
 port to whatever languagewe decide to use, if that's what is
 wanted.

I vote Perl, but it looks like that's the programming lingua franca for
this list anyhow.

 The Feynman Problem   1) Write down the problem.
 Solving Algorithm 2) Think real hard.
   3) Write down the answer.

Have you read /Genius/ by James Gleick? Great book.

/me sees the ball start to rock...

mike

ps: Coincidentily, I'm in the process of developing an ancillary tool
for people trying to get GPG+mutt working fast and easy.



Re: About the language for the mutt config tool

2002-03-08 Thread darren chamberlain

Quoting Mike Erickson [EMAIL PROTECTED] [Mar 08, 2002 11:51]:
 I think a major improvement would be to store the configuration
 file (sorry for the buzzword) metainfo seperately.

*nod*

 Have a parsable file containg the options, possible values, and
 description. This will make adding new configuration directives
 much easier than writing (and reusing) code for each one.
 Opinions?

I tried that, but there seemed to be too many variations for it
to be done in a way that (a) didn't take more than a hour or two
(I was doing this on the train home last night ;), (b) could be
easily ported to another language if we decide to not use Perl,
and (c) took all the possibilities into consideration (other than
string-based, boolean, and quad-options, there's the issue of
alternates, which takes 0 or more addresses and makes a regex --
too hard to do in a generic way, without making each directive be
code that gets evaluated at run time, which is cake for Perl but
starts to become Perl only very quickly... ;).

I like the mon does things:  a master script that calls other
scripts, and expects the script to send its results to STDOUT.
We could do this, make what I wrote a shell script that basically
does:

  for file in config/*; do
results=`$i`
echo $results  $new_muttrc
  done

And the individual config modules can just pull everything from
%ENV (or os.environ or getenv() or whatever is appropriate).

 ps: Coincidentily, I'm in the process of developing an
 ancillary tool for people trying to get GPG+mutt working fast
 and easy.

Cool!  Can it be integrated, and, if not, can you send me a URL?
I keep procrastinating...

(darren)

-- 
The rebootings will continue until the configuration works.



Re: About the language for the mutt config tool

2002-03-08 Thread Will Yardley

darren chamberlain wrote:
 
 This was my thought, either attach ourselves to the mutt-newbie
 project or start a new project on sourceforge.

yeah that might be the best idea.
 
a few comments... the script looks like a good starting place. eek i
probably should have put line numbers on it somehow sorry.

i'm glad to see someone putting their money where their mouth is and
making some code :  if some other people contribute, i'm sure we'll
have a very helpful tool (that's _hopefully_ easy to use) in no time.

does it create a backup if ~/.muttrc exists? doesn't look that way -
that might be a good idea.

 # folder
 #   Where to put read mail by default (set folder=~/Mail)

i was envisioning checking to see if ~/Mail, ~/mail or both exist (or
don't exist) - then if only one exists that would be suggested as the
default; if both exist or don't exist, ~/Mail would be suggested.

 #   Where to put read mail (set mbox=~/mbox)

this might be a good place to also deal with move (yes or no) - ie
check first if they WANT to move mail after reading.

another common gotcha is that a lot of people don't like 'mark_old' - so
we might want to explain this variable and let people unset it.

  /usr/sbin/sendmail -oem -oi);

not sure about this one - most people will want the default, but then
the real newbies might not want to use sendmail at all - i'm thinking
that giving people a chance to mess up the default flags to sendmail
might be bad though - perhaps better to offer to setup one of the really
lightweight sendmail replacements for them?  does the one that's written
in perl actually work?

ie do you have an MTA like sendmail, postfix, or qmail configured on
your system? if not, choose 'n', and we'll explain your options.
however this might be a little outside of the scope of the project.
thoughts?

 $env-{username}  = $pw[0];
 $env-{realname}  = $gecos[0];
 $env-{hostname}  = hostname();
 $env-{mailspool} = $ENV{MAIL};
 $env-{editor}= $ENV{VISUAL} || $ENV{EDITOR} || builtin;

excellent.  also, the script might want to suggest 'nano -t' or 'pico
-t' for newbies or people who are used to pine (even if $EDITOR is set
to something else).
 
 Is user a pine or elm user?  Offer contrib/{Pine,Tin}.rc keybindings

yes! i think that the suggestion to take the keybindings itself should
be modular somehow.  also i think there is a more comprehensive set of
pine keybindings somewhere (maybe on sven's page) - the one in contrib/
only covers really basic stuff.  for instance the main pine keybinding
that i'm attached to is ',' - i have this binding, which isn't quite
right, but close:

bind pager , exit
macro index , change-folder?tab

probably best to check for ~/.pinerc ~/.tin/ ~/.elm/ ~/.elm/ etc... if
more than one exists, ask for each.

is there any other data that we need in the template, or could it just
be as simple as copying contrib/blah.rc over?
 
 3. POP, IMAP, PGP, SSL, etc

i think that IMAP might need to be integraded with spoolfile and folder
collection (ie if you're usng POP3 or IMAP should be one of the first
questions, and should influence the rest of the process).

some more advanced features we _might_ want to ask about. these are
my settings (which mostly differ from the default... i'm sure everyone
has a favorite feature and this list might start to get too long, but i
think we should ask about some / most of these)

* lists? i found the 'lists' feature confusing at first, but it's also one
of the best things about mutt. maybe at least offer a simple explanation
and stick some examples (commented) in the file?

* set delete=yes

* unset confirmappend

* unset mark_old (above)

* smart_wrap / unset markers, etc (wrap settings)

* MAYBE configuring a simple .mailcap for them to view html (if they
don't already have a .mailcap)

* weed settings (which headers to show perhaps offer a sensible
default for this, explaining how to change it???)

* maybe test for programs like enscript, etc on the system, and offer them
as suggestsions if they exist?

-- 
Will Yardley
william  newdream . net




Problems sending large attachments

2002-03-08 Thread Jim Quigley

Problems sending large attachments?

I have a P111 notebook with over 300MB memory, using a pcmcia modem running 
on Redhat 7.2.  I use Kmail 1.3.2 on KDE 2.2.2-1 and Mutt 1.3.25i .  I have 
used sendmail-8.11.6-3 and have configured Kmail and mutt to use this

I can send emails with small attachments, receive emails even with large 
attachments but when I try to send large attachments around 40 KB and over 
using either ./sendmail -v -q or Kmail's smtp server, I get error messages, 
and the connection freezes.   Mutt sends the mail to mqueue and when I use 
sendmail -q the connection stalls.

This has happened with different desktops, different distros i.e. Redhat and 
SuSE 7.3.  I have no problem when I use Windows, so it is not the ISP.  Could 
it be a problem with 'wvdial.conf' or some other configuation file, limiting 
the size of message I can send?  I have spent alot of time searching for 
answers and using different configuration of sendmail but unfortunately 
without joy.  

Is this a problem with linux,  I need to send large attachments sometimes 
from home to work.  Do I need to keep Windows installed?

Jim








[OT] Re: Setting the hostname used in HELO

2002-03-08 Thread Charles Cazabon

MuttER [EMAIL PROTECTED] wrote:
  
   No, it would mask your problem (`man band-aid`).  The real solution is
   to configure your MTA to use an acceptable argument to the HELO
   command, or to tell it to forward your mail to your ISP's smarthost.
   This is possible with sendmail or any other MTA.
 
 Where do I 'configure my MTA to use an acceptable argument to the
 HELO COMMAND ??

If you're running qmail, it's set in the control file helohost.  If you're
running sendmail, I haven't the foggiest idea, but it's probably buried
somewhere in that 1000+ line monstrosity known as sendmail.cf.

Charles
-- 
---
Charles Cazabon [EMAIL PROTECTED]
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
---



Re: Problems sending large attachments

2002-03-08 Thread Joel Hammer

I don't use a modem anymore, but:
It seems very unlikely that this is a limitation of linux. You would not be
the first one to notice this problem.
Does this happen with ftp?
What is the error message you are getting?
Maybe your ISP doesn't like what your linux modem driver is doing. 
This link may be interesting:

http://www.linuxdoc.org/HOWTO/Modem-HOWTO-17.html#ss17.4

Joel

 Problems sending large attachments?
 
 I have a P111 notebook with over 300MB memory, using a pcmcia modem running 
 on Redhat 7.2.  I use Kmail 1.3.2 on KDE 2.2.2-1 and Mutt 1.3.25i .  I have 
 used sendmail-8.11.6-3 and have configured Kmail and mutt to use this
 
 I can send emails with small attachments, receive emails even with large 
 attachments but when I try to send large attachments around 40 KB and over 
 using either ./sendmail -v -q or Kmail's smtp server, I get error messages, 
 and the connection freezes.   Mutt sends the mail to mqueue and when I use 
 sendmail -q the connection stalls.
 
 This has happened with different desktops, different distros i.e. Redhat and 
 SuSE 7.3.  I have no problem when I use Windows, so it is not the ISP.  Could 
 it be a problem with 'wvdial.conf' or some other configuation file, limiting 
 the size of message I can send?  I have spent alot of time searching for 
 answers and using different configuration of sendmail but unfortunately 
 without joy.  
 
 Is this a problem with linux,  I need to send large attachments sometimes 
 from home to work.  Do I need to keep Windows installed?
 
 Jim
 
 
 
 



Re: [OT] Re: Setting the hostname used in HELO

2002-03-08 Thread MuttER

* Charles Cazabon [EMAIL PROTECTED] [03-08-02 19:52] crowed:
 MuttER [EMAIL PROTECTED] wrote:
   
No, it would mask your problem (`man band-aid`).  The real solution is
to configure your MTA to use an acceptable argument to the HELO
command, or to tell it to forward your mail to your ISP's smarthost.
This is possible with sendmail or any other MTA.
  
  Where do I 'configure my MTA to use an acceptable argument to the
  HELO COMMAND ??
 
 If you're running qmail, it's set in the control file helohost.  If you're
 running sendmail, I haven't the foggiest idea, but it's probably buried
 somewhere in that 1000+ line monstrosity known as sendmail.cf.

I am running postfix.
-- 
Pat Shanahan  Registered Linux User #207535
   Registered at: http://counter.li.org
  9:20pm  up 19 days, 11:53,  6 users,  load average: 0.21, 0.31, 0.23



Re: [OT] Re: Setting the hostname used in HELO

2002-03-08 Thread Knute

On Fri, 08 Mar 2002, Charles Cazabon wrote:

 MuttER [EMAIL PROTECTED] wrote:
   
No, it would mask your problem (`man band-aid`).  The real solution is
to configure your MTA to use an acceptable argument to the HELO
command, or to tell it to forward your mail to your ISP's smarthost.
This is possible with sendmail or any other MTA.

  Where do I 'configure my MTA to use an acceptable argument to the
  HELO COMMAND ??

 If you're running qmail, it's set in the control file helohost.  If you're
 running sendmail, I haven't the foggiest idea, but it's probably buried
 somewhere in that 1000+ line monstrosity known as sendmail.cf.

So read the man page for whatever MTA you are using to find out what the
name of the config file is, then you can issue the command (in my case
for exim):
cat /etc/exim/exim.conf |grep helo

It will show you the line and what variable you need to be looking for.

--
Knute

I like greps.  Especially the green ones! :)



msg25203/pgp0.pgp
Description: PGP signature


Re: [OT] Re: Setting the hostname used in HELO

2002-03-08 Thread MuttER

* Knute [EMAIL PROTECTED] [03-08-02 21:47] crowed:
 On Fri, 08 Mar 2002, Charles Cazabon wrote:
 
  MuttER [EMAIL PROTECTED] wrote:

 No, it would mask your problem (`man band-aid`).  The real solution is
 to configure your MTA to use an acceptable argument to the HELO
 command, or to tell it to forward your mail to your ISP's smarthost.
 This is possible with sendmail or any other MTA.
 
   Where do I 'configure my MTA to use an acceptable argument to the
   HELO COMMAND ??
 
  If you're running qmail, it's set in the control file helohost.  If you're
  running sendmail, I haven't the foggiest idea, but it's probably buried
  somewhere in that 1000+ line monstrosity known as sendmail.cf.
 
 So read the man page for whatever MTA you are using to find out what the
 name of the config file is, then you can issue the command (in my case
 for exim):
   cat /etc/exim/exim.conf |grep helo
 
 It will show you the line and what variable you need to be looking for.

:~ grep -i helo /etc/sendmail.cf
O PrivacyOptions=authwarnings,needmailhelo,novrfy,noexpn,noverb
#O Timeout.helo=5m
# Allow HELO SMTP command that does not include a host name
#O AllowBogusHELO=False
O Milter.macros.helo={tls_version}, {cipher}, {cipher_bits},{cert_subject}, 
{cert_issuer}

??
-- 
Pat Shanahan  Registered Linux User #207535
   Registered at: http://counter.li.org
  9:52pm  up 19 days, 12:25,  6 users,  load average: 0.03, 0.18, 0.24



Re: [OT] Re: Setting the hostname used in HELO

2002-03-08 Thread Timothy R. Robnett

On Fri Mar 08, 2002 at 09:20:39PM -0500, MuttER wrote:
 * Charles Cazabon [EMAIL PROTECTED] [03-08-02 19:52] crowed:
  MuttER [EMAIL PROTECTED] wrote:

 No, it would mask your problem (`man band-aid`).  The real solution is
 to configure your MTA to use an acceptable argument to the HELO
 command, or to tell it to forward your mail to your ISP's smarthost.
 This is possible with sendmail or any other MTA.
   
   Where do I 'configure my MTA to use an acceptable argument to the
   HELO COMMAND ??
  
  If you're running qmail, it's set in the control file helohost.  If you're
  running sendmail, I haven't the foggiest idea, but it's probably buried
  somewhere in that 1000+ line monstrosity known as sendmail.cf.
 
 I am running postfix.

My postfix server has this in main.cf
myhostname = polycarp.robnett.net

I would bet that the $myhostname combined with valid forward and reverse DNS would do 
the trick.

Tim