maildirmake difficulties

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

E> No changes to the run file are needed if you use Frederik Vermeulen's
E> TLS patch: http://inoa.net/qmail-tls/netqmail-1.05-tls-20040419.patch

That patch is not the right way to go if SMTP/SSL is what one wants, as
is the case here. (Note that TLS and SSL are not the same thing.) It's
not necessary to be intrusive into the code of the service program, as
that patch is (and highly so), _at all_ in order to provide an SSL/TCP
service. The layering of the server end of a TCP service over SSL is
quite clean. The modular approach of "sslserver", which requires no
modification to stock "{net,}qmail", is by far the better one.

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

DP> Hi All,

Always read FAQTS *before* posting.

<URL:http://www.faqts.com./knowledge_base/view.phtml/aid/29482/fid/206>

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

E> You would be requiring TLS unconditionally by using sslserver in the
E> run file.

SSL != TLS. As I said.

E> There are uses for this however, an example being a secure data feed
E> on a non standard port.

SMTPS on port 465 is a well-known convention.

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

tw> For five of these, their DNS does not point to our server yet.

Not in the case of the one relevant one, where the DNS data most
certainly *do*:

[C:\]dnsqry mx vetdentistry.com. | grep /b/u "Answer:"
Answer: vetdentistry.com. IN MX 120 10 mail.vetdentistry.com.
[C:\]dnsgeta mail.vetdentistry.com.
216.55.183.17
[C:\]dnsgetmx vetdentistry.com.
10 0 25 216.55.183.17
[C:\]

Because you don't have users "greg" and "amy", your system generates and
attempts to send a bounce message to <eitdsrsgjwej@ameritech.net>:

[C:\]dnsgetmx ameritech.net.
10 0 25 67.36.55.28
10 0 25 65.43.19.28
10 0 25 207.115.57.18
10 0 25 206.141.192.66
10 0 25 66.73.20.19
10 0 25 207.115.57.17
[C:\]

The SMTP Relay server at 206.141.192.66 refuses the bounce, probably on
the grounds that there's no such user as "eitdsrsgjwej", and you get a
double-bounce. Simple. What, exactly, are you failing to understand
about this process?

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

<URL:http://catb.org./~esr/faqs/smart-questions.html#urgent>
<URL:http://www.faqts.com./knowledge_base/view.phtml/aid/28942/fid/284>

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

b> my suggestion is run a local dnscache, [...]

<sigh> Always read FAQTS *before* posting.

<URL:http://www.faqts.com./knowledge_base/view.phtml/aid/28942/fid/284>

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

MG> Hi receive a long strange line and qmail says: "deferral:
qmail-inject:_fatal:_unable_to_parse_this_line"

And quite correctly so. Your user's MUA is generating incorrectly
formatted mail messages. Indeed, your user's MUA appears to be quite
seriously broken. It is erroneously using single quotation marks
instead of double quotation marks for quoted-strings, and it isn't
following the rules of RFC 2047 sections 2 and 5.

One particularly bad part of the "To:" field that it is generating is:

=?iso-8859-1?Q?'Santogal P: Auto Rep=FAblica'?=
<absantos@autorepublica.pt>

This of course should be:

=?iso-8859-1?Q?Santogal=20P=3A=20Auto=20Rep=FAblica?=
<absantos@autorepublica.pt>

Get your user to fix his/her horrendously broken MUA. This is not a
"qmail" problem.

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

RJ> I think, there is no fully baked anti-spam idea available.

You're not alone.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-anti-ubm-dont-work.html>

By a long chalk.

RJ> But a _valid_ mail with empty sender can only sent to an address that
RJ> is used for sending mails.

.......... or a mailbox to which that is (pre-delivery) forwarded.

Forgetting forwarding is one of the most common errors that people make
when they talk about validity criteria for delivery status notification
messages.

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

No, it isn't.

The "Message-ID: <fred[jim" attack is one of several well-known, and
widely exploited, attacks against Microsoft Outlook Express. These are,
of course, all MUA problems, not POP3 server problems. Microsoft, in its
turn, makes vague accusations against Trend Micro's PC-Cillin, but
provides no specific bases for them.

<URL:http://www.faqts.com./knowledge_base/view.phtml/aid/17751/fid/139>

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

BL> the major goal of NAT was for the small number of IP available.

Some also see it as a security mechanism, as you alluded. "The traffic
to and from RFC 1918 non-public IP addresses is non-routable, therefore
it is impossible for attackers on the rest of Intenet to directly
communicate with our machines." As such, people will *want* to have NAT
in IP version 6.

In some ways, that view is true. The problems are (a) that it isn't,
however, *entirely* true; and (b) that RFC 1918 non-public IP addresses
are inherently problematic in their own right.

