On 7/29/2011 4:40 PM, Victor Duchovni wrote:
> On Fri, Jul 29, 2011 at 11:34:54PM +0200, Andrea Ganduglia wrote:
> 
>>> This is not difficult, as long as you don't override postfix' default
>>> behaviour with silly transport_maps that don't work.
>>
>> Without transport_maps it doesn't works. If I set virtual_transport =
>> dovecot log returns relay=none
> 
> The "virtual_transport" setting only applies to domains that are listed
> in virtual_mailbox_domains. If adding the domain to the transport table
> works, while setting virtual_transport does not, clearly the domain
> is not listed in virtual_mailbox_domains.

Andrea, Viktor gives you the knowledge to make Dovecot deliver/sieve
work properly.  Now, once you get the submission service setup correctly
you should be squared away.

You may want to add restriction exclusions to your submission daemon to
prevent potential problems caused by your restrictions in main.cf or
Spamassassin.  Doing so also reduces or eliminates delays.  This delay
issue can be critical on high volume relays, probably less important on
small hosts.  You may also want to use 587 instead of submission.
Something like this:

587      inet  n       -       n       -       -       smtpd
        -o smtpd_enforce_tls=yes
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o content_filter=

This service is meant for PCs running MUAs such as Thunderbird and
Outlook to submit their mail for delivery, whether to addresses within
your domain, or external addresses.  You configure the clients just as
you would an ISP setup, with the IP address of the server, port TCP 587,
username, and password.

You can't properly test this submission service directly from a shell on
the Postfix server itself with something like the mail command, as you
mentioned on the Dovecot list that you had tried.  You need to test
submission from a remote MUA.  The reason for this is that Postfix
resembles, say, a train terminal with many tracks leading into the
terminal.  Mail is transmitted to Postfix from different sources and
travels down different tracks.

For example, internet mail arrives on 'track' 10.10.10.10:25, subjected
to various restrictions, content filters, etc, and is delivered locally.
 Mail arriving from a webmail application running on the Postfix machine
may arrive on 'tracks' localhost:25, localhost:587, or maildrop/pickup.
 Mail arriving from remote MUAs for relay or local delivery may arrive
on 10.10.10.10:587.  Mail that has entered the system and is sent to a
content filter may arrive back into Postfix on localhost:10025.  Mail
arriving via the UNIX 'mail' command is read from a file in the maildrop
directory and enters Postfix via 'track' pickup.

Because of this, mail sent via the shell command 'mail' will not go down
the :25 or :587 'tracks', or any others.  This is obviously not a valid
test of the :587 track, or the :25 track.  The mail command is of
limited testing use with Postfix.

-- 
Stan

Reply via email to