Fallback_transport

harrytk
2011-09-19
2013-01-23
  • harrytk

    harrytk - 2011-09-19

    Hi,

    I am new to postfixadmin and have just done my first installation. My problem is that I would like mail for unknown local users to be relayed to another server, instead of being being rejected. I have done this before with unix accounts using the fallback_transport feature of postfix. How can I achieve the same in postfixadmin where the email accounts are not unix accounts?

    I have tried the following without success:

    local_recipient_maps = $virtual_mailbox_maps
    fallback_transport = smtp:another.server.com

    The error I get is:

    550 5.1.1 <user@domain.com>: Recipient address rejected: User unknown in virtual mailbox table

     
  • Charles

    Charles - 2011-09-19

    Unless you have a really good reason, this is a really bad idea, because it totally BREAKS the SMTP protocol.

    NOT rejecting invalid recipients means that people who typo addresses to your VALID users will never know their intended recipient didn't get the message. It is also *much* more resource expensive to NOT reject them.

    What is your *reason* for wanting to do this?

     
  • harrytk

    harrytk - 2011-09-19

    The reason I'm doing this is because email users on this particular domain are distributed across two servers. There is a central office server and a branch office server. When users at the branch server send mail amongst themselves, the mail is delivered locally on the branch server. If a branch office user sends a mail to a central office user, the branch office server checks that the recipient is not a local user, and then forwards to the central office server.

    I have had this working fine on a basic postix setup wit out postfixadmin. It is the fact the the mailboxes on a postfixadmin setup are mysql lookups that has me stumped.

     
  • Charles

    Charles - 2011-09-19

    I understand, and yes, this 'will work', but you are solving the problem incorrectly. As I said, you are breaking the SMTP protocol, and creating a situation where users who typo valid addresses will never know it.

    What you need to do is setup a transport on the branch office server *for those specific users not located there*, pointing to the central office server.

    Yes, this is a little more work, but it is the correct way to solve the problem. You could also script it so that it is less work, if there are a lot of users and a lot of changes happening all the time.

    I guarantee you are losing mail the way it is set up now, even though you may not know it.

     
  • Simon Hobson

    Simon Hobson - 2011-09-19

    Personally, how I'd tackle a setup like this would be :

    Configure branch office server to handle a subdomain - eg "user@branch.company.com"
    Configure head office server to correctly handle mail for branch.company.com - normally forward it to the branch office server
    In the "company.com" domain, forward mail for branch office users to the branch office - ie create aliases "user@company.com" -> "user@branch.company.com".

    Now, the trick is to configure the branch office clients to log in to the branch office server using username "user@branch.company.com", but use "user@company.com" in the email body & envelope as the sender. Even Outlook  can manage this !

    Mail will now all "just work" without having any spam-friendly "catch all" email addresses or forwarding emails that will then bounce* when the branch office server rejects the unknown address. It's also scalable to multiple branch offices. The only sub-optimal bit is that if user1@branch.company.com sends an email to user2@branch.company.com and user2 doesn't exist, the bounce message will go to the main office server first.

    With a bit of effort you can also have the branch office server handle mail for the main domain - you need to configure to handle relay domains/backup MX about which I think I posted some config notes not too long ago. Ideally though you need some scripting to keep the two databases in sync - but that applies (to a lesser degree) when keeping the main server in sync with accounts on the branch office server as well.

    * I have strong views that you either reject a message or deliver it, and that means pre-queue spam/malware scanning. And in cases like this, only accepting mail to accounts you know to exist on the second server. Once you have accepted a message without doing this, you are stuck between a rock (are you going to be part of the spam problem and silently throw away the message ?) and a hard place (are you going to be part of the spam problem by sending a bounce message ?).

     
  • harrytk

    harrytk - 2011-09-19

    creating a situation where users who typo valid addresses will never know it.

    I don't understand why this is a problem. If you typo an email address, the server won't find the mailbox and bounce it anyway.

    E.g. if I type "jhn@domain.com" when I actually wanted to type "john@domain.com", and jhn@domain.com is not a valid mailbox, I fully expect my server to reject that mail.

    Perhaps, what I should also explain is that users on the branch server also have mail boxes on the central server. The branch server fetchmails their mail to their local mail boxes. There are less than 10 users on the branch server, and over 100 users on the central server. The central server is also the destination MX for this email domain.

    Going back to my example, if jhn@domain.com doesnt exist on the branch server, the branch server should forward the mail to the central server. Most likely jhn@domain.com will also not exist on the central server, which will then generate the undeliverable error.

     
  • harrytk

    harrytk - 2011-09-19

    Simon,

    That is a good solution. However, the head office server is a hosted service, where I don't have full control. I'l have to check with the hosting provider if this possible.

     
  • Charles

    Charles - 2011-09-19

    > I don't understand why this is a problem. If you typo an email address, the server won't find the
    > mailbox and bounce it anyway. E.g. if I type "jhn@domain.com" when I actually wanted to type
    > "john@domain.com", and jhn@domain.com is not a valid mailbox, I fully expect my server to
    > reject that mail.

    What you are missing is 'bounce' is absolutely NOT the same t hing as 'reject'.

    But the main reason that invalid recipients should always be smtp REJECTED, not accepted *then* bounced, is, bouncing them after they've been accepted makes you a BACKSCATTER source, and *will* eventually get you on one or more blacklists - sometimes quickly, in case of a dicstionary attack on your server, or if you handle a large volume of mail daily.

     
  • Simon Hobson

    Simon Hobson - 2011-09-19

    Now you've added details that considerably change the picture. I, and I imagine libertytrek, have assumed that the main server was also yours AND that you were using SMTP for mail transfer between them. The fact that the main server is hosted, and that you are using fetchmail, does change the landscape significantly !

    I'm not familiar with the option you've been using, so I can;t help there. But, what I can say is that the objections both of us had are almost certainly negated now.

    The fact that the main server has mailboxes for all the branch office users means it knows what addresses to accept mail for - and so it can reject mail from outside users for invalid addresses. Since you are running your own, well behaved, server then the same applies to mails from your branch office users - they will correctly get a bounce from the branch office server when the message is rejected by the main server.
    Assuming the branch office server isn't relaying mail, no outside sources should be able to send mail and so you won't be creating backscatter.

    You could still run your branch office server on a subdomain. The main downside is that mails between branch office users will go out to the main server and back again - thus generating outside traffic and delaying mail receipt according to the fetchmail schedule.

     
  • harrytk

    harrytk - 2011-09-19

    Glad my situation is now understood. I could have saved a lot of time with a better explanation initially!

    I want to turn off rejecting mail for unknown local users on the branch server, and instead forward to the central server.

    With unix accounts it's trivial:
    local_recipient_maps =
    fallback_transport = smtp:another.server.com

    This just doesn't work with Postfixadmin and virtual users/domains and the server still rejects mail for unknown local users.

    I've picked a similar thread while Googling, http://permalink.gmane.org/gmane.mail.postfix.user/220679, and they are saying basically that it's not possible. Surely not?

     
  • Charles

    Charles - 2011-09-20

    "I want to turn off rejecting mail for unknown local users on the branch server, and instead forward to the central server.

    With unix accounts it's trivial:
    local_recipient_maps =
    fallback_transport = smtp:another.server.com

    This just doesn't work with Postfixadmin and virtual users/domains and the server still rejects mail for unknown local users.

    I've picked a similar thread while Googling, http://permalink.gmane.org/gmane.mail.postfix.user/220679, and they are saying basically that it's not possible. Surely not?"

    Actually, that thread *does* contain the *correct* solution, and it is quite simple… don't use transport maps.

    Use 'virtual_alias_maps' to specify the users *that require local delivery*, then define your central server as the 'relayhost', and it should just work.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks