Folks;

   The initial problems I was concerned about are now completely fixed, 
literally by my writing them up for you to read. (I used to call this, 
"restating the problem," and I'm embarrassed I didn't do exactly that on my 
own.) Briefly, the second test I made, creating a one-line virtusertable and 
sending mail to the address in it bounced without an error message to the 
recipient machine, hence the two problems. The latter problem is because the 
machine THINKS it's managing mail for the entire domain (it will, but not yet), 
so tried to deliver the bounce to a local user that didn't exist. My bad. The 
former problem was caused by the setting of $myorigin - by remming that from 
main.cf the default $myhostname apparently applied and was grafted onto the 
user listed instead, which delivered successfully. Again, my bad. I have since 
manually declared it $myhostname in main.cf.

   I do have questions, though, which may seem simplistic but which will help 
me better understand. Feel free to send me to external documents, and yes I 
know I need to spend some quality time later with 
http://www.postfix.org/ADDRESS_CLASS_README.html . Also for explanation, the 
testing virtusertable file is:

webmas...@makodon.com   validuser

   ...and DNS is properly (!?) set up.

   1) May I assume every delivery must have a fully-qualified email address, 
even those to MBOX files on the server?

   2) The following occurred back when I was having bounce issues because of 
the setting of $myorigin. According to the logs, when I sent mail to 
webmas...@makodon.com, it is properly accepted from the external machine (I 
assume because I have it in virtual_alias_domains via a hash of sendmail's 
local-host-names file) and then postfix disconnects from that machine. After 
disconnect, the user validuser is rewritten to validu...@lofcom.com (bad 
$myorigin setting), that fails, then postfix makes a connection to the sending 
machine and delivers the bounce message. It doesn't hold the connection open to 
reject the mail, but rather reports the bounce later with a new message.

   Since I've intentionally forged all of these header fields for the tests 
similar to spam forgeries, doesn't that reconnect imply that postfix could 
cause backscatter spam? Am I doing something wrong that would get postfix to 
follow to the ultimate delivery while the connection is open and reject instead 
of bounce later?

         Charlie

Reply via email to