maildirmake difficulties

Jonathan de Boyne Pollard · *nix forums beginner Joined: 07 Jan 2005 Posts: 49

CR> /usr/local/bin/tcpserver -v -H -R -l "$LOCAL" \
CR> -x /etc/tcp.smtp.cdb \
CR> -c "$MAXSTMPD" -u "$QMAILDUID" -g "$NOFILESGID" \
CR> 0 smtp /var/qmail/bin/qmail-smtpd

CR> 1724 ? S 0:00 \
CR> /usr/local/bin/tcpserver -v -H -R -l atheris.itsconnect.com \
CR> -x /etc/tcp.smtp.cdb \
CR> -c -u 1002 -g 102 \
CR> 0 smtp /var/qmail/bin/qmail-smtpd

What you need is a "tcpserver" that actually performs error checking on
its command line options.

<URL:http://homepages.tesco.net./~J.deBoynePollard/Softwares/ucspi/#option-checks>

Jonathan de Boyne Pollard · *nix forums beginner Joined: 07 Jan 2005 Posts: 49

SS> c> Putting drmemory.starband.net.mshome.net into control/me...

This is why "qmail-inject" is using
<swani@drmemory.starband.net.mshome.net> as your mailbox name. I'm
guessing that the correct contents of "control/me" should be
"drmemory.starband.net".

SS> c> Your host's fully qualified name in DNS is
drmemory.starband.net.mshome.net.

And this is why "config" thought in the first place that "control/me"
should contain that. "dnsfq" performed a name->address->name mapping on
"drmemory.starband.net." and came back at the end with
"drmemory.starband.net.mshome.net.".

SS> Sometime long ago, I put HOSTNAME=drmemory.starband.net into the
SS> /etc/sysconfig/networks file.

This, in combination with either with a wildcard or a badly edited
"zone" file, is why your "hostname" command is behaving as it does when
you use its "-f" option, and why "config" did the same.

SS> Don't know if that was wise or not, [...]

It wasn't. You should, at the very least, have put a dot on the end to
make it into an actual fully-qualified domain name if it being a
fully-qualified domain name was your intention. (There are
disadvantages having your hostname be a fully-qualified domain name,
note. A few softwares expect the hostname to not be fully qualified,
and become quite upset if it is.)

<URL:http://menandmice.com./online_docs_and_faq/glossary/fqdn.htm>

SS> but it seemed to work with postfix.

Postfix has funny ideas about domain name qualification. This is but
one of them. The rest of the world ("qmail", the "hostname" command,
Sendmail, "exim", and so forth) assume that gethostname()/uname()
returns a local nickname, which they then pass through various
contortions to invoke DNS name qualification (gethostbyname(),
dns_ptr(dns_ip()), and so forth) to obtain the actual full host name.
You've seen the results that your configuration yields with "qmail" and
with the "hostname" command. Postfix, in contrast, assumes that
gethostname() returns the full host name directly, and by default
derives everything else from that ($myorigin::=$myhostname,
$mydomain::=$myhostname minus the first label,
$mydestination::=$myhostname amongst others, and so forth) with no
attempt to run it through any DNS name qualification procedures first.
Because your hostname wasn't a local nickname, Postfix happened to work.

SS> The hostname I see is being set in sysconfig. But where does that
SS> mshome.net part come from?

grep domain /etc/resolv.conf

SS> What should /etc/hosts actually contain?

The contents of "/etc/hosts" are irrelevant to your problem. In fact,
they are largely irrelevant to your entire use of "qmail".

SS> What hostname should I be setting in sysconfig?

Either (read this *carefully*) "drmemory.starband.net." or "drmemory".

SS> Should I run ./config-fast?

No. You should edit "control/me", "control/defaultdomain", and
"control/locals".

Jonathan de Boyne Pollard · *nix forums beginner Joined: 07 Jan 2005 Posts: 49

KM> something strange is going on.

