outbound smtp on osx leopard, enabling postfix for mail blasting

if you have a mac lying around and not being used, it can be setup fairly easily to be an smtp email server

this could come in handy for a company that doesn't have exchange, is using hosted email with relay limits such as godaddy and their 250 relays per day, and needs to regularly send a large number of emails out to clients as well as internal staff

we are going to use the built in postfix email server that is part of osx leopard, we will set it up so that the email server will look to the local osx user database, any user account setup on the osx box will be able to be used for sending email, so when you need a new email user just add a regular osx user instead of having to setup sasl lists

first thing we need to do is enable it, to do so navigate to:
/System/Library/LaunchDaemons/org.postfix.master.plist

let's open this file up and edit it, i prefer using the vi editor. right before the closing </dict> tag we need to add some parameters, these will enable postfix to start when the computer boots up, so add this line right before that tag:
<key>OnDemand</key> <false /> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/>

we can either use launchctl to start it up right now, or we can reboot, to use launchctl make sure you're root or sudo the command:
launchctl

once in the launchctl prompt do:
start org.postfix.master

after this, let's check netstat:
netstat -a | grep smtp

we should then see localhost listening for smtp connections, like this:
tcp4 0 0 localhost.smtp *.* LISTEN

next we need to make changes to /etc/postfix/main.cf:
smtpd_sasl_auth_enable=yes
smtpd_use_pw_server=yes
enable_server_options=yes
smtpd_pw_server_security_options=plain, login
smtpd_sasl_security_options=noanonymous
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, reject
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_auth_destination, reject
broken_sasl_auth_clients=yes
mynetworks = 192.168.240.0/21


lastly we will want to tell postfix which networks to accept mail from, for my purposes i only want to accept mail from machines in our local subnet, there is an option called mynetworks_style that has a choice of subnet that should be acceptable for most people's uses, since the box i am setting up will be multihomed with 1 of the ips being public, i don't want to use that option for obvious reasons, instead of the mynetworks_style option i will use the mynetworks option like this:
mynetworks = 192.168.240.0/21

i am in a cidr network, most folks won't be, if we were in a standard class c network it'd look something like this:
mynetworks = 192.168.240.0/24

last thing here, the default file size is far too small for my purposes, i need to be able to send out at least 5 dvd's worth of date, 5 * 4.7gb = 23.5gb, just kidding! seriously if we can send out 20mb then i'm happy and my users will be too (keep in mind, it isn't uncommon to run across a system you are sending to that has a 10mb file size limit!), so we'll open up our main.cf and change the parameter named message_size_limit, like this:
message_size_limit = 20480000

after this, restart the server or restart postfix, as root you can do this to restart postfix:
postfix reload

that should be it!

here are some handy commands for postfix

Reload launchctl after plist edit:
sudo launchctl load /System/Library/LaunchDaemons/org.postfix.master.plist

List active plist files:
launchctl list

Start up/test updated plist:
sudo launchctl start org.postfix.master

Send a test email:
mail name@domain.com

Check the mail queue:
mailq

Clear the mail queue:
sudo postsuper -d ALL

Editing the configuration file:
vi /etc/postfix/main.cf

Reloading postfix after changes:
sudo postfix reload

Starting and Stopping postfix:
sudo postfix stop
sudo postfix start

-----------------------
UPDATE - 01/03/2010 - i have noticed mac osx will sometimes overwrite values in /etc/postfix/main.cf

in particular the inet_interfaces value was changed on my installation. it was changed from all, to localhost, of course this made postfix only listen on localhost thus causing a connection error when clients attempted to mail through this system, changing inet_interfaces from localhost to all then rebooting is the simplest way to resolve this issue.

another long progress bar, 152 hours!

copying 45,750 items to "design002"
39.63 gb of 2.56 tb - about 152 hours

long progress bar

this is the kind of stuff i deal with at work, it's a friday night and we got this crazy time going on:

why i no longer do business with dell

i received an email today from a dell account rep, they are on a campaign trying to reach out to businesses that have not worked with dell in some time

here was my response, included is a fun story that explains why this i.t. manager will never do business with dell again:

hello kara,

we are not interested in any further purchasing with dell

we do not wish to speak with anyone about this decision at this present time

if you have the time, here is my rant on why i will never do business with dell again:

early september 2008 i was waiting for a shipment of 7 pcs that i was told would ship 08/25/2008, order was placed 08/18/2008, next day shipping was used

i received an email about the order being cancelled, aaron even asked me if i had meant to cancel them. i replied, absolutely not! i did not cancel the order, my job was relying on that order!

so we then had a new order on 09/02/2008, i was supposed to have the machines by this date, they were scheduled to be rolled out 09/03/2008, i let aaron know that this situation was “screwing me”, in fact it very much was. i still have all of the emails from this incident, stresses me out just perusing through them to pick the dates out.

they finally arrived on the 10th. or 11th., by then i had already placed an order for 7 hp systems, ordered through pcconnection.com, they arrived the next day and deployed before the dell systems had arrived.

i have seen dell at big jobs i’ve been on, like the navy marine corps intranet, as well as the transportation security administration, these were all huge jobs with enormous purchasing budgets, maybe dell rocks for the big dogs like that, but for a small to medium sized business i do not feel at all that i could ever rely upon dell from that point forward.

i have not ordered dell since then. i have relayed this story to all other i.t. personnel in the apparel and creative circles i work with, i could have lost my job over that mess.

needless to say, i will not be purchasing any dell products in the future, there are far too many other options out there for me to have to go through this sort of stressed out chaos with your company ever again,

thank you,

nathon

virtualbox bridged networking osx host windows xp guest mtu bug!

if you are running windows xp as a guest os using bridged networking, and osx as the host os, using virtualbox for the virtualization software, then i am sure you have noticed some difficulty getting to various websites, such as microsoft's windows update site

the strange thing is that some sites do indeed load, my personal natefrogg.com site loaded without incident, google.com also loads just fine, you may even be able to access other machines on the lan without any issues as well!

it comes down to the mtu settings, for whatever reason, the standard 1500 mtu needs to be reduced in your guest operating system. it appears that the bridged networking mode in virtualbox actually interferes with packet size, packets larger than 1469 will not correctly transmit, seems to be that virtualbox is padding the packets

we need to change the mtu in windows xp, or whatever guest os you are using, to 1469 in order to resolve this problem

to do so, open up a registry editor, i am using regedit, and navigate to this key:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\[Adapter ID]]