It isn't entirely true because non-public IP address traffic often *is*
routable in practice, to a degree that surprises people who take the RFC
at face value, and does leak. There do exist transit providers that
assign RFC 1918 addresses to routers, so traffic with such addresses
*is* seen in the core. And in many cases, non-public IP address traffic
is routable between customers of a single ISP, for example. ISPs often
use such IP addresses on their internal networks, and make such IP
addresses visible to their customers, and routable. (i.e. They don't
obey RFC 1918 section 3 for the borders between themselves and their
customers, only for the border between themselves and the rest of
Internet.) In such cases, the use of RFC 1918 non-public IP address
ranges doesn't of itself secure the customers from the ISP, or from one
another.

Ironically, the major problem with RFC 1918 non-public IP addresses is
actually laid out in essence in RFC 1918 itself, in section 4 paragraphs
3 and 5. (Some further problems with the notion of "site local
addresses" are outlined in RFC 3879.) Corporate merger is not the only
way that two separate, non-public, networks find themselves linked
together. Tunnelling is another. With the number of roaming users that
there are now, and the (ironically) security-consideration-inspired
drive towards roaming users operating out of their "home" organization,
tunnelling is now quite common. Several times already, I've run across
the problem of people who have a machine in one RFC 1918 non-public
network in one organization, with a VNC connection to another RFC 1918
non-public network in another organization, having an unresolvable
routing conflict between (for example) the routes to a local
192.168.0.0/24 and to a remote 192.168.0.0/24.

Sadly, there is already, in the shape of ULAs ("unique local addresses")
a drive to entrench these self-same problems into IP version 6.
Ironically, people fail to see that the underlying cause of the problem
is actually the (perceived) difficulty for organizations to obtain
ordinary, globally unique, public IP addresses. Were such a thing
(perceptibly) easy, organizations would simply allocate public IP
version 6 addresses to their machines, and block traffic flowing across
their borders with the rest of Internet with router rules. (Anyone who
objects to this with "But I'd have to have router rules!" should be
asked "How did you think that the traffic to and from your machines
using 'site local' IP addresses would be blocked? Magic?", by the way.)

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

Always read FAQTS *before* posting.

<URL:http://www.faqts.com./knowledge_base/view.phtml/aid/28942/fid/284>

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

Hi Bruce,

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

DEVSTAS> Kindly help me if this is a known issue and could be solved.

It's not a problem with "qmail" to be solved. It's a problem with your
MUA to be solved. The carriage return (and line feed) in the header is
perfectly legal Internet message header syntax. (It's known as "folding
white space".) If your MUA cannot properly display mail that has such
headers, then your MUA isn't fully capable of parsing Internet messages,
and needs to be fixed.

DEVSTAS> "This E-mail may contain privileged information and is intended
DEVSTAS> solely for the addressee, and [...]

.......... thus is, technically, unanswerable by anyone subscribed to this
mailing list, since they are not the addressee. One way that people
address stupid electronic mail disclaimers such as yours is to employ
negative feedback, to take the disclaimers entirely at their face value,
and ignore any such mail sent to mailing lists. You've been warned.

<URL:http://goldmark.org./jeff/stupid-disclaimers/>

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

RJ> I'm thinking about rejecting mails, where helo is one of my own
RJ> domains, own IPs, localhost or 127.0.0.1

Congratulations! You've just re-discovered the original purpose of the
argument to the "HELO" verb.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-avoid-helo.html#Constraints>

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

It seems simple enough.

1. UBM sender injects a message with a forged Delivered-To: header into
your system, intending it to be bounced to the actual target:

Envelope:
Sender <Daltonqsnd@obsidiana.com>
Recipient <rhodes@plutomusic.com>
Message:
Delivered-To: rhodes@plutomusic.com
Message-ID: <2002.44.170.199.169.451937CA673D7C9A@flamemail.com>
From: "Norbert Blackman" <Daltonqsnd@obsidiana.com>
Date: Mon, 13 Dec 2004 14:02:57 +0100
To: <rhodes@plutomusic.com>
Subject: info from you bank
Reply-To: rhodes@plutomusic.com

2. qmail-local notices the "loop", ahead of actually making the
delivery, and fails the delivery causing the generation of a bounce message:

Envelope:
Sender <>
Recipient <Daltonqsnd@obsidiana.com>
Message:
Received: (qmail 8828 invoked for bounce); 13 Dec 2004 13:06:21
-0000
Date: 13 Dec 2004 13:06:21 -0000
From: MAILER-DAEMON@mail.chrispyfur.net
To: Daltonqsnd@obsidiana.com
Subject: failure notice

3. Because the SMTP Relay server for the actual target of the UBM, the
envelope recipient of the bounce message, is unreachable for an entire
week ("I wasn't able to establish an SMTP connection. (#4.4.1)"),
qmail-send generates a double-bounce message:

Envelope:
Sender <#@[]>
Recipient <postmaster@mail.chrispyfur.net>
Message:
Date: 20 Dec 2004 15:50:39 -0000
From: MAILER-DAEMON@mail.chrispyfur.net
To: postmaster@mail.chrispyfur.net
Subject: failure notice

This has *nothing at all* to do with your aliases file.

Google