Indeed. You have an error logged with the words "Remote host said:" in
it, followed by the error message text from the remote host that is
clearly from Sendmail, and yet you've decided to ask about your "qmail"
system in the "qmail" support forum.

Jonathan de Boyne Pollard · *nix forums beginner Joined: 07 Jan 2005 Posts: 49

CC> You have not shown any evidence that spammers are relaying messages
CC> through your qmail server.

Actually, pre-adding a "Delivered-To:" is a new variation on the old
"Have an innocent intermediary deliver the payload to the victim in a
bounce message." trick that UBM senders have recently begun to use.

A few people vilify MTS softwares that check the local parts of mailbox
names after accepting a message, on the grounds that UBM senders exploit
this to have the intermediaries generate bounce messages containing the
payload and directed at the real targets, ignoring the fact that having
the SMTP Relay server run in a context where it does not have privileged
access to other user accounts is an advance in the state of the art. I
predict that on the exact same grounds those people will soon begin
vilifying MTS softwares that have a "Delivered-To:" loop detection
mechanism. Have their way, and we'll be back where we were in the
1980s, with no loop detection and with SMTP Relay servers that run with
elevated privileges, in no time.

Jonathan de Boyne Pollard · *nix forums beginner Joined: 07 Jan 2005 Posts: 49

JN> I've also managed to figure out that the audubon@neodata.com address
JN> is NOT subscribed to the list. It probably never was, since ezmlm is
JN> careful enough to not allow "broken autoresponder" subscriptions.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/djb-qsecretary.html#Flaws>

Jonathan de Boyne Pollard · *nix forums beginner Joined: 07 Jan 2005 Posts: 49

BL> it's a fact that NAT will always have some "advantage" for a
BL> sysadmin like the false feeling of security of the box behind.

X> if we all had public IP's setting up an SMB server to put files on
X> would be that much harder, as now you can have someone in India
X> connect to it.

Wrong. That's exactly the false feeling of security that NAT inspires
that Benoit was referring to.