note that [Adapter ID] is going to be a unique alphanumeric sequence, you may have several, you need to find the correct one, usually the correct key will have more entries within it, to be safe you could add the mtu entry to all of them, it wouldn't do any harm to do so...

once in the registry key for your interface, create a new dword value and call it MTU

edit the MTU dword value, change the value itself to 1469 and make sure it is a decimal value and not hexadecimal

close up the registry editor, it is time to reboot

once rebooted, try to get to the sites you were having issues with, all should be well in the land of bridged networking now

the virtualbox.org site does in fact have record of this bug, it is filed as trouble ticket #3783 and can be viewed on the virtualbox site here: http://www.virtualbox.org/ticket/3783

howto enable remote desktop on a remote windows machine that has it disabled

here's the scenario:
i'm working from home over a vpn to the office, i have administrative access to the computer i need to work on and the firewall is set with an exception to allow remote desktop/terminal services, but remote desktop is disabled

if i were on site i could simply right click my computer, hit properties, hit remote, then check the "enable remote desktop on this computer" checkbox which would do the trick


fortunately, the setting that the above checkbox activates is something we can change remotely

we need to fire up the registry edit, click start then run then enter regedit, press enter...you are now looking at the windows registry editor, and honestly, if this is your first time seeing the windows registry editor i would highly advise exercising EXTREME CAUTION!!

here is more detailed information about the windows registry:
http://technet.microsoft.com/en-us/library/cc751049.aspx

disclaimer: EDITING YOUR WINDOWS REGISTRY CAN BREAK THINGS! IF YOU MESS UP AN INSTALL AND IT NO LONGER BOOTS OR WORKS, DO NOT COME CRYING TO ME!



now that we have the windows registry editor open, we need to connect to the remote computer, hit file, then "connect network registry"


in the window that popped up, type in the name of the computer we are trying to get into and hit enter, the registry editor will then connect to the remote computer's registry...again, provided you have administrative level access on the remote computer and there is nothing blocking you (firewall, etc.)


here we are, all up in their registry


now we're going to navigate to this key in the registry of the remote computer:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

find the key named fDenyTSConnections and change it's value from 1 to 0, then click ok


in most cases, that is it! you should now be able to connect to the remote computer's terminal server through remote desktop!

in some occasions, the computer may need to be restarted, the easiest way to do this, in my opinion, would be to open a command prompt and issue this command, replace "jane" with the ip address or computer name of the remote system you need to reboot:
shutdown -m \\jane -r -t 000 -f

give it a minute or 2, and the machine should be up again and allowing you to connect without issue

windows 7 and windows server 2008 bug in smb2 allows for remote BSOD!

just discovered this while reading some blogs and tech sites, this guy is the one whom found it first and made a proof of concept:
http://g-laurent.blogspot.com/

here's the post on seclists.org:
http://seclists.org/fulldisclosure/2009/Sep/0039.html

here is my barely modified version, all i did was add an ip address and some more comments, just playin' around here at work, good times:
http://natefrogg.com/tmp/win_7-smb2_bsod.py.zip

it's a python script, i'm using it on a  mac, all you do is unzip it, drop to the directory you unzipped to, open the the python script up and modify the ip host variable to something more appropriate to your testing environment, then run:
python win_7-smb2_bsod.py

if it doesn't work, you most likely do not have file sharing enabled on the windows 7 or windows server 2008 machine

again, i did not discover this, i am just spreading the info