On Tue, Dec 29, 2009 at 12:59:13AM +0100, Christoph Anton Mitterer wrote:
> On Mon, 2009-12-28 at 14:27 -0500, Victor Duchovni wrote:
> > The trivial-rewrite service does the rewriting, and the cleanup service
> > updates the queue-file updating addresses in headers, ...
>
> > No, but smtpd(8) uses normalized (via trivial-rewrite) recipient
> > and sender addresses to make access decisions. The original addresses
> > are passed to cleanup(8).
> So this means that address rewriting is done (at least) twice.
No, it means that address *normalization* to standard form is done
at least three times:
- smtpd resolve envelope addresses to
(transport, nexthop, standard form)
for access checks
- cleanup normalize envelope (and possibly headers)
to standard form. Rewrite envelope and perhaps
headers via canonical_maps, masquerade_domains,
virtual_alias_maps, ...
- qmgr resolve envelope recipients to
(transport, nexthop, standard form)
> 1st at smtpd receiving level (but done via trivial-rewrite)
> 2nd at cleanup level (also done via trivial-rewrite)
> Right?
No, because real rewriting (not just conversion to normal form) is
done in cleanup.
> (And of course there may be later stages where addresses are rewritten,
> e.g. generic or local aliases)
Don't confuse transformation to normal form with real rewriting.
> These rewritings at stage 1 (what you called "normalised",... what do
> they include? I assume only those at
> http://www.postfix.org/ADDRESS_REWRITING_README.html#standard
Yes.
> but not
> the ones (canonical, etc.) below that chapter, right?
Yes.
> > No, it is trivial-rewrite that determines the address class of a
> > recipient, this data is consumed by smtpd.
>
> So address class determination also happens, twice?
Yes, in smtpd and each time a recipient enters the active queue.
Cleanup(8) does not need address class information.
> 1st at smtpd level (via trivial-rewrite) just in order to determine,
> whether the domain is recognised an will be deliverable.
> (This should only happen if something like
> reject_unauth_destination is used, and the address class is actually
> required?)
It is possible to create configurations in which smtpd does not consult
trivial-rewrite. These are configurations that perform no sender or
recipient address based lookups, all policy depends only on SMTP client
information. No logging of the envelope is configured.
> 2nd when mail is delivered (I assume qmgr invokes trivial-rewrite this
> time) to determine the transport.
Yes, each time the message enters the active queue from "incoming"
(first time) or "deferred" (subsequent times as necessary).
> > > 2) Further I assume, that already smtpd checks whether the envelope
> > > recipient address matches any of the configured domains, and I think this
> > > happens before most address rewritings (except app...@origin and
> > > append.domain).
> >
> > The address class of a recipient is determined by trivial-rewrite after
> > basic normalization (analogous to Sendmail's ruleset 3 canonicalization).
>
> Ok it's determined by trivial-rewrite, but smtpd (if
> reject_unauth_destination is used) "checks" whether it is deliverable.
"Deliverable" is a poor term of art in this context. The question
is whether the Postfix server is a "final" or "relay" destination
for the recipient address. Only these are accepted from untrusted
clients.
> > > It is not enough if e.g. virtual aliasing rewrites f...@exmaple.net to
> > > f...@localhost (which I assume to be part of mydestination).
>
> > Remote addresses are not accepted, even if the remote address happens
> > to be rewritten to a local mailbox.
> Ok here I have one additional question:
> I understand (at least I hope this is now correct ^^), that at smtpd
> level, the domain part of an address is checked whether it can be
> delivered (and if not => "Relay access denied") AND that any rewrites
> after the normalisations (@myorigin, .domain) are not used for this.
> So even if virtual aliasing rewrites u...@remote.domain to
> u...@virtual.aliased.domain or u...@virtual.mailbox.domain or
> u...@virtual.relay.domain or u...@virtual.local.domain it's NOT accept.
> Right?
Yes.
> But...
> It seems that exactly this works for the recipient!
> What I tried was:
> mydestination = example.com remote.domain
Why did you add a remote domain to "mydestination"? In what sense is it
"remote" after that change?
> I'd have expected that this does not work, and only local users would be
> accepted as recipients. However, it worked (perhaps I should
> triple-check it ^^)
Your expectation is most peculiar in this case. The "remote" domains
are exactly those that are not listed in one of the not "default"
address classes:
http://www.postfix.org/ADDRESS_CLASS_README.html#classes
> > > So virtual aliasing allows in principle some kind of relaying as the
> > > rewritten address might be any remote address?!
>
> > No, not relaying, rather forwarding of mail from a domain you own and
> > control (the virtual domain) to a real mailbox associated with a user
> > in the virtual domain. The "pobox.com" folks come to mind.
>
> Ok your wording is much better, but that's what I've meant.
> Anyway,... why does postfix accept this forwarding?
Because you own the original recipient domain, MX records for it point
at your server, and you and can do with it as you please. Or because
some unlucky SMTP clients are configured to use your system as a relay,
and you choose to misdirect mail for various remote domains. :-)
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
