On Tue, May 13, 2014 at 05:27:26PM -0500, deoren wrote: > 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
No, notice that "pickup" was logged. That means condition 1. > >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. I was only pointing out something which might have rewritten your addresses, but that apparently was not the case here. > >>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 snip > >> > >>/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, No, but you cannot whitelist from header_checks. > but now that I'm having to answer you I believe I see the problem: > header checks run before the smtpd_recipient_restrictions checks? No, header_checks are applied by cleanup(8), which can only occur after smtpd(8) or pickup(8) has received the mail. > >>/etc/postfix/virtual.common.conf:MAILER-DAEMON root snip > If you're referring to the duplicate addresses between /etc/aliases > and /etc/postfix/virtual.common.conf, those are mostly carry over I was. > 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. There is overlap in functionality between aliases(5) and virtual(5) aliases. But the former only applies to local(8) addresses and has extra features beyond mere aliasing, whilst the latter applies to ALL mail and ONLY does aliasing. There's certainly no point in doing the same aliasing twice. snip > >>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? We saw the envelope recipient, which was all we needed to see. <r...@sparky.example.com> was the recipient address that your MUA gave to sendmail(1). Postfix did not see <root>. > 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. Compose your RFC5322-compliant message and pipe it to sendmail. > >>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. Except that the Postfix logging showed that no aliasing was done. Those logs are what I believe. > 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. I can't help it if your software did not document its behavior. Sometimes Debian patches things to make them act differently. If that's the case, perhaps they did not patch the manual? Anyway, that's an issue for Debian and/or their mailutils, not on topic here. > >>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. Fair enough, but do use caution when using third party sites. You often will find that they are wrong or outdated. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
