Prev: Timed out RCPT TO
Next: Testing Postfix EECDH support with OpenSSL 1.0.0
From: Curtis Maurand on 1 Jun 2010 14:09
Hello,
I'm new to the list, but I've been searching the manuals, how-to's, mail
archives, google, etc trying to find the answer to this quesiton.

I have the following setup.

Postfix 2.6.5
Amavisd-new 2.6.3
Spamassassin 3.2.5
clamav 0.96
dbmail 2.2.9

The entire set up works, amavis is a memory and resource hog, but I
digress. Mail is received, forwards to amavis which does what it does
and then forwards to postfix which then delivers to dbmail via lmtp.

I use sql lookups for local recipients, transports and mynetworks.

I have in the main.cf

relay_domains= < a couple of domains> mysql:/etc/postfix/transport.cf
transport_maps = mysql:/etc/postfix/transport.cf
local_recipient_maps=mysql:/etc/postfix/sql-recipients.cf
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_client_restrictions = permit_mynetworks, reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rb
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unlisted_recipients

the only problem I'm having is that this system is not rejecting
unlisted recipients. I know that I'm missing something and I just can't
quite put my finger on it.

If you need further details, feel free to ask.

thanks in advance,
Curtis Maurand


From: Victor Duchovni on 1 Jun 2010 14:22
On Tue, Jun 01, 2010 at 02:09:23PM -0400, Curtis Maurand wrote:

> I have in the main.cf
>
> relay_domains= < a couple of domains> mysql:/etc/postfix/transport.cf
> transport_maps = mysql:/etc/postfix/transport.cf

Don't use the transport table directly as a relay domain table, some day
you'll need special routing for an external domain, that will become an
inadvertant relay domain.

Also, it is best to avoid mysql, ldap, ... for the transport table and
relay domain list. These are used by the queue manager (via trivial-rewrite)
and are performance critical. I recomment indexed files for these, not
database sources.

> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination,
> reject_unlisted_recipients
>
> the only problem I'm having is that this system is not rejecting unlisted
> recipients. I know that I'm missing something and I just can't quite put
> my finger on it.

You have not defined "relay_recipient_maps".

--
Viktor.

From: Curtis Maurand on 1 Jun 2010 15:13
On 6/1/2010 2:22 PM, Victor Duchovni wrote:
> On Tue, Jun 01, 2010 at 02:09:23PM -0400, Curtis Maurand wrote:
>
>
>> I have in the main.cf
>>
>> relay_domains=< a couple of domains> mysql:/etc/postfix/transport.cf
>> transport_maps = mysql:/etc/postfix/transport.cf
>>
> Don't use the transport table directly as a relay domain table, some day
> you'll need special routing for an external domain, that will become an
> inadvertant relay domain.
>
I have lots of email addresses that need to be delivered to the dbmail
lmtp agent. How would you suggest I map those. Currently they go via:

left hand: domain.tld right hand: dbmail-lmtp:127.0.0.1:24

I was editing the table by hand, but it seemed to be easier to do via
the dbmail administrator and the mysql lookup. two domains, I'm simply
filtering mail for and then sending along to their exchange server via
smtp (sort of a postini type service.).


> Also, it is best to avoid mysql, ldap, ... for the transport table and
> relay domain list. These are used by the queue manager (via trivial-rewrite)
> and are performance critical. I recomment indexed files for these, not
> database sources.
>
such as a regular map file (e.g. hashtable)? That becomes unwieldy and
unscalable for a large number of domains doesn't it. Isn't that the
reason for using mysql? It does these types of lookups very fast.
There is also the added advantage that I can index that table. I
suppose I could write an interface to a hash table, but not fun.

> You have not defined "relay_recipient_maps".

That was the problem. Its now working as advertised.

Thanks,
Curtis

From: Stan Hoeppner on 2 Jun 2010 20:57
Curtis Maurand put forth on 6/1/2010 2:13 PM:

> I was editing the table by hand, but it seemed to be easier to do via
> the dbmail administrator and the mysql lookup. two domains, I'm simply
> filtering mail for and then sending along to their exchange server via
> smtp (sort of a postini type service.).

You need to be using recipient address verification. It was designed
specifically for this scenario. It is realtime and fully automatic, using
SMTP queries to downstream servers to determine valid users. Set it up once
and you're done. No databases to maintain.

As an example, Nortel Networks uses this technique (although with qpsmtpd, not
Postfix, IIRC) to route mail through a few smtp gateways to hundreds of
internal domains and over 50k+ users worldwide. They have divisions using MS
Active Directory and Exchange, some using Novell eDirectory and Groupwise,
some using Lotus Notes, others using ??. The sheer magnitude of attempting to
tie all of these disparate systems together just to identify valid recipients
would have cost multiple millions and would have never worked correctly due to
directory synchronization issues.

SMTP based recipient address verification was(is) the simple, elegant
solution, as all of these disparate mail platforms have SMTP in common, and
SMTP has a mechanism for recipient address verification. In essence this
solution is "free" of cost and complexity, and works extremely well.

It's really the only way to fly:

http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient


--
Stan

 | 
Pages: 1
Prev: Timed out RCPT TO
Next: Testing Postfix EECDH support with OpenSSL 1.0.0