521 SMTP Server...
Taylor, Grant
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?
See RFC 1846 "SMTP 521 Reply Code"
(ftp://ftp.rfc-editor.org/in-notes/rfc1846.txt) for more details.
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. . . .
feen...@gmail.com
> 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.
Daniel Feenberg
>
> Regards
> Henning Hucke
> --
Taylor, Grant
> 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.
Grant. . . .
Taylor, Grant
> 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!/>
*nod* Why the sigh?
Grant. . . .
Taylor, Grant
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.
Grant. . . .
Frank Slootweg
[deleted]
> 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?
[deleted]
Taylor, Grant
> 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?
*nod* Multiple version there of.
Grant. . . .
David F. Skoll
> 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
#}
Taylor, Grant
> 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.
Indeed.
> For Grant's original question:
>
> 1) Install xinetd.
*mumble*
> 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.
Thank you David, and Dave, for the Perl script. I will look in to the
option to have the script bind to the network it's self.
Grant. . . .
Taylor, Grant
> 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? ;)
Grant. . . .
Taylor, Grant
> 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.
Grant. . . .
Mark Crispin
> 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.
Taylor, Grant
> 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.
Grant. . . .
Dave Sill
> 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:
http://cr.yp.to/ucspi-tcp.html
--
Dave Sill Oak Ridge National Lab, Workstation Support
Author, The qmail Handbook <http://web.infoave.net/~dsill>
<http://lifewithqmail.org/>: Almost everything you always wanted to know.
AK
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.
AK
Also refer to http://www.sendmail.org/tips/relaying.html. Go to the
Access Database section.
AK
Bill Cole
AK <aktr...@excite.com> wrote:
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.
--
Now where did I hide that website...
Bill Cole
AK <aktr...@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?
> >
> > See RFC 1846 "SMTP 521 Reply Code"
> > (ftp://ftp.rfc-editor.org/in-notes/rfc1846.txt) for more details.
> >
> > 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.
I don't think that answers what he asked for.
AK
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.
AK
Taylor, 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.
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?
Grant. . . .
Taylor, Grant
> 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.
To quote from the OP, "... See RFC 1846 "SMTP 521 Reply Code"
(ftp://ftp.rfc-editor.org/in-notes/rfc1846.txt) for more details. ..."
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.
Grant. . . .
Mark Crispin
> To quote from the OP, "... See RFC 1846 "SMTP 521 Reply Code"
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
> 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. . . .
AK
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?
AK
Chris Davies
> 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 <gta...@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.
Chris
Frank Slootweg
[much deleted]
> 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.
If he has a UNIX system worthy of that qualification :-), he probably
has line(1) [1] which also has a -t timeout parameter.
[1] line(1) is SVID*/XPG*.
Taylor, Grant
> I belive many have posted.
Indeed. I have also replied many times that I was asking about a solution
not using (x)inetd.
> 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.
One would think. However, this discussion started out as a discussion in
response to reading an RFC. I know that SMTP traffic is usually not
random. However this is just a discussion thread.
> 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.
Lots of things are an exercise in futility, yet they happen.
> 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?
I don't believe any other protocol defines the lack of being able to get a
permanent error out of a server as a temporary condition like SMTP does.
If this was not the case, I suspect that such would exist for other
protocols as well.
Grant. . . .
Chris Davies
> If he has a UNIX system worthy of that qualification :-), he probably
> has line(1) [1] which also has a -t timeout parameter.
> [1] line(1) is SVID*/XPG*.
Strange. I thought Sun provided XPG compliant alternatives to Solaris
utilites, when those utilities weren't already XPG compliant. Solaris has
read(sh), read(ksh), and line, but none of them has the option for a
read timeout. We do have bash on our systems, but I don't know whether
that's now part of the standard install.
Chris
Taylor, Grant
> I'm not convinced about this; I think it has the potential to help
> generate collateral spam.
How will this generate collateral spam? The daemon should just listen for
SMTP connections and issue a 521 to any command save for quite. This
system its self will never send any mail.
Grant. . . .
Frank Slootweg
Well, I based my information on HP's HP-UX version of line(1), which
is SVID 2/3 and XPG 2/3 [1], but that version being compliant does of
course not neccessarily mean that the -t option is in also the SVID/XPG.
So I may have spoken too soon. Sorry. I have no access to the actual
SVID/XPG standards, so I can't check.
Chris Davies
> I'm not convinced about this; I think it has the potential to help
> generate collateral spam.
Taylor, Grant <gta...@riverviewtech.net> wrote:
> How will this generate collateral spam? The daemon should just listen
> for SMTP connections and issue a 521 to any command save for quite. This
> system itself will never send any mail.
Collateral spam is defined (usually) as including DSNs from spam
itself. If something tries to deliver a message to one of your servers
and fails (thanks to the 521), it is required to return a DSN to the
envelope sender stating the reason for non-delivery. Given that most spam
forges the envelope sender, this means someone somewhere gets a message
as a result of a spam that couldn't be delivered. This is collateral
spam, and is considered poor practice. There are even RBLs for marking
such hosts.
As I wrote originally when I offered a solution that could hang off
netcat ("while :; do nc -p 25 -l -e smtp521.sh; done"), I think it has
the *potential* to help generate collateral spam. This does not mean I
think it will do so, but I have raised a concern for you to consider.
Chris
Taylor, Grant
> Collateral spam is defined (usually) as including DSNs from spam
> itself. If something tries to deliver a message to one of your servers
> and fails (thanks to the 521), it is required to return a DSN to the
> envelope sender stating the reason for non-delivery. Given that most spam
> forges the envelope sender, this means someone somewhere gets a message
> as a result of a spam that couldn't be delivered. This is collateral
> spam, and is considered poor practice. There are even RBLs for marking
> such hosts.
From the conversations that I've been part of before regarding "collateral
spam" a.k.a. "Back Scatter", there is a vast difference in rejecting the
message and making someone else handle the failed delivery verses accepting
the message in and then later bouncing it. Seeing as how I would refuse to
accept the message does not mean that I am sending any form of spam. It
could be the sending site's policy to just drop messages that it could not
deliver, or it could be the sites policy to send failed delivery
notifications as is standard to do so. However, it is not my site that is
doing the sending but rather the site that attempted to send me the
message(s). If this site is taking some heat for sending too many bounce
notifications, then chances are good they need to find out why they are
sending too many bounce notifications and remedy the situation. Just
because I'm being smarter about what messages I will and will not accept
responsibility for compared to the site sending them to me does not make me
a spammer.
> As I wrote originally when I offered a solution that could hang off
> netcat ("while :; do nc -p 25 -l -e smtp521.sh; done"), I think it has
> the *potential* to help generate collateral spam. This does not mean I
> think it will do so, but I have raised a concern for you to consider.
Indeed.
However, I could liken this to me locking my doors and windows to deter a
burglar. If I do so, is it my fault that the burglar went next door and
went in to my neighbors unlocked house? I think not. It is my neighbors
fault for not locking his / her house.
Grant. . . .
Bill Cole
Frank Slootweg <th...@ddress.is.invalid> wrote:
Given that Solaris is an actual SysV derivative (you can find many files
on a Solaris box that claim to be unpublished code of AT&T, which
collaborated with Sun on the earliest Solaris) and it lacks a -t for
line OR a distinct version under /usr/xpg4/, I suspect that the SVID/XPG
standard does not include a -t flag.
> [1] <http://www.docs.hp.com/en/B2355-90128/line.1.html>
As warned there, line was removed from XPG4. One could argue that it is
not a standard command for *modern* Unix.
Frank Slootweg
> In article <44e04723$0$12787$dbd4...@news.wanadoo.nl>,
> Frank Slootweg <th...@ddress.is.invalid> wrote:
> > Well, I based my information on HP's HP-UX version of line(1), which
> > is SVID 2/3 and XPG 2/3 [1], but that version being compliant does of
> > course not neccessarily mean that the -t option is in also the SVID/XPG.
> > So I may have spoken too soon. Sorry. I have no access to the actual
> > SVID/XPG standards, so I can't check.
[Solaris SysV info deleted. Thanks.]
> > [1] <http://www.docs.hp.com/en/B2355-90128/line.1.html>
>
> As warned there, line was removed from XPG4. One could argue that it is
> not a standard command for *modern* Unix.
Thanks for that bit of information! The new (HP-UX 11i Version 2
September 2004) HP-UX manpage still says "This command is likely to be
withdrawn from X/Open standards.", but as, as you say, it *is* removed
from XPG4, your comment is very valid and my "a UNIX system worthy of
that qualification" wasn't.
Mark Crispin
> However, I could liken this to me locking my doors and windows to deter a
> burglar. If I do so, is it my fault that the burglar went next door and went
> in to my neighbors unlocked house? I think not. It is my neighbors fault
> for not locking his / her house.
Wrong metaphor.
What you're doing is equivalent to filing a "return to sender" for all
your postal mail with the post office. The junk mailers can then use your
filing to send junk mail to someone else, and get around that other
person's request for "no junk mail", by putting their intended victim as
the return address of their junk mail.
Kari Hurtta
> On 08/10/06 06:22, Chris Davies wrote:
> > I'm not convinced about this; I think it has the potential to help
> > generate collateral spam.
>
> Taylor, Grant <gta...@riverviewtech.net> wrote:
> > How will this generate collateral spam? The daemon should just listen
> > for SMTP connections and issue a 521 to any command save for quite. This
> > system itself will never send any mail.
>
> Collateral spam is defined (usually) as including DSNs from spam
> itself. If something tries to deliver a message to one of your servers
> and fails (thanks to the 521), it is required to return a DSN to the
> envelope sender stating the reason for non-delivery. Given that most spam
> forges the envelope sender, this means someone somewhere gets a message
> as a result of a spam that couldn't be delivered. This is collateral
> spam, and is considered poor practice. There are even RBLs for marking
> such hosts.
Actually number of DSNes is smaller when 521 is given.
If server gives 521
smtp client sends just "failed" DSN
If server do not respond
smtp client sends first "delayed" DSN
and then sends "failed" DSN
/ Kari Hurtta
Taylor, Grant
> Wrong metaphor.
>
> What you're doing is equivalent to filing a "return to sender" for all
> your postal mail with the post office. The junk mailers can then use
> your filing to send junk mail to someone else, and get around that other
> person's request for "no junk mail", by putting their intended victim as
> the return address of their junk mail.
I'll agree that what you are saying is more correct, but not quite
accurate. I am refusing to accept a message. I am not saying "Return to
sender". It is the post office that is choosing to return the message to
the sender.
Before you say that the post office does not have the ability to filter
messages, I'll cut you off at the path. Mail servers have the option to be
selective about what messages they do pass, and thus they have the option
to filter and hold people accountable for what they send.
Also keep in mind that email was designed and is primarily intended to be
sent between two servers, the sending parties server and the receiving
parties server. In this scenario the sending parties server will (or
should) have fine grained control over what messages it will accept from
senders. Thus if the receiving server server refuses to accept a message
the sending server will have a very good idea who to send the message back to.
IMHO the ideal solution would be to either filter during message submission
or directly there after. I'm saying during submission or directly there
after because there are some lame MUAs out there that will not return the
an error message back to users when they try to send, much less the correct
one. In this case the error can be sent as a DSN that people will much
more likely be able to read (if they will or not is another story) where as
the MUA may hide the real error.
In this type of scenario it is extremely likely that the error message will
reach the correct recipient. About the only other thing that comes to mind
regarding this would be to set up some sort of who is allowed to send as
who in conjunction with authenticated senders.
Grant. . . .
Steve Baker
<chris-...@roaima.co.uk> wrote:
>Collateral spam is defined (usually) as including DSNs from spam
>itself. If something tries to deliver a message to one of your servers
>and fails (thanks to the 521), it is required to return a DSN to the
>envelope sender stating the reason for non-delivery. Given that most spam
>forges the envelope sender, this means someone somewhere gets a message
>as a result of a spam that couldn't be delivered. This is collateral
>spam, and is considered poor practice. There are even RBLs for marking
>such hosts.
1.) If someone is trying to deliver email to his "server", and they would
send a bounce for "message refused", they're also eventually going to
send a bounce for "can't connect to server, I give up".
2.) No one legit will be trying to deliver email to his fake server.
3.) Most spam is sent via spam zombies. Spam zombies don't send DSNs when
their email is refused.
--
Steve Baker
Sam
Furthermore, and if someone does send the DSN, it's not going to be my
server, it's going to be the server trying to unload the spam on me. That
server is the one who's going to get blacklisted due to spam backscatter,
and not me.
Ask me if I care.
Per Hedeland
And furtherfurthermore, the amount of DSNs generated due to a server
replying 521 to everything will certainly be no more than that generated
due to that same server replying 550 to one or more RCPT commands - and
the DSNs (if any) will in both cases be generated at the same place.
Hopefully the Holy War on Spam has not yet reached the point where we're
not allowed to reject invalid recipients in the SMTP dialogue for fear
of creating "backscatter" somewhere...
--Per Hedeland
p...@hedeland.org
Taylor, Grant
> And furtherfurthermore, the amount of DSNs generated due to a server
> replying 521 to everything will certainly be no more than that generated
> due to that same server replying 550 to one or more RCPT commands - and
> the DSNs (if any) will in both cases be generated at the same place.
Indeed.
> Hopefully the Holy War on Spam has not yet reached the point where we're
> not allowed to reject invalid recipients in the SMTP dialogue for fear
> of creating "backscatter" somewhere...
I do not think that this will be a long lived belief if it ever does get to
that point. The idea here is to chase the rejection point back to where
the message originated.
It would be interesting to set up servers to require authentication to send
and then only allow each authenticated user to send messages as a very
small subset of users, namely the authenticated user and null reverse path.
I believe such accountability offered by such a system will help
eliminate a LOT of spam. Of course, it would have to be very easy for
someone to call their ISP and say, "Hay, I'd like to send emails out as
this user, please add it to my list of allowed sending addresses.". You
may even be able to allow such a thing to be done based on a web form.
Grant. . . .
Kari Hurtta
> It would be interesting to set up servers to require authentication to
> send and then only allow each authenticated user to send messages as a
> very small subset of users, namely the authenticated user and null
> reverse path. I believe such accountability offered by such a system
> will help eliminate a LOT of spam. Of course, it would have to be
> very easy for someone to call their ISP and say, "Hay, I'd like to
> send emails out as this user, please add it to my list of allowed
> sending addresses.". You may even be able to allow such a thing to be
> done based on a web form.
Problem is that authentication do not scale beyond initial submission of mail.
Authentication is often used between
MUA -> smtp (submission) server
but between next(?) step it is no longer practical
MTA (isp 1) -> MTA (isp 2)
RFC 2554 SMTP Service Extension for Authentication
is published at March 1999
This specification itself allow that kind usage. After
smtp server is accepted authentication of smtp client, there
is passed authenticated user of mail separately on MAIL command.
| 5. The AUTH parameter to the MAIL FROM command
|
| AUTH=addr-spec
|
| Arguments:
| An addr-spec containing the identity which submitted the message
| to the delivery system, or the two character sequence "<>"
| indicating such an identity is unknown or insufficiently
| authenticated. To comply with the restrictions imposed on ESMTP
| parameters, the addr-spec is encoded inside an xtext. The syntax
| of an xtext is described in section 5 of [ESMTP-DSN].
|
| Discussion:
| The optional AUTH parameter to the MAIL FROM command allows
| cooperating agents in a trusted environment to communicate the
| authentication of individual messages.
<...>
|
| Examples:
| C: MAIL FROM:<e=m...@example.com> AUTH=e+3...@example.com
| S: 250 OK
Problem is expansion of a trusted environment which do not scale.
/ Kari Hurtta