Does any one know of a small unix daemon that is a "521 SMTP server"? I.e. a daemon that will accept connections on port 25 and issue a hello string of "521 <host name> does not accept mail" as well as issuing the same string to any command save for "QUIT" for which it closes the connection?
I have done some quick Googleing and have not come up with any thing yet. Seeing as how I'm a C novice I'm not real keen on the idea of trying to code it my self.
Henning Hucke wrote: > On Sun, 6 Aug 2006, Taylor, Grant wrote:
> > Does any one know of a small unix daemon that is a "521 SMTP server"? I.e. a > > daemon that will accept connections on port 25 and issue a hello string of > > "521 <host name> does not accept mail" as well as issuing the same string to > > any command save for "QUIT" for which it closes the connection? > > [...] > > Grant. . . .
> Erm, Grant. Is this meant to be a serious question?
> This should already be achievable with a little bash script started by > xinetd. It should even be secure with a little care while write the bash > code. And If you want to run a sendmail on the same port for not > blacklisted hosts it should even be possible to start such a script with > the tcpwrapper. <sigh!/>
What about something even simpler - add this to inetd.conf:
smtp stream tcp nowait nobody /usr/bin/echo echo 521 host does \ not accept mail
Since echo doesn't read from the input, it probably won't be a security problem. I haved to admint I haven't tried this with port 25, but it is true that inetd passes the standard output of the programs it invokes to the remote system - there isn't any network socket programming required in the application.
drfrem...@nber.org wrote: > What about something even simpler - add this to inetd.conf:
> smtp stream tcp nowait nobody /usr/bin/echo echo 521 host does \ > not accept mail
> Since echo doesn't read from the input, it probably won't be a security > problem. I haved to admint I haven't tried this with port 25, but it is > true that inetd passes the standard output of the programs it invokes > to the remote system - there isn't any network socket programming > required in the application.
This is indeed a novel approach that would probably work for the simpler method suggested in the RFC. My concern is that this will not listen for the quit command and so such or reject any other commands as suggested by the RFC.
Henning Hucke wrote: > Erm, Grant. Is this meant to be a serious question?
Yes. This is why I posted the RFC.
> This should already be achievable with a little bash script started by > xinetd. It should even be secure with a little care while write the bash > code. And If you want to run a sendmail on the same port for not > blacklisted hosts it should even be possible to start such a script with > the tcpwrapper. <sigh!/>
Taylor, Grant wrote: > Does any one know of a small unix daemon that is a "521 SMTP server"? > I.e. a daemon that will accept connections on port 25 and issue a hello > string of "521 <host name> does not accept mail" as well as issuing the > same string to any command save for "QUIT" for which it closes the > connection?
> I have done some quick Googleing and have not come up with any thing > yet. Seeing as how I'm a C novice I'm not real keen on the idea of > trying to code it my self.
Thank you Henning and Daniel. Both of your suggestions would probably work fairly well if I was running (x)inetd. However, I am not running such on any of my production systems and as such neither of th proposed solutions will work. I was hopping that someone knew of a small compiled daemon (possibly written in C) that would bind to port 25 and listen for connections and respond according to RFC 1846.
> Thank you Henning and Daniel. Both of your suggestions would probably work > fairly well if I was running (x)inetd. However, I am not running such on > any of my production systems and as such neither of th proposed solutions > will work.
Huh? You have a computer *on a network* (otherwise you wouldn't be needing a "521 SMTP Server", but don't have (x)inetd? What network services *do* your "production systems" have and how *are* they started (if not by (x)inetd)?
Or are you saying you don't have UNIX/Linux? If so, then why not say so?
Frank Slootweg wrote: > Huh? You have a computer *on a network* (otherwise you wouldn't be > needing a "521 SMTP Server", but don't have (x)inetd? What network > services *do* your "production systems" have and how *are* they started > (if not by (x)inetd)?
*chuckle*
Yes, I have multiple systems connected to the internet. No, I'm not running a super server to launch my daemons. I'm leaving my daemons running in daemon mod, bound directly to the ports that I need. I have found this to be faster and more reliable than having a super server daemon launch services when need be. You may think that this is taking up more overhead leaving these daemons running all the time. If I was running a lot of daemons that did things very infrequently that would possibly be true. However, seeing as how my systems are web / email / ftp servers, the services in question are used multiple times a second. The only other service that I run that is not hit by most clients is SSH, which I use multiple times per day. So rather than having to use a daemon that slows down connections to my other serving daemons that I would have to worry about security with, I elected to not run a super server daemon and to instead run my real serving daemons directly.
> Or are you saying you don't have UNIX/Linux? If so, then why not say > so?
Frank Slootweg wrote: > Huh? You have a computer *on a network* (otherwise you wouldn't be > needing a "521 SMTP Server", but don't have (x)inetd? What network > services *do* your "production systems" have and how *are* they started > (if not by (x)inetd)?
I have production systems on the network that don't run (x)inetd.
If all you want to run is a Web server and mail server, you don't need (x)inetd because those services are not typically managed by (x)inetd.
For Grant's original question:
1) Install xinetd.
2) Modify the attached trivial Perl script, written by my colleague Dave O'Neill.
If you don't want to install xinetd, modify the Perl script to use socket(), bind(), listen(), accept() and fork() as appropriate.
Regards,
David.
#!/usr/bin/perl -w
# Null SMTP server. Accepts and throws away everything on stdin. # Run it via inetd.
print "220 /dev/null SMTP Ready\n"; my $in_data = 0; $| = 1; while(<>) { $in_data = 0 if ($in_data && /^\.\r?$/); next if $in_data; if (/^QUIT\r?$/i) { print "221 didn't even know you were here\n"; last; } if (/^DATA/i) { print "350 sure, but I will throw it away\n"; $in_data = 1; next; } print "250 sent to /dev/null as planned\n";
}
# xinetd config for above daemon # default: on # description: Null SMTP server #service nullsmtp #{ # socket_type = stream # wait = no # user = nobody # port = 2525 # server = /path/to/nullsmtp.pl # log_on_failure += USERID # disable = no #}
> Sorry for this and don't take it to personally but to me it's *so* > obvious that I sigh.
*nod*
> Just ask yourself what normally listens to connection requests on the > port(s) in question and take its capabilities. Its as easy as that. Once > you honor this way of deduction you find the right questions and the > places to look for the answers.
If you will read subsequent posts in this thread you will realize that I do not run (x)inetd on any of my production systems, in fact it is not even installed. As such, (x)inetd is not such an obvious solution is it? ;)
> Well. You have productive systems which normally don't have SMTP servers > running but you honestly think on installing such a fake daemon on all > of them!?
Not all of them, but possibly some. Honestly I was not really thinking seriously about installing such. After reading the RFC I got to thinking that I had never heard of such a daemon so I thought to my self, "Self, do you know any one or any group that you could ask about such a daemon?" and I answered my self, "Why yes I do. I'll post to comp.mail.sendmail and comp.mail.misc.". So I did.
> You hopefully have a firewall installed. Install an xinetd on one of > your productive servers, write this little script thingy (remind that > you can bind even bash scripts to ports without the need of an xinetd. > Otherwise use perl) and *redirect* any access to SMTP serverless IP > address to this machine. This would give you central control over this > stuff which also means (tadaaaaa) updates only on *one* machine.
Yes there are firewalls installed, but the systems in question are sparse and on client's networks and thus central redirection is not practical.
Please do tell or point me to documentation on how to bind bash scripts to a socket.
On Tue, 8 Aug 2006, Taylor, Grant wrote: > If you will read subsequent posts in this thread you will realize that I do > not run (x)inetd on any of my production systems, in fact it is not even > installed. As such, (x)inetd is not such an obvious solution is it? ;)
Which then leads to the obvious question of why don't/won't you install [x]inetd?
What attraction is there for you to build a unique server which (unlike [x]inetd) has not been extensively reviewed and tested, rather than use solutions which have had extensive review testing?
Usually, when I see someone with such seemingly-irrational criteria, it indicates one of two things: . the person is under the sway of some net.myth . there is some important data point which has not been disclosed, but knowledge of which is critical for a proper recommendation.
net.myths are widespread. Many are based upon actual fact, albeit distorted or out of context, or deal in circumstances that are long obsolete. Others are complete nonsense.
Most net.myths of the form "[x]inetd is insecure (or inefficient)" fall into the complete nonsense category.
-- Mark --
http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.
Mark Crispin wrote: > Which then leads to the obvious question of why don't/won't you install > [x]inetd?
Personal preference / experience. I know that is not a very sound answer, but it is still my answer.
> What attraction is there for you to build a unique server which (unlike > [x]inetd) has not been extensively reviewed and tested, rather than use > solutions which have had extensive review testing?
I personally believe there is a place for such a server. If you do not agree, that is fine, you are free to have your own beliefs.
> Usually, when I see someone with such seemingly-irrational criteria, it > indicates one of two things: > . the person is under the sway of some net.myth > . there is some important data point which has not been disclosed, but > knowledge of which is critical for a proper recommendation.
> net.myths are widespread. Many are based upon actual fact, albeit > distorted or out of context, or deal in circumstances that are long > obsolete. Others are complete nonsense.
My dislike of (x)inetd is not based on any net.myths, but rather my personal experience.
> Most net.myths of the form "[x]inetd is insecure (or inefficient)" fall > into the complete nonsense category.
Well, I have seen the inefficiency of (x)inetd, which is why I stated it. This is why I do not want to run (x)inetd.
"Taylor, Grant" <gtay...@riverviewtech.net> writes: > Thank you Henning and Daniel. Both of your suggestions would probably > work fairly well if I was running (x)inetd. However, I am not running > such on any of my production systems and as such neither of th > proposed solutions will work. I was hopping that someone knew of a > small compiled daemon (possibly written in C) that would bind to port > 25 and listen for connections and respond according to RFC 1846.
It'd be pretty easy to write one that would run under tcpserver:
Taylor, Grant wrote: > Does any one know of a small unix daemon that is a "521 SMTP server"? > I.e. a daemon that will accept connections on port 25 and issue a hello > string of "521 <host name> does not accept mail" as well as issuing the > same string to any command save for "QUIT" for which it closes the > connection?
> I have done some quick Googleing and have not come up with any thing > yet. Seeing as how I'm a C novice I'm not real keen on the idea of > trying to code it my self.
> Grant. . . .
Grant,
In sendmail, you can define the source as deny i.e. 0.0.0.0/0 DENY
I believe that will set all connections to be rejected with a 5xx error upon connection such that there will be no opportunity for interaction.
Taylor, Grant wrote: > Does any one know of a small unix daemon that is a "521 SMTP server"? > I.e. a daemon that will accept connections on port 25 and issue a hello > string of "521 <host name> does not accept mail" as well as issuing the > same string to any command save for "QUIT" for which it closes the > connection?
> I have done some quick Googleing and have not come up with any thing > yet. Seeing as how I'm a C novice I'm not real keen on the idea of > trying to code it my self.
AK <aktrad...@excite.com> wrote: > Taylor, Grant wrote:
> > Does any one know of a small unix daemon that is a "521 SMTP server"? > > I.e. a daemon that will accept connections on port 25 and issue a hello > > string of "521 <host name> does not accept mail" as well as issuing the > > same string to any command save for "QUIT" for which it closes the > > connection?
> > I have done some quick Googleing and have not come up with any thing > > yet. Seeing as how I'm a C novice I'm not real keen on the idea of > > trying to code it my self.
AK <aktrad...@excite.com> wrote: > Taylor, Grant wrote:
> > Does any one know of a small unix daemon that is a "521 SMTP server"? > > I.e. a daemon that will accept connections on port 25 and issue a hello > > string of "521 <host name> does not accept mail" as well as issuing the > > same string to any command save for "QUIT" for which it closes the > > connection?
> > I have done some quick Googleing and have not come up with any thing > > yet. Seeing as how I'm a C novice I'm not real keen on the idea of > > trying to code it my self.
> > Grant. . . .
> Grant,
> In sendmail, you can define the source as deny > i.e. > 0.0.0.0/0 DENY
Where do you think Sendmail understands such syntax?
That looks like a tcp wrappers config line, and believe it or not, not all Sendmail's are linked to libwrap.
> I believe that will set all connections to be rejected with a 5xx error > upon connection such that there will be no opportunity for interaction.
Bill Cole wrote: > In article <U8ednU5OxJSxmkTZnZ2dnUVZ_vadn...@comcast.com>, > AK <aktrad...@excite.com> wrote:
>>Taylor, Grant wrote:
>>>Does any one know of a small unix daemon that is a "521 SMTP server"? >>>I.e. a daemon that will accept connections on port 25 and issue a hello >>>string of "521 <host name> does not accept mail" as well as issuing the >>>same string to any command save for "QUIT" for which it closes the >>>connection?
>>>I have done some quick Googleing and have not come up with any thing >>>yet. Seeing as how I'm a C novice I'm not real keen on the idea of >>>trying to code it my self.
> The access database cannot do what Grant is asking for.
> A shell script behind (x)inetd or a nc (netcat) could do it handily. A > SMOP.
Bill,
What is Grant asking for? If the server should not be getting email, one should not list the server as a mail server (MX record). One thing is to answer the question as posed another is to get to the bottom of what is being asked. There is only one use for what is being sought and that is for spamming. i.e. use spam domains that list this server as the MX. as long as the server issues 5xx errors, the mail admins will have a slightly more difficult time catching this since the bounce back email will not be stuck in the queue because they can not be sent back. Any mail server administrator, uses a bit bucket for double bounces and the server/domain in question will find itself being blacklisted in short order.
> In sendmail, you can define the source as deny > i.e. > 0.0.0.0/0 DENY
> I believe that will set all connections to be rejected with a 5xx error > upon connection such that there will be no opportunity for interaction.
I'm quite sure that I could configure Sendmail to do this, however I'm wanting this to not need to have Sendmail installed. Why get out an industrial sized generator powered hydraulic operated impact hammer drill to turn a screw 1/4 turn when Can turn it by hand with a basic screw driver?
> What is Grant asking for? If the server should not be getting email, > one should not list the server as a mail server (MX record). One thing > is to answer the question as posed another is to get to the bottom of > what is being asked. There is only one use for what is being sought and > that is for spamming. i.e. use spam domains that list this server as > the MX. as long as the server issues 5xx errors, the mail admins will > have a slightly more difficult time catching this since the bounce back > email will not be stuck in the queue because they can not be sent back. > Any mail server administrator, uses a bit bucket for double bounces and > the server/domain in question will find itself being blacklisted in > short order.
I'm wanting a very simple daemon to implement a SMTP like server that will issue the 521 reply code to any sending system. Read the sited RFC for reasons why. Or if I need to I can copy and past the RFC in to this news group.
Taylor, Grant wrote: > On 08/10/06 02:05, Mark Crispin wrote:
>> RFC 1846 is an Experimental protocol, and a lot has changed in the 11 >> years since it was published.
>> I don't think that it is a particularly good idea to implement it.
> Possibly a very valid point. However for the sake of discussion, the > question still stands.
> Grant. . . .
grant,
I belive many have posted.
You can use inetd or xinetd depending on you system that will listen on port 25 and trigger your script a bash script will do just fine.
You need not implement a fully functional SMTP transaction handling script.
#!/bin/bash echo "521 myserver.somedomain.com does not accept mail" exit
Is sufficient. xinetd or inetd will fire the script for every port 25 connection.
One would think if a server is not listening on port 25, it would be obvious that it is not accepting email. Additionally, email transmission is not a random selection of hosts to see whether this particular host accept email for a particular domain.
you could use read to see what is being sent in and deal with it accordingly, but if it has not been made clear, this is an excersise in futility.
If there were RFC's of similar context dealing with other services web, ftp, pop3d, imap, etc., would you be exploring implementing those that as well just out of curiosity?
> RFC 1846 is an Experimental protocol, and a lot has changed in the 11 > years since it was published. I don't think that it is a particularly > good idea to implement it. Taylor, Grant <gtay...@riverviewtech.net> wrote: > Possibly a very valid point. However for the sake of discussion, the > question still stands.
I'm not convinced about this; I think it has the potential to help generate collateral spam.
------------------------------------------------------------------------ | #!/bin/bash | # | PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin | NULL=/dev/null | | HOSTNAME="$1" | TIMEOUT=60 | | | ######################################################################## | # Go | # | TAG=`basename "$0" .sh` | | test -z "$HOSTNAME" && HOSTNAME=`cat /etc/mailname 2>$NULL` | test -z "$HOSTNAME" && HOSTNAME=`( hostname || uname -n ) 2>$NULL` | | MSG_521="521 $HOSTNAME does not accept mail" | MSG_221="221 $HOSTNAME closing connection. Better luck elsewhere" | | echo "$MSG_521" | while IFS= read -t "${TIMEOUT:-300}" -r VERB DATA | do | DATA=`echo "$DATA" | expand | cut -c1-79` | | test -n "$TAG" && logger -t "$TAG" "$VERB $DATA" | test ! -t 0 -a -t 2 && echo "< $VERB $DATA" >&2 | | case "$VERB" in | | QUIT) | break | ;; | *) | echo "$MSG_521" | test ! -t 0 -a -t 2 && echo "> $MSG_521" >&2 | ;; | esac | done | | # All done | # | echo "$MSG_221" | test ! -t 0 -a -t 2 && echo "> $MSG_221" >&2 | exit 0 ------------------------------------------------------------------------
If you don't have bash, the -t timeout parameter will need to be removed from the read, and you'll have to work out some other way of timing out the whole process.
