[PLUG] Postfix + Dovecot
I've been running postfix with cyrus-SASL for years but it's time to
change the SASL tool to dovecot. I've been wrestling with this for a couple
of days now and it has me pinned to the mat. I need help.
Today I upgraded dovecot-2.2.13 to -2.2.15. Went to the dovecot Web sits
and followed the configuration instructions step-by-step. Added user
dovenull and all checks appear correct:
doveconf -n
# 2.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 3.10.17-smp i686 Slackware 14.1 ext3
mail_location = mbox:/var/spool/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox Sent Messages {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
type = private
}
passdb {
args = scheme=CRYPT username_format=%u /etc/dovecot/users
driver = passwd-file
}
ssl_cert = /etc/ssl/certs/dovecot.pem
ssl_key = /etc/ssl/private/dovecot.pem
userdb {
args = username_format=%u /etc/dovecot/users
driver = passwd-file
}
In postfix's main.cf:
smtpd_sasl_path = smtpd
# Frontier blocking outbound port 25:
relayhost = [mail.aracnet.com]:submission
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noplaintext, noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = may
smtp_sasl_type = dovecot
#smtp_sasl_type = cyrus
All looks good, so I start postfix (/etc/rc.d/rc.postfix start) and tail
/var/log/maillog where I see this:
Feb 17 15:03:13 salmo postfix/smtp[30653]: warning: unsupported SASL client
implementation: dovecot
Feb 17 15:03:13 salmo postfix/smtp[30653]: fatal: SASL library
initialization
Feb 17 15:03:14 salmo postfix/master[30558]: warning: process
/usr/libexec/postfix/smtp pid 30653 exit status 1
Feb 17 15:03:14 salmo postfix/master[30558]: warning:
/usr/libexec/postfix/smtp: bad command startup -- throttling
The problem looks like it's with postfix, not dovecot, but my inexperience
prevents me from seeing what it is. Please provide a clue so I can move past
this issue.
TIA,
Rich
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Postfix + Dovecot
On 02/17/2015 05:09 PM, Rich Shepard wrote: On Tue, 17 Feb 2015, Rich Shepard wrote: Today I upgraded dovecot-2.2.13 to -2.2.15. Went to the dovecot Web sits and followed the configuration instructions step-by-step. Added user dovenull and all checks appear correct: smtp_sasl_type = dovecot #smtp_sasl_type = cyrus Think I've isolated the problem and have no idea how to fix it. dovecot apparently does not work with outgoing mail if that mail has to be relayed through another server. So, if I have dovecot set to smpt I cannot send mail, only receive it. Trying to assign dovecot to smtpd in the above line also causes a fatal error and throttling on outgoing mail. Rich What you need is to set your configs to use a smarthost. My searches turned up very few results, but I did find this one that seems to what you need with all the steps required. http://xmodulo.com/configure-mail-server-postfix-dovecot.html Hopefully this will get you going in the right direction. dafr ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Postfix + Dovecot
On Tue, 17 Feb 2015, Rich Shepard wrote: Today I upgraded dovecot-2.2.13 to -2.2.15. Went to the dovecot Web sits and followed the configuration instructions step-by-step. Added user dovenull and all checks appear correct: smtp_sasl_type = dovecot #smtp_sasl_type = cyrus Think I've isolated the problem and have no idea how to fix it. dovecot apparently does not work with outgoing mail if that mail has to be relayed through another server. So, if I have dovecot set to smpt I cannot send mail, only receive it. Trying to assign dovecot to smtpd in the above line also causes a fatal error and throttling on outgoing mail. Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Spyware in hard drive firmware - a reality for 10+ years
Michael == Michael Rasmussen mich...@jamhome.us writes: Michael Or so reports Kaspersky. Michael http://www.thestar.com/business/2015/02/17/us-can-permanently-spy-on-sabotage-foreign-computers-kaspersky-lab-report-says.html One thing the articles about this problem keep saying and which doesn't make complete sense is that this infection is immune to removal. There is a method to get the infection into spare sectors and into firmware, which seems to me to mean that there *is* a way to see those raw sectors and/or firmware in a such a way as to a) see what's there; and b) remodify the firmware. It might be that if you are dependent on the firmware to inspect or replace the firmware, then the infected firmware could just lie to you in order to hide itself. In which case, these devices really need to have some offline way of inspecting their flash sufficient to generate dumps and checksums to verify they are running what you think they are running. What tools currently exist on linux to inspect the hard disk firmware? I recall updating some hard disk firmware (several years ago), but perhaps using a vendor supplied freedos-based software kit. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] Spyware in hard drive firmware - a reality for 10+ years
Or so reports Kaspersky. http://www.thestar.com/business/2015/02/17/us-can-permanently-spy-on-sabotage-foreign-computers-kaspersky-lab-report-says.html -- Michael Rasmussen Be Appropriate Follow Your Curiosity ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] cron.weekly, early monday morning?
On Feb 16, 2015, at 4:48 PM, Keith Lofstrom kei...@gate.kl-ic.com wrote: I've been running an offsite network-hog backup script once a week, which I foolishly put in /etc/cron.weekly. Further scrutiny reveals that anacron runs cron.weekly in the wee hours of Monday morning; since this script may need a day to send data over a low bandwidth ADSL uplink, this is not a good thing to continue through the workday monday. Does anyone know why anacron is configured this way, or where to change it? Meanwhile, I pulled the job out of cron.weekly and run it from crontab now, starting friday evening at 2200 (10 pm). What I would REALLY like is method like nice to prioritize network traffic. The backup uses rsync, which can be throttled with the bwlimit parameter, but I would like rsync to run full throttle when nothing else is using the network, then get out of the way for humans. tc is usable for traffic shaping, but not agile. This might be the kind of thing you’re looking for: http://lartc.org/howto/lartc.cookbook.fullnat.intro.html http://lartc.org/howto/lartc.cookbook.fullnat.intro.html -- Louis Kowolowskilou...@cryptomonkeys.org mailto:lou...@cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Spyware in hard drive firmware - a reality for 10+ years
some light reading on the topic of HD firmware backdoors: http://www.s3.eurecom.fr/docs/acsac13_zaddach.pdf On Tue, Feb 17, 2015 at 9:28 AM, Russell Senior russ...@personaltelco.net wrote: Michael == Michael Rasmussen mich...@jamhome.us writes: Michael Or so reports Kaspersky. Michael http://www.thestar.com/business/2015/02/17/us-can-permanently-spy-on-sabotage-foreign-computers-kaspersky-lab-report-says.html One thing the articles about this problem keep saying and which doesn't make complete sense is that this infection is immune to removal. There is a method to get the infection into spare sectors and into firmware, which seems to me to mean that there *is* a way to see those raw sectors and/or firmware in a such a way as to a) see what's there; and b) remodify the firmware. It might be that if you are dependent on the firmware to inspect or replace the firmware, then the infected firmware could just lie to you in order to hide itself. In which case, these devices really need to have some offline way of inspecting their flash sufficient to generate dumps and checksums to verify they are running what you think they are running. What tools currently exist on linux to inspect the hard disk firmware? I recall updating some hard disk firmware (several years ago), but perhaps using a vendor supplied freedos-based software kit. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] INFORMAL Advanced Topics Meeting Tonight
Hello all, For want of responses to the CFP, there will be an informal Advanced Topics meeting at the Lucky Lab on Hawthorne tonight for those who need to get out of the house. Enjoy! Michael Dexter PLUG Volunteer ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] cron.weekly, early monday morning?
On Mon, Feb 16, 2015 at 4:48 PM, Keith Lofstrom kei...@gate.kl-ic.com wrote: I've been running an offsite network-hog backup script once a week, which I foolishly put in /etc/cron.weekly. Further scrutiny reveals that anacron runs cron.weekly in the wee hours of Monday morning; since this script may need a day to send data over a low bandwidth ADSL uplink, this is not a good thing to continue through the workday monday. Does anyone know why anacron is configured this way, or where to change it? If your system is configure similar to mine then here is where things are configured: [lbrigman@area51 ~]$ cat /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Spyware in hard drive firmware - a reality for 10+ years
One thing the articles about this problem keep saying and which doesn't make complete sense is that this infection is immune to removal. There is a method to get the infection into spare sectors and into firmware, which seems to me to mean that there *is* a way to see those raw sectors and/or firmware in a such a way as to a) see what's there; and b) remodify the firmware. It might be that if you are dependent on the firmware to inspect or replace the firmware, then the infected firmware could just lie to you in order to hide itself. In which case, these devices really need to have some offline way of inspecting their flash sufficient to generate dumps and checksums to verify they are running what you think they are running. Yes, that very well may be the case. Much like kernel-level root kits that return a clean version of an infected binary upon read(), but run a different version when and exec system call is run. Besides, even if a BIOS read did return the infected version, we don't have any off-the-shelf tools to test for the infection. What tools currently exist on linux to inspect the hard disk firmware? I recall updating some hard disk firmware (several years ago), but perhaps using a vendor supplied freedos-based software kit. I don't know of any, but I haven't looked. Similar to BadUSB research, you'd probably have to reverse engineer the vendor-supplied HD BIOS update software to figure out how they do it. It's probably just a matter of sending a vendor-specific magic word over to the HD. I know there's been interest in creating open source system BIOSes, but not sure about HDs. IMO, HD vendors shouldn't provide a way to update their firmwares over ATA, unless it involves some serious downtime. For instance, they could require that the flashing can only occur after being authorized directly by the Firmware during a reboot. Perhaps leverage the ATA password prompt process to ask the user to type CONFIRM or something very explicit to unlock the flashing capability for that single boot session. Same goes for USB firmwares, and any other device firmware. Either provide a physical port for re-flashing, or find a way to make it very hard to secretly flash the firmware. It seems cumbersome, but all that scary backdoor stuff people hypothesized about 15 years ago actually began to happen 10 years ago, and we're only now finding out about it. tim ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Spyware in hard drive firmware - a reality for 10+ years
On Tue, Feb 17, 2015 at 9:28 AM, Russell Senior russ...@personaltelco.net wrote: Michael == Michael Rasmussen mich...@jamhome.us writes: Michael Or so reports Kaspersky. Michael http://www.thestar.com/business/2015/02/17/us-can-permanently-spy-on-sabotage-foreign-computers-kaspersky-lab-report-says.html One thing the articles about this problem keep saying and which doesn't make complete sense is that this infection is immune to removal. There is a method to get the infection into spare sectors and into firmware, which seems to me to mean that there *is* a way to see those raw sectors and/or firmware in a such a way as to a) see what's there; and b) remodify the firmware. It might be that if you are dependent on the firmware to inspect or replace the firmware, then the infected firmware could just lie to you in order to hide itself. In which case, these devices really need to have some offline way of inspecting their flash sufficient to generate dumps and checksums to verify they are running what you think they are running. What tools currently exist on linux to inspect the hard disk firmware? I recall updating some hard disk firmware (several years ago), but perhaps using a vendor supplied freedos-based software kit. Also you would think that anything headed for that special area of the disk would have some sort of signature that could be searched for before it got sent to the mysterious firmware. Bill Barry ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
