[TAG] Undeliverable Mail
rick at linuxmafia.com
Fri Aug 18 01:13:52 MSD 2006
Quoting Claude S. Sutton (claudesutton at cognisurf.com):
> Since I broke mutt, this is a fresh start on the subject without any
> copied text, so I may miss a few points.
Not a problem. Nobody's annoyed at you, Claude. We just sometimes
frown a bit when it seems as if communication is a bit unclear.
> I sent that reject with all of the headers because at one point Rick
> asked for it.
Indeed, and thanks. Just please bear in mind that I get a _ton_ of
e-mail, and when I get a copy of somebody's DSN lobbed over to me,
or especially several in a few individual mails, it doesn't hurt to
remind me what I'm supposed to do with them.
> I know exactly what the 550 said. It said suttonmachine.com does not exist.
Well, actually, it said that the mail from "claudesutton at suttonmachine.com"
was being refused because "claudesutton at suttonmachine.com" didn't seem
to be a deliverable address. That's _different_ from the domain not
> Limited as my knowledge is, I can do a whosis on suttonmachine.com and get:
> host suttonmachine.com suttonmachine.com has address 184.108.40.206
> suttonmachine.com mail is handled by 10 hermes.ncaccess.net.
> suttonmachine.com mail is handled by 20 triton.ncaccess.net.
Yes, this proves that there are two designated hosts for receipt of
suttonmachine.com's incoming e-mail, listed in the DNS. Note that this
doesn't prove that the listed machines will actually perform that
function, only that records in the DNS claim they will. It's where
other MTAs will _attempt_ to deliver all mail addressed to mailboxes
in suttonmachine.com (hermes by preference, triton if hermes can't be
reached). Whether they will _succeed_ or not depends on whether hermes
and triton are prepared to accept that mail.
One standard way of testing the latter assumption is to carry out a
_manual_ delivery attempt, using telnet to port 25 (SMTP port) on one or
both of the mail exchangers. Ben showed more-or-less how to do this in
a recent e-mail. (The SMTP commands he typed in the transcript he
posted were "EHLO" (or you could use "HELO", as I do, being a
technofossil), "MAIL FROM:", "RCPT TO:", and "QUIT" (which he didn't
show). That's almost all the SMTP you need to know how to speak; the
other useful commands are "DATA", "." (to terminate a "DATA" stream),
and "HELP". ;->
Ben's post is archived here:
(You too can speak SMTP like a native!)
> As you know, that can be pursued to the point that we get phone numbers
> and post office boxes. And the name of the tech administrator.
Yes, but it's really handy to be able to say "Tech Administrator, your
MX for my suttonmachine.com domain, which you guys virtual-host for me
and I pay you $100 CDN for every month, is refusing all incoming mail
with a '550 5.7.1 Relaying denied' DSN, and I have the telnet sessions
to prove it. You suck."
> So my question really was: If that is the case, is my machine doing
> something to that address to mangle it so that Rick's machine is looking
> at something other than suttonmachine.com?
Something that's never really been clear to me: Which machine is "your
machine"? This has made diagnosis a bit fuzzy.
I initially entered this discussion with the assumption, which is now
looking increasingly unlikely, that your Postfix box, the one that keeps
identifying itself as "localhost.localdomain", was trying to be a
full-service Internet mail host, and was handling (sending and
receiving) mail for your domains(s) on its own. I apologise for my
tunnel-vision on that matter: I tend to wrongly assume that other
people are doing it, because it's what I do.
Upon re-parsing in my head some of your recent posts, I'm now surmising
that your Postfix box is a "satellite" SMTP system in the sense that it
isn't listed as an MX in your domains' DNS records, that by design all
incoming mail from your domains is supposed to arrive at your ISPs' mail
hosts as their end-SMTP-destination, only later at your convenience
being picked up by your _own_ machine using fetchmail or something like
that (via IMAP or POP3). Instead, your Postfix box's MTA simply hands
off all outgoing SMTP to an ISP "smarthost", which takes it from there
(the Postfix box fulfilling, as Ben and I noted, the perfect role for a
Upon further reflection, one of the difficulties _all_ of us have been
having in this discussion is that your Postfix box doesn't seem (as far
as any of _us_ know) to have a _name_.
Unix boxes have names! That's one of the basic, fundamental things
about them, that a lot of newcomers aren't used to. I'd forgotten about
how this tends to startle people, but in the past have had a rather mean
and sadistic habit of, when walking people through Linux installers,
taking some glee from their confusion:
Rick: OK, the installer is now asking you for a name for your machine.
Joe User: A what?
Rick: A name. The thing you call it. Pets have names, people
have names, one bloke even named his car "Dick Turpin" because,
everywhere it goes, it holds up traffic. The moniker. The
appellation. The cognomen. Handle. Epithet. Designation.
Traditionally in Unix, a single, short string of letters with
optional non-leading numbers and no embedded spaces. Something
you wouldn't mind typing. Short is good.
Joe User: Er... let's just call it "joe".
Rick: No, Joe is the guy you shave. We're talking about one of your
computers. You are not your computer, unless I'm missing
Joe User: Er... <lost in a cloud>
Sysadmins are Not Nice People. ;->
I'm betting your Postfix box keeps coming up as "localhost.localdomain"
because you didn't supply a name for it. (Ben said something about that
To reiterate, it seems likely that Postfix is attempting to pick up the
hostname from /etc/hosts as a fallback measure, since no name is
declared in main.cf . All it finds in /etc/hosts is
"localhost.localdomain" (associated as the primary name with loopback IP
address 127.0.0.1, on line one), so it goes with that. Which is
The correct way to fix that would be to declare a specific hostname on
Postfix's main.cf, or in the appropriate configuration file for whatever
nullmailer MTA you're currently using in place of Postfix. I'm not
personally supplying details on that recommendation because I'm a user
of neither Postfix nor any nullmailer -- but I'm sure people on TAG
can help you, if you ask.
However, that is not actually the problem you are currently asking
about, which concerns why your mail is getting rejected.
Getting back to your two questions:
> So my question really was: If that is the case, is my machine doing
> something to that address to mangle it so that Rick's machine is
> looking at something other than suttonmachine.com?
To repeat: You are sending out messages purporting to be from
"claudesutton at suttonmachine.com". My system is refusing that mail
because your MXes (mail exchanger hosts) for domain suttonmachine.com
refuses to accept mail addressed to "claudesutton at suttonmachine.com".
> Or is it possible that Rick's system is too picky and rejecting
> something it should not be?
No. The RFCs say that any sender address ("From:" address) must be
deliverable. My MTA is simply quite a bit more militant than most about
insisting on observance of that requirement, verifies compliance
before saying yes or no to the delivery attempt, and refuses mail from
claimed sending addresses that don't verify.
(This catches a tremendous amount of forged mail, pretty much all of it
> Neil Youngman posted this, to which no one replied:
> ;; QUESTION SECTION:
> ;suttonmachine.com. IN MX
> ;; ANSWER SECTION:
> suttonmachine.com. 86400 IN MX 20 triton.ncaccess.net.
> suttonmachine.com. 86400 IN MX 10 hermes.ncaccess.net.
> ;; Query time: 149 msec
> ;; SERVER: 192.168.1.1#53(192.168.1.1)
> ;; WHEN: Wed Aug 16 07:52:50 2006
> ;; MSG SIZE rcvd: 93
Again, that merely proves that two MXes are listed in the DNS,
_claiming_ that they'll accept mail addressed to "suttonmachine.com".
Unfortunately, Ben proved that hermes, the primary (low-numbered) MX,
refuses that mail when you try to actually send some.
> Finally, I have copied myself to that address to see that it is still
> working, and it was as of last night.
Ah, a classic pitfall: You sent a test message _from_ your domain _to_
the domain. That probably seems to you like a good way to test, but the
problem is that hermes (your ISP's MX) is turning down mail on account
of unauthorised _relaying_. If you'd sent your test message from, say,
a GMail account, your ISP would have done "550 5.7.1 Relaying denied" on
> So although I confess that I am not as smart as you guys are, I have
> thus far given you credit for being smarter than you are.
You're plenty smart, Claude, and obviously a super-fast learner. A lot
of us have merely been at this an incredibly long time, in addition to
being arrogant and lazy. ;->
 ...which probably is currently running a nullmailer instead of
Postfix, but I call it "your Postfix box" for ease of reference.
 See April Fools Day RFC 2100, which is not entirely facetious:
There's an art to picking a naming scheme for, e.g., a company full of
machines. One company of my acquaintance used the names of the chemical
elements. All of the Solaris boxes were named for noble gases, because
they were mostly inert and unreactive. Another named some of its key
Unix machines for the Seven Deadly Sins and the Seven Virtues. The
firewall machine was "chastity".
The Debian Project uses mostly the names of classical composers
(http://people.debian.org/~joey/misc/naming.html). I use the names of
famous Mafiosi. Some day, I'd like to pick a naming scheme for some
corporate network again, because I'd like to use names of tropical
diseases, in part so mine can be "ebola" or "marburg".
(I should also stress that you do _not_ want to give machines names
indicating their function -- though you can and should assign those as
secondary names that get repointed whenever a function must be migrated
between machines. Thus, if "ebola" catches on fire, mail could be moved
to "marburg" without having to disturb the users just by changing the
relevant DNS "A" and "MX" records for secondary name "mail".)
More information about the TAG