On 2014-05-13 14:46, /dev/rob0 wrote:
On Tue, May 13, 2014 at 02:15:48PM -0500, deoren wrote:
If I send an email to 'root' and $myorgin is set to $mydomain
(which is also set properly), shouldn't 'root' be qualified as
root@$mydomain (i.e., r...@example.com)?
Correct, see:
http://www.postfix.org/postconf.5.html#append_at_myorigin
Thanks for that link. If I read over that specific conf setting in the
past it's been so long that I don't remember doing so. Looking at "Note
2" on that page I see this:
Note 2: with Postfix version 2.2, message header address rewriting
happens only when one of the following conditions is true:
* The message is received with the Postfix sendmail(1) command,
* The message is received from a network client that matches
$local_header_rewrite_clients,
* The message is received from the network, and the
remote_header_rewrite_domain parameter specifies a non-empty value.
Running postconf on the mail server I get this back:
root@sparky:~# postconf append_at_myorigin local_header_rewrite_clients
remote_header_rewrite_domain
append_at_myorigin = yes
local_header_rewrite_clients = permit_inet_interfaces
remote_header_rewrite_domain =
Since I'm submitting locally I assume that means condition 2 is met
($local_header_rewrite_clients) and the "@$myorigin" string is written
to mail addresses without the domain information.
recipient_canonical_classes = envelope_recipient
recipient_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
tcp:127.0.0.1:10004,
sender_canonical_classes = envelope_sender
sender_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
tcp:127.0.0.1:10003,
But here you seem to be using canonical(5) rewriting.
I am. As a SRS solution I installed pfix-srsd which is in charge of
mangling the envelope address in order to pass remote SPF checks. Manual
for that tool:
https://github.com/Fruneau/pfixtools/blob/master/pfix-srsd/pfix-srsd.asciidoc
I'm hoping to eventually replace it with another tool that doesn't
mangle the log entries and also reliably translates bounce messages
(right now only a virtual alias wildcard saves them from going into a
black hole). I've been too busy with other stuff to find a suitable
replacement yet.
virtual_alias_domains = example.com
virtual_alias_maps = hash:/etc/postfix/virtual.common.conf,
hash:/etc/postfix/virtual.example.com.conf,
and both local and virtual aliases:
grep -i 'root' /etc/aliases /etc/postfix/*.conf | grep -v '#'
postmaster: root
example.com is a virtual alias domain. You're aliasing everything
here to a virtual alias, r...@example.com ...
adm: root
bin: root
daemon: root
exim: root
lp: root
mail: root
named: root
nobody: root
postfix: root
operator: root
ftp: root
hostmaster: root
noc: root
security: root
usenet: root
uucp: root
webmaster: root
/etc/postfix/sender_access.conf:r...@example.com OK
/etc/postfix/sender_access.conf:r...@example.net OK
[ These all look pointless, why do you need them? ]
If you're referring to the /etc/postfix/sender_access.conf entries I was
hoping to whitelist those addresses from the new header checks I added
yesterday, but now that I'm having to answer you I believe I see the
problem: header checks run before the smtpd_recipient_restrictions
checks?
/etc/postfix/virtual.common.conf:MAILER-DAEMON root
/etc/postfix/virtual.common.conf:postmaster root
/etc/postfix/virtual.common.conf:adm root
/etc/postfix/virtual.common.conf:bin root
/etc/postfix/virtual.common.conf:daemon root
/etc/postfix/virtual.common.conf:exim root
/etc/postfix/virtual.common.conf:lp root
/etc/postfix/virtual.common.conf:mail root
/etc/postfix/virtual.common.conf:named root
/etc/postfix/virtual.common.conf:nobody root
/etc/postfix/virtual.common.conf:postfix root
/etc/postfix/virtual.common.conf:operator root
/etc/postfix/virtual.common.conf:abuse root
/etc/postfix/virtual.common.conf:ftp root
/etc/postfix/virtual.common.conf:hostmaster root
/etc/postfix/virtual.common.conf:news root
/etc/postfix/virtual.common.conf:noc root
/etc/postfix/virtual.common.conf:security root
/etc/postfix/virtual.common.conf:usenet root
/etc/postfix/virtual.common.conf:uucp root
/etc/postfix/virtual.common.conf:webmaster root
/etc/postfix/virtual.common.conf:www root
/etc/postfix/virtual.common.conf:scripts root
If you're referring to the duplicate addresses between /etc/aliases and
/etc/postfix/virtual.common.conf, those are mostly carry over from when
I was truly a newbie (not that I'm an expert now) and was looking for a
way to merge the contents into a single file for ease of maintenance.
/etc/postfix/virtual.example.com.conf:r...@example.com
m...@example.net
... And indeed your virtual alias address exists.
I forgot to mention it in the OP, but sending directly to the virtual
alias works fine (not that you're saying there is a problem).
Here are two examples of sending mail to an unqualified 'root'
--------------------------^ faulty testing of
address. One if via the mail command and the other is through
cron handling uncaught output from a job. I would expect that
both would yield the same results, but that's not the case.
* I send an email using the 'mail' command (local user, doesn't
seem to matter which user it is):
echo "Testing" | mail -s "Test email to unqualified root address" root
and it gets delivered to the local 'root' system account
May 13 12:54:01 sparky postfix/pickup[24601]: 98354214B7: uid=0
from=<root>
May 13 12:54:01 sparky postfix/cleanup[24668]: 98354214B7:
message-id=<20140513175401.9835421...@sparky.example.com>
May 13 12:54:01 sparky postfix/qmgr[24600]: 98354214B7:
from=<r...@example.com>, size=388, nrcpt=1 (queue active)
May 13 12:54:01 sparky postfix/local[24673]: 98354214B7:
to=<r...@sparky.example.com>, relay=local, delay=0.1,
delays=0.09/0.01/0/0,
dsn=2.0.0, status=sent (delivered to mailbox)
There is no "orig-to=" here. No rewriting took place.
Agreed. That's what I found confusing.
Your MUA apparently converted the "root" recipient into
"r...@sparky.example.com" before Postfix saw it.
Is there a way to see the raw email that Postfix accepts from the mail
command? Is there a better command-line tool to use for testing
Postfix's address resolution? Basically one that will attempt to send to
the literal address as given instead of trying to do any
conversion/cleanup before handing it off. I saw mention of "sendmail",
but I always assumed it was mainly for compatibility with apps/tools
that expected a sendmail binary.
I remember reading that if you don't have $myorigin specified then
$myhostname will be used as the default value to qualify addresses.
That appears to be what's happening here?
Nope, check your mail(1) manual.
I didn't think it would be, although the behavior did seem to be just
like I had specified $myhostname. I went back and looked again and
didn't see anything which would answer why I was getting the behavior. I
plan to look again, but nothing jumps out at me. I'm using the mailutils
debian package if that helps.
http://www.fredshack.com/docs/postfix.html
Who's this? Just stick with the documentation you got with your own
Postfix, or use www.postfix.org.
I provided that link along with the official documentation link to give
contrast on the different wordings. Both said the same thing, but a
little differently. I was mainly trying to show that I attempted to RTM
before bugging you guys.
