This question is a side-result of following Falko's excellent "The Perfect Setup" Debian Etch tutorial. With SMTPAuth turned on, I'm having an issue when I try to autoforward mail to the ISP inbox of my hosting client's local mail provider. Here's the scenario... I have Postfix installed on my etch 4.0r3 server together with the dovecot (IMAP and pop3) server, SMTPAuth, and TLS together with squirrelmail as my web mail client and SpamAssassin as my spam filter. I basically followed Falko's tutorial when setting up the server (with a couple of exceptions). This stuff all works fine and none of those apps per se seems to have any direct bearing on my current issue. Here's the problem I'm having... When I send an email to an inbox on the server, it arrives just fine. It can be downloaded and read with a mail client or accessed and read online using squirrelmail. However, if I set that same inbox up to autoforward all mail it receives to another location on the net using the sendmail/postfix “.forward” file (i.e. the final target email address is not actually ON my server but is the user’s private email inbox at their own ISP), I get the message I sent bounced back to me with the following error: [email protected] SMTP error from remote mail server after RCPT TO:: host mail.hissite.com [208.18.180.68]: 554 5.7.1 : Relay access denied This is a very common mail scenario for many of my hosting clients. They use an email inbox address on the server where their site is located with their site name attached but then they want the incoming emails forwarded to their inbox at their local ISP. It's a simple and perfectly legitimate mail forwarding request that I've used successfully for years. It appears SMTPAuth is blocking this because it sees it as a mail relay; but that’s exactly how it’s supposed to work and it's configured on my own server for gosh sakes. There are no nefarious tricks here. This is NOT some insidious spamming or anonymous email trick. It's just forwarding the emails from one or more sites to a single client inbox. Surely there must be some easy way around this "relay access denied" problem. This seems to me like a situation where SMTP has gotten a bit overzealous. Can someone please tell me how to work around this problem? Thanks!
Sure, Falko. Here it is verbatim. The only change I made was to mask the names of the domains on the server. Code: # See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings delay_warning_time = 4h # TLS parameters smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key smtpd_use_tls = yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. myhostname = myhost.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = myhost.com, exx015503, localhost.localdomain, localhost, onedomain.com, anotherdomain.com, thirddomain.com, relayhost = mynetworks = 127.0.0.0/8 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all smtpd_sasl_local_domain = smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination smtpd_tls_auth_only = no smtp_use_tls = yes smtp_tls_note_starttls_offer = yes smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom header_checks = regexp:/etc/postfix/header_checks # Enable sendmail spamass-milter configuration # milter_default_action = accept # smtpd_milters = unix:/var/run/sendmail/spamass.sock Does this help? I've looked at this file for hours; but I'm reluctant to change anything for fear I will screw something else that seems to be working up. Perhaps I should explain here that after I had SpamAssasin working, I started to install milters as well and then decided that was overkill. So I removed and purged all the milter stuff. That explains why some milter stuff is showing here but it's commented out. As a friend of mine is fond of saying, "If it's my fault, I'd at least like to know how 'I screwed the pooch'." Thanks a lot for at least replying.
Clarification question... Does the line that reads: Code: mydestination = myhost.com, exx015503, localhost.localdomain, localhost, onedomain.com, anotherdomain.com, thirddomain.com, need to be updated (i.e. does the domain list there need to be expanded) each time we add a new domain to the server?
Never Mind... It was MY fault (as usual) While posting the main.cf as requested by Falko, I noticed the "mydestination = " list containing the Domain names that is embedded in that file and realized it only contained my test domains. I manually populated that list with my list of test domains when I was installing Postfix a week ago; but I overlooked the fact (though it should have been obvious) that the "mydestination = " list in /etc/postfix/main.cf ABSOLUTELY MUST be updated when new domains are added to the server and had thus failed to add my newly migrated domains to it when I started moving existing domains to the server. The fact that the domains were not listed in that table was BOTH preventing the delivery of inbound mail and the autforwarding of ANY mail involving those domains. So, after posting my follow-up question about that list earlier, I went back and added the domains I've manually migrated from the old server to the new one to that list. Then I restarted the server and did some further testing. What I eventually realized was it was the fact that the migrated domains had not been added to the "main.cf" domain list that was preventing mail sent to recipients at those domains from being delivered and from being forwarded too. Once I added all the domains that now reside on the new server to that list, auto forwarding and mail delivery started working fine for all the newly migrated domains. In addition to defining each new domain in Apache (in sites-available), and mararc (the maradns config file) and adding them to the maradns directory, and creating entire directory structures for them wherever the domain will be reside in the file system, here's yet ANOTHER place where each virtual domain on the server must be identified and listed in order for mail forwarding to work right. Postfix and SMTPAuth allow auto forwarding if the domain is listed in this table. But they refuse to forward if the domain is NOT listed here. Needless to say, I missed this one. And THAT explains exactly HOW I screwed the pooch! Hopefully, my tracks in the sand will be useful to someone else one day. Sorry, Falko. I hope I didn't waste TOO much of your time! Best Professional Regards, WebSissy
