Re: mutt native SMPT support vs Postfix?
On Sun, Jan 05, 2014 at 02:25:16PM +0800, Chris Down wrote: > Well, that's exactly what I was recommending -- using something like > sendmail over something which is designed for far more (Postfix). Sendmail and Postfix are both MTAs, they both do (essentially) the same thing. Cheers, Tom -- PIZZA!! signature.asc Description: Digital signature
Re: mutt native SMPT support vs Postfix?
On Sun, Jan 05, 2014 at 08:48:50AM +1100, Cameron Simpson wrote: > On 04Jan2014 20:01, Matthias Apitz wrote: > > El día Sunday, January 05, 2014 a las 02:50:12AM +0800, Chris Down escribió: > > > On 2014-01-04 19:35:19 +0100, Ulrich Lauther wrote: > > > > Recent posts made me aware of the fact, that mutt supports SMPT. > > > > So far I have been using postfix for mail transport. > > > > Which way is better, and why? > > > > > > "Better" is subjective. Using Postfix for this is pretty heavy duty over > > > using a purpose-built MTA. > > > > I'm using mutt (right now by typing) on my FreeBSD netbook, connected > > via UMTS WAN to my ISP. My mutt drops the mail (this mail) to the local > > MTA (sendmail) and this takes care for the transport to the next MX hop, > > even if the WAN link is down; the mail gets queued until the link comes > > up again. I think this, queuing, is a big advantage over talking SMTP > > directly by mutt. > > I agree. I'm running postfix on my Mac (it ships with postfix installed). > Local queuing. Automatic retry accordidng to a sensible policy. > > AND:... All the local systems that send email (eg cron and innumerable > shell scripts) can send email via the UNIX standard "sendmail" > executable. > > Use a real mail system locally. A win. unless you try to do something like multiple email providers for one user which is very easy to do with anything but sendmail/postfix/exim. I have done this on all three and got tired, after every system upgrade some incompatible change breaks it and even the most basic smarthost configuration stops working, not to mention the multiple accounts which always required some configuration acrobatics. Also, having mail comming from mutt going through postfix to a smarthost generates headers which increase the spam score of your email dramatically because the headers are very similar (or practically indisinguishable) to headers that would appear from an open relay. If mail queueing is a requirement esmtp has it. Although it needs fixing to work reliably it is still much easier than configuring one of the big programs. I would not touch sendmail/postfix/exim again unless I want to run a real public mail server. Richard --- Name and OpenPGP keys available from pgp key servers
Re: mutt native SMPT support vs Postfix?
* Richard Z [01-05-14 08:57]: [...] > unless you try to do something like multiple email providers for one > user which is very easy to do with anything but sendmail/postfix/exim. > I have done this on all three and got tired, after every system upgrade > some incompatible change breaks it and even the most basic smarthost > configuration stops working, not to mention the multiple accounts which > always required some configuration acrobatics. I have been doing this for *many* years with miniminal intervention across many versions of linux, mostly SuSE/openSUSE w/o problems using postfix/fetchmail/procmail/spamassassin. Postfix and/or most other mta's also provide the use of rbl's to help minimize spam. In November last I had to replace my server box witch intailed a four version upgrade/jump and all I really did to the mail system was clean up /etc/postfix/main.cf and /etc/postfix/access of stale and mostly commented out ancient text from prior *experiments*. [...] > I would not touch sendmail/postfix/exim again unless I want to run a > real public mail server. Somewhere you have encountered major weird problems or I have experienced the "luck of a drunken Irishman" (which I may be). And by no means can I be considered of guru status, maybe a forgotten, neglected stepchild with leprosy. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: mutt native SMPT support vs Postfix?
El día Sunday, January 05, 2014 a las 09:16:02AM -0500, Patrick Shanahan escribió: > * Richard Z [01-05-14 08:57]: > [...] > > unless you try to do something like multiple email providers for one > > user which is very easy to do with anything but sendmail/postfix/exim. > > I have done this on all three and got tired, after every system upgrade > > some incompatible change breaks it and even the most basic smarthost > > configuration stops working, not to mention the multiple accounts which > > always required some configuration acrobatics. Every now and than I update my FreeBSD netbook to the most recent version: 8-CURRENT, 9-CURRENT, 10-CURRENT, ... which always brings a new sendmail compiled in the base system. For its configuration to be able to send mail to my MX (including SASL authentication), I just put the old content of /etc/mail in place and all is done. For many years already. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards
S/SMIME configuration: .index-file
Dear mutt-users, Anybody knows the format of the ".index"-file (used to manage the certificates and keys in a S/SMIME-setup[1])? The first three items are obvious... first.l...@domain.com 1a2b3c4d.0 me ? t ^ email ^ key ^ label ...but what about the last 2? I didn't find any information in the manuals. Best regards, Heiko [1] http://equiraptor.com/smime_mutt_how-to.html -- Heiko Heil • heiko.h...@me.com
Re: S/MIME configuration: .index-file
On Sun, Jan 05, 2014 at 04:25:39PM +0100, Heiko Heil wrote:
[...]
first.l...@domain.com 1a2b3c4d.0 me ? t
^ email ^ key ^ label
...but what about the last 2? I didn't find any information in the
manuals.
I found the description of those fields in smime.c:
/* 0=email 1=name 2=nick 3=intermediate 4=trust */ (line 397)
Just wondering why "smime_keys add_p12" didn't insert the intermediate
certificate ("?").
Best regards,
Heiko
--
Heiko Heil • heiko.h...@me.com • twitter @hhe • mobile +49 170 4713229
Re: S/MIME configuration: .index-file
On Sunday 05 Jan 2014 19:10:42 Heiko Heil wrote:
> On Sun, Jan 05, 2014 at 04:25:39PM +0100, Heiko Heil wrote:
> > [...]
> > first.l...@domain.com 1a2b3c4d.0 me ? t
> > ^ email ^ key ^ label
> >
> >...but what about the last 2? I didn't find any information in the
> >manuals.
>
> I found the description of those fields in smime.c:
> /* 0=email 1=name 2=nick 3=intermediate 4=trust */ (line 397)
>
> Just wondering why "smime_keys add_p12" didn't insert the intermediate
> certificate ("?").
Could it be that the intermediate cert was not part of the p12 file bundle?
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: mutt native SMPT support vs Postfix?
On 05Jan2014 14:25, Chris Down wrote: > On 2014-01-04 20:01:56 +0100, Matthias Apitz wrote: > > I'm using mutt (right now by typing) on my FreeBSD netbook, connected > > via UMTS WAN to my ISP. My mutt drops the mail (this mail) to the local > > MTA (sendmail) and this takes care for the transport to the next MX hop, > > even if the WAN link is down; the mail gets queued until the link comes > > up again. I think this, queuing, is a big advantage over talking SMTP > > directly by mutt. > > Well, that's exactly what I was recommending -- using something like > sendmail over something which is designed for far more (Postfix). Sendmail and postfix are vaguely equally functional. The debate isn't particularly over which to use (though postfix is far far easier to configure), the debate's abot having a local mail system which queues and sends versus having mutt send directly (and fail when offline). > I typically don't use my computer when offline, so having a local mail > queue would not be a big win for me over occasionally having to save > outgoing e-mails to a local file when offline (which has happened about > twice in the last two years). Personally, I expect my laptop to work when offline. Certainly I can code offline, and my commit hooks send email (to me!) Plenty of other examples. Cheers, -- Cameron Simpson Microsoft is not the ANSWER. Microsoft is the QUESTION, and the ANSWER is NO! - roland.gier...@aut.alcatel.at
Re: mutt native SMPT support vs Postfix?
On 05Jan2014 14:55, Richard Z wrote: > On Sun, Jan 05, 2014 at 08:48:50AM +1100, Cameron Simpson wrote: > > AND:... All the local systems that send email (eg cron and innumerable > > shell scripts) can send email via the UNIX standard "sendmail" > > executable. > > > > Use a real mail system locally. A win. > > unless you try to do something like multiple email providers for one user > which is very easy to do with anything but sendmail/postfix/exim. Well, I have two answers to that. The first is that for postfix (assuming it isn't just doing direct SMTP itself, which any real mail system can), is that a reconfig involves modifying the "relayhost" setting in /etc/postfix/main.cf and running "postfix reload". Sendmail is similarly trivial. Any of GNU sed, perl or my patch-config script will all batch edit simple changes like that in a single command line. The second is that I run persistent ssh tunnels to a home server. (obviously offline when offline); my relayhost is "127.0.0.1:1025". That almost never needs adjusting. Cheers, -- Cameron Simpson I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. - English Professor, Ohio University
Re: mutt native SMPT support vs Postfix?
On Sun, Jan 05, 2014 at 09:16:02AM -0500, Patrick Shanahan wrote: > * Richard Z [01-05-14 08:57]: > [...] > > unless you try to do something like multiple email providers for one > > user which is very easy to do with anything but sendmail/postfix/exim. > > I have done this on all three and got tired, after every system upgrade > > some incompatible change breaks it and even the most basic smarthost > > configuration stops working, not to mention the multiple accounts which > > always required some configuration acrobatics. > > I have been doing this for *many* years with miniminal intervention across > many versions of linux, mostly SuSE/openSUSE w/o problems using > postfix/fetchmail/procmail/spamassassin. Postfix and/or most other mta's > also provide the use of rbl's to help minimize spam. your or mine spam filter is not the problem. The problem is when you pipe email through a local postfix/exim MTA it will attach received headers with the domain name and IP, quite often a domain name and IPs that is not even valid. The mail than goes through the smarthost - and this combination easily looks suspicious to certain stupid spam filters of the destination provider. Because the problem is not with your/mine system but the stupidity of the spam filter on the other end it is not easy to fix. It may be that I was hit a bit more often by stupid spam filters because I am using linux-m68k.org domain as from addr but routing mail through gmail.. I will never know because such providers never answer questions, they just silently discarded my mail. > In November last I had to replace my server box witch intailed a four > version upgrade/jump and all I really did to the mail system was clean up > /etc/postfix/main.cf and /etc/postfix/access of stale and mostly commented > out ancient text from prior *experiments*. > > [...] > > I would not touch sendmail/postfix/exim again unless I want to run a > > real public mail server. > > Somewhere you have encountered major weird problems or I have experienced > the "luck of a drunken Irishman" (which I may be). perhaps I was doing things at the wrong time, when I first messed with sendmail something as simple as smarthost support was an unusual thing to do. But the only easy solution that I can see to prevent the "suspicious MTA headers" problem is avoiding the local MTA hop. Richard --- Name and OpenPGP keys available from pgp key servers
Automatically collapsing threads
Hello, Is there a setting or magic trick for automatically collapsing threads? I cannot seem to find anything that would affect the initial thread collapse/uncollapse state (e.g. upon entering a mailbox). -- kchr |_|O|_| |_|_|O| Kim Christensen |O|O|O| http://technopragmatics.org - () ascii ribbon campain - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature
Re: Automatically collapsing threads
On 06Jan2014 00:50, Kim Christensen wrote:
> Is there a setting or magic trick for automatically collapsing
> threads? I cannot seem to find anything that would affect the initial
> thread collapse/uncollapse state (e.g. upon entering a mailbox).
My mutt state is arranged so that completely read threads are
collapsed, and threads with unread items are expanded.
My muttrc has:
set collapse_unread=no
set uncollapse_jump=yes
folder-hook . 'push ""'
folder-hook . 'push ":set collapse_unread=no"'
macro index \R "" "mark the
current thread as read"
macro index '{' ':set my_oldcollapse_unread=$collapse_unread:set
collapse_unread=yes:set
collapse_unread=$my_oldcollapse_unread' 'Collapse thread.'
macro index '}' "{" '(Un)collapse thread.'
Specificly, the folder-hooks push a command, collapsing
all threads when I first enter a mail folder. Depending what you
want, you may be able to push various commands on folder entry to
achieve the state you want.
I've also included a few keyboard macros I find useful.
\R mark whole thread as read and collapse it
{ Collapse the current thread.
} Uncollapse the current thread (really a toggle, but I _use_ it for
uncollapse).
Hope this helps,
--
Cameron Simpson
It looks like you've got Mister Bus Error installed.- tjc
Re: Automatically collapsing threads
On Mon, Jan 06, 2014 at 11:32:16AM +1100, Cameron Simpson wrote: > My mutt state is arranged so that completely read threads are > collapsed, and threads with unread items are expanded. [snip] > I've also included a few keyboard macros I find useful. Awesome, exactly what I had in mind. Thanks for sharing! -- kchr |_|O|_| |_|_|O| Kim Christensen |O|O|O| http://technopragmatics.org - () ascii ribbon campain - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature
Re: mutt native SMPT support vs Postfix?
Please, I read the list and have NO need of duplicate copies of posts. * Richard Z [01-05-14 16:57]: > On Sun, Jan 05, 2014 at 09:16:02AM -0500, Patrick Shanahan wrote: > > * Richard Z [01-05-14 08:57]: > > [...] > > > unless you try to do something like multiple email providers for one > > > user which is very easy to do with anything but > > > sendmail/postfix/exim. I have done this on all three and got tired, > > > after every system upgrade some incompatible change breaks it and > > > even the most basic smarthost configuration stops working, not to > > > mention the multiple accounts which always required some > > > configuration acrobatics. > > > > I have been doing this for *many* years with miniminal intervention > > across many versions of linux, mostly SuSE/openSUSE w/o problems using > > postfix/fetchmail/procmail/spamassassin. Postfix and/or most other > > mta's also provide the use of rbl's to help minimize spam. > > your or mine spam filter is not the problem. Nor was it commented as such. > The problem is when you pipe email through a local postfix/exim MTA it > will attach received headers with the domain name and IP, quite often a > domain name and IPs that is not even valid. The mail than goes through > the smarthost - and this combination easily looks suspicious to certain > stupid spam filters of the destination provider. Why would you want to. Use postfix. I am *not* advocating the use of mutt's smpt. > Because the problem is not with your/mine system but the stupidity of > the spam filter on the other end it is not easy to fix. Or that you do not have a permanent ip. I find that *most* sites refuse to accept email from a dynamic ip. I stopped sending mail from my own smtp many years ago, I relay thru my isp's servers using many different return addresses including gmail, but not their smtp services. > It may be that I was hit a bit more often by stupid spam filters because > I am using linux-m68k.org domain as from addr but routing mail through > gmail.. I will never know because such providers never answer > questions, they just silently discarded my mail. > > > In November last I had to replace my server box witch intailed a four > > version upgrade/jump and all I really did to the mail system was clean > > up /etc/postfix/main.cf and /etc/postfix/access of stale and mostly > > commented out ancient text from prior *experiments*. > > > > [...] > > > I would not touch sendmail/postfix/exim again unless I want to run a > > > real public mail server. > > > > Somewhere you have encountered major weird problems or I have > > experienced the "luck of a drunken Irishman" (which I may be). > > perhaps I was doing things at the wrong time, when I first messed with > sendmail something as simple as smarthost support was an unusual thing > to do. I find postfix *much* easier to config than sendmail! > But the only easy solution that I can see to prevent the "suspicious MTA > headers" problem is avoiding the local MTA hop. ?? use postfix/sendmail/ ps: remember I read the list and do not need direct replies. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: mutt native SMPT support vs Postfix?
On Sun, Jan 05, 2014 at 10:55:22PM +0100, Richard Z wrote: > On Sun, Jan 05, 2014 at 09:16:02AM -0500, Patrick Shanahan wrote: > > * Richard Z [01-05-14 08:57]: > > [...] > > > unless you try to do something like multiple email providers for one > > > user which is very easy to do with anything but sendmail/postfix/exim. > > > I have done this on all three and got tired, after every system upgrade > > > some incompatible change breaks it and even the most basic smarthost > > > configuration stops working, not to mention the multiple accounts which > > > always required some configuration acrobatics. > > > > I have been doing this for *many* years with miniminal intervention across > > many versions of linux, mostly SuSE/openSUSE w/o problems using > > postfix/fetchmail/procmail/spamassassin. Postfix and/or most other mta's > > also provide the use of rbl's to help minimize spam. > > your or mine spam filter is not the problem. The problem is when you pipe > email > through a local postfix/exim MTA it will attach received headers with the > domain > name and IP, quite often a domain name and IPs that is not even valid. > The mail than goes through the smarthost - and this combination easily looks > suspicious to certain stupid spam filters of the destination provider. No, that's not 'the problem' with piping outgoing e-mail through a sensible MTA like postfix. The problem you're describing occurs when 1) not configuring your MTA (postfix) for proper relaying, and 2) not configuring your MUA (mutt) correctly. Mutt, for example, when properly configured will use a FQDN (fully qualified domain name) as your "From:" header - which a properly configured MTA will pass on to a real SMTP server for delivery. The SMTP RFC says nothing about having private network ranges or unqualified (non-FQDN) domain names, such as "laptop.local", in your message "Received:" headers - however I can imagine some anti spam solutions will get suspicious when encountering messages with no routable IPs _at all_... But we're talking relaying of SMTP, not delivering directly. -- kchr |_|O|_| |_|_|O| Kim Christensen |O|O|O| http://technopragmatics.org - () ascii ribbon campain - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature
