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. 1st at smtpd receiving level (but done via trivial-rewrite) 2nd at cleanup level (also done via trivial-rewrite) Right? (And of course there may be later stages where addresses are rewritten, e.g. generic or local aliases) 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 but not the ones (canonical, etc.) below that chapter, right? > 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? 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?) 2nd when mail is delivered (I assume qmgr invokes trivial-rewrite this time) to determine the transport. > > 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. > > 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? But... It seems that exactly this works for the recipient! What I tried was: mydestination = example.com remote.domain virtual_alias_maps = hash:file file: nonexistinu...@remote.domain r...@example.com Obviously there's no local user "nonexistinguser". 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 ^^) So I think my question is: Why does this work? And when does the recipient checking take place? (Also multiple times?) > > 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? Probably because the mail is already beyond all domain/recipient checks? If it's a remote domain (and I do not include relay domains this time), the default transport is used, isn't it (well unless there is a more specific transport override for that domain). Thanks for your time Victor! :) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