NAT implies the use of non-public IP addresses, and the supposed feeling
of security is actually derived from that rather than from NAT /per
se/. But often that hypothetical Person in India can also connect to a
machine with a non-public IP address. Non-public and site-local IP
addresses are not magic pixie dust. There's nothing inherently special
about them that makes them unreachable. The thing that makes them
unreachable is not "RFC 1918 has a magic incantation in it that casts a
spell on the world" but the simple presence of rules in border routers
that say "filter out traffic with these IP addresses in it". And it's
just as easy to have a rule that says to filter out 2001:04F8::/32 (a
company's global unicast address space) traffic as it is to have a rule
that says to filter out FEC0::/16 (site local address space) traffic.
The router doesn't care about the actual numbers. So it's just as easy to
use public IP addresses, and secure that SMB server from (direct) outside
access by filtering out traffic using those addresses, as it is to use
non-public IP addresses, and secure it from (direct) outside access by
filtering out traffic using those addresses. Furthermore: The argument
that the well-known non-public IP address ranges are already universally
filtered out, making using them the easier option to employ, is quite
easily demonstrated to be based upon a premise that is actually false in
practice.

Here's an eye-opener for those sitting behind mass-market routers that
perform NAT, assigning 192.168.0.0/16 IP addresses to their machines:
Find out whether your router happily transmits 10.0.0.0/8, or
172.16.0.0/12, or 127.0.0.0/8 traffic between you and the rest of
Internet. If so, ask yourself what, exactly, is making all of those "a
secure address range" that "someone outside of your network cannot reach".

The argument in favour of using RFC 1918 non-public IP addresses is that
public IP version 4 addresses are *hard to obtain*. If they were easy
to obtain, there would be no reason to favour non-public IP addresses
over public IP addresses in this context, since it is equally easy to
render either one unreachable.

Over the past few years I've been carefully recommending, as best
practice, that proxy servers be configured to listen on
"non-publically-reachable IP addresses" rather than "RFC 1918 IP
addresses", because it was pointed out that "reserved by RFC 1918" and
"unreachable" are not synonymous.

Mark Lundquist · *nix forums beginner Joined: 07 Jan 2005 Posts: 6

Mark Lundquist · *nix forums beginner Joined: 07 Jan 2005 Posts: 6

Kyle Wheeler · *nix forums Guru Wannabe Joined: 07 Jan 2005 Posts: 208

On Friday, January 7 at 01:42 PM, quoth Charles Cazabon:

Bruce Larson · *nix forums beginner Joined: 07 Jan 2005 Posts: 11

On Fri, 7 Jan 2005 13:42:44 -0600, Charles Cazabon
<qmail@discworld.dyndns.org> wrote:

Bruce Larson · *nix forums beginner Joined: 07 Jan 2005 Posts: 11

On Fri, 7 Jan 2005 15:44:58 -0500, Kyle Wheeler
<kyle-qmail@memoryhole.net> wrote:

Chris Berry · *nix forums addict Joined: 08 Jan 2005 Posts: 81

Although I tend to agree with Charles sentiments about employee trust,
I've found this a fairly common request from management. This cannot be
implemented using pure qmail, however if you set up a second smtpd
listener on port 26 that is local only, then block port 25 for those
users with an authenticating firewall it will effectively create the
situation you're looking for.

Chris Berry
chris_berry@jm-associates.com
Systems Administrator
JM Associates & Coast Business Service

"FIRE! READY! AIM! -Poor management process exemplified"

Charles Cazabon wrote:

David Dyer-Bennet · *nix forums beginner Joined: 08 Jan 2005 Posts: 5

I'm rebuilding my servers, hence my email setup, and hence looking at
making changes (since changing just one thing at a time is really too
simple Smile

) (Okay, since I'll have them out of service for testing
anyway, it's a good time to make other changes too.)

Change 1: I think I want to add smpt auth capability. I support some
roving users, and as I understand it that's the easiest way to make
their setup portable (they don't have to find/guess what a working
outbound smtp server is for their boxes at each IP provider they work
through). There appear to be multiple smtp auth patches; is there a
clear consensus on one being "the" smtp auth patch this week? I think
I want to use Bruce Guenter's mailfront stuff anyway, and I need to
keep using vmailmgr (so far as I can tell vmailmgr is the only way to
support *both* local users *and* virtual users on the same box). So
does using mailfront settle my smtp auth decision? Survivably?

Change 2: I'm currently using qpsmtpd. I'm not sure that's worth the
cost. The big thing I think I'm winning on by using it is the ability
to block based on name-based blocking lists -- especially some of the
ones from rfc-ignorant.org. (I initially started using qpsmtpd for
spf, but on consideration I don't think I care any more.) Hence
mailfront being considered. The loop blocking gets the one crucial
thing, spammers whose bouncing messages try to go to 127.* and loop
forever.

Thought 3: Is it worth it / easy enough to support some kind of
encryption of links for smtp sending and pop pickup? Most importantly
for the password in smtp auth and in pop?

Other than that, looks like I'm starting from netqmail-1.05 and adding
patches from there. I don't need some of the patches I had in before
I now think, which simplifies things some. With the level of patching
I'm doing, debian packages aren't so attractive for this application
to me, so I think I'm just building from source as I always have.

I've been scanning this list pretty erratically the last few years and
posting hardly at all, so I may have missed important changes /
revolutions / discoveries when they happened and not caught them in my
quick research the last few days. So what else should I be thinking
about?
--
David Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/>
Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>

David Dyer-Bennet · *nix forums beginner Joined: 08 Jan 2005 Posts: 5

Kiril Todorov <voland@shadowblade.net> writes:

Kyle Wheeler · *nix forums Guru Wannabe Joined: 07 Jan 2005 Posts: 208

On Saturday, January 8 at 01:33 AM, quoth David Dyer-Bennet:

Google