Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

On Sun, 11 Dec 2011 20:03:59 -0500 (EST)
Wietse Venema  wrote:

> Wietse Venema:
> > > bge1 @0:24 b ,25 -> 89.73.201.168,36545 PR
> > > tcp len 20 40 -AR OUT
> > 
> > Why are you blocking outbound TCP RST?
> 
> According to ipmon(8),

The web is rotting my brain.  I never thought to actually check, you
know, the manual page.

Good. Grief.

>-AR means the ACK and RST flags are set.
> My question is why is your firewall blocking outbound ACK|RST?

I'm using basically "canned" rulesets in my ipfilter setup.  That is
the default deny at the end of bge1's output filters.

I must've messed-up, somewhere.  I'll take a look in the morning.

Thanks, Wietse, Sahil, for the education.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: memcache client for Postfix

[Wietse Venema]

Wietse Venema:
> Combining memcache and proxymap
> ---
> 
> It seems that memcache is best for (surprise) doing what it was
> designed for: a cache layer on top of a persistent database, where
> the cache is maintained by the clients of the persistent database.
...
> The idea is that the memcache client delegates persistent database
> access to the proxymap server.  Whenever the memcache client looks
> up or modifies the persistent database, it updates the memcache
> server to keep the cache up-to-date (clearly, cache consistency
> won't be perfect, so information should be cached for only a limited
> time).

Done in postfix-2.9-20111211-nonprod; the code is very lightly tested.

Wietse

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Wietse Venema]

Wietse Venema:
> > bge1 @0:24 b ,25 -> 89.73.201.168,36545 PR tcp len
> > 20 40 -AR OUT
> 
> Why are you blocking outbound TCP RST?

According to ipmon(8), -AR means the ACK and RST flags are set.
My question is why is your firewall blocking outbound ACK|RST?

Wietse

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

On Sun, 11 Dec 2011 18:41:56 -0500
Sahil Tandon  wrote:

[snip]
> 
> Postfix sends a 450 response because your DNS server cannot find the
> client's reverse hostname; following that, the client foolishly
> sends DATA, to which Postfix responds with a 554.  Finally, instead
> of gracefully QUITing, the client drops the connection.   

I see.  So the "odd" ipfilter message is probably as a result of the
client pulling the rug out from under the connection, as it were?

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

On Sun, 11 Dec 2011 19:15:35 -0500
Jim Seymour  wrote:

> Each of them occurs two-or-more
> times, involving the same contacting IP.

Clarification: That was to say that, when it occurs multiple times
in a row, it's the same IP trying over-and-over again in each set of
retries. A total of 17 unique IPs have been involved in such
occurrences today.

In fact: No client has tried less than twice in a row, most have
averaged around six tries.  Some up to a dozen or more.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

On Mon, 12 Dec 2011 01:11:00 +0100
Reindl Harald  wrote:

> 
> 
> Am 12.12.2011 01:04, schrieb Jim Seymour:
> > On Mon, 12 Dec 2011 00:14:08 +0100
> > Reindl Harald  wrote:
> > [snip]
> >>
> >> why do you use "reject_unknown_reverse_client_hostname" if you do
> >> not like the results of it?
> > 
> > Why do you answer the question when you obviously have not read
> > it? (Or at least apparently not understood it.)
> 
> wtf - i have read your log-snippet and explained you what
> "cannot find your reverse hostname" means

I know what "cannot find your reverse hostname" means.

> 
> what "bge1 @0:24 b ,25 -> 89.73.201.168,36545 PR tcp
> len" means i have not commented since i am not a bsd-user, if this
> is your only question so why do you post maillog-snippets?

To show the relationship between the information in the two logfiles.

If it was *purely* a FBSD or ipfilter question (which I allowed as
how it might actually be), I'd have asked in a FBSD or ipfilter forum.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

On Sun, 11 Dec 2011 18:35:23 -0500 (EST)
Wietse Venema  wrote:

[snip]
> 
> Why are you blocking outbound TCP RST?

I am not, to the best of my knowledge.

There is a TCP control traffic rate limit in the border router, there
as a DoS prevention tactic, but that's it.

This doesn't happen all the time.  It doesn't even happen often.  Out
of nearly 6000 connections, today, there are 145 various "A.. OUT" and
"A.. OUT OOW" messages.  Each of them occurs two-or-more times,
involving the same contacting IP.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Reindl Harald]

Am 12.12.2011 01:04, schrieb Jim Seymour:
> On Mon, 12 Dec 2011 00:14:08 +0100
> Reindl Harald  wrote:
> [snip]
>>
>> why do you use "reject_unknown_reverse_client_hostname" if you do
>> not like the results of it?
> 
> Why do you answer the question when you obviously have not read it?
> (Or at least apparently not understood it.)

wtf - i have read your log-snippet and explained you what
"cannot find your reverse hostname" means

what "bge1 @0:24 b ,25 -> 89.73.201.168,36545 PR tcp len"
means i have not commented since i am not a bsd-user, if this is your
only question so why do you post maillog-snippets?



signature.asc
Description: OpenPGP digital signature

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

On Mon, 12 Dec 2011 00:14:08 +0100
Reindl Harald  wrote:
[snip]
> 
> why do you use "reject_unknown_reverse_client_hostname" if you do
> not like the results of it?

Why do you answer the question when you obviously have not read it?
(Or at least apparently not understood it.)

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Sahil Tandon]

On Sun, 2011-12-11 at 18:10:34 -0500, Jim Seymour wrote:

> Looking in /var/log/maillog...
> 
> Dec 11 17:47:08 myhost postfix/smtpd[48290]: connect from
>   unknown[89.73.201.168]
> Dec 11 17:47:10 myhost postfix/smtpd[48290]: NOQUEUE: reject:
>   RCPT from unknown[89.73.201.168]: 450 4.7.1 Client host
> rejected: cannot find your reverse hostname, [89.73.201.168];
>   from= to=
>   proto=ESMTP helo=<89-73-201-168.dynamic.chello.pl>
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
>   after DATA from unknown[89.73.201.168]
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from
>   unknown[89.73.201.168]
> 
> This particular one occurred seven times in a row, in quick
> succession.

Postfix sends a 450 response because your DNS server cannot find the
client's reverse hostname; following that, the client foolishly sends
DATA, to which Postfix responds with a 554.  Finally, instead of
gracefully QUITing, the client drops the connection. 

-- 
Sahil Tandon

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Wietse Venema]

Jim Seymour:
> Hi All,
> 
> This may be a weird one, and may be completely OT.  If the latter:
> Feel free to tell me to bugger off :)
> 
> System is FreeBSD 8.2, running ipfilter and
> postfix-current-2.9.2019,4.
> 
> Occasionally I see something like this from ipfilter in
> /var/log/messages:
> 
> bge1 @0:24 b ,25 -> 89.73.201.168,36545 PR tcp len
> 20 40 -AR OUT

Why are you blocking outbound TCP RST?

Wietse

Re: Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Reindl Harald]

Am 12.12.2011 00:10, schrieb Jim Seymour:
> Occasionally I see something like this from ipfilter in
> /var/log/messages:
> 
> bge1 @0:24 b ,25 -> 89.73.201.168,36545 PR tcp len
> 20 40 -AR OUT
> 
> Looking in /var/log/maillog...
> 
> Dec 11 17:47:08 myhost postfix/smtpd[48290]: connect from
>   unknown[89.73.201.168]
> Dec 11 17:47:10 myhost postfix/smtpd[48290]: NOQUEUE: reject:
>   RCPT from unknown[89.73.201.168]: 450 4.7.1 Client host
> rejected: cannot find your reverse hostname, [89.73.201.168];
>   from= to=
>   proto=ESMTP helo=<89-73-201-168.dynamic.chello.pl>
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
>   after DATA from unknown[89.73.201.168]
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from
>   unknown[89.73.201.168]
> 
> This particular one occurred seven times in a row, in quick
> succession.
> 
> I've searched on this *fairly* seriously and come up with nothing.
> Anybody got any idea what this is?

why do you use "reject_unknown_reverse_client_hostname" if you do not
like the results of it?



signature.asc
Description: OpenPGP digital signature

Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

Hi All,

This may be a weird one, and may be completely OT.  If the latter:
Feel free to tell me to bugger off :)

System is FreeBSD 8.2, running ipfilter and
postfix-current-2.9.2019,4.

Occasionally I see something like this from ipfilter in
/var/log/messages:

bge1 @0:24 b ,25 -> 89.73.201.168,36545 PR tcp len
20 40 -AR OUT

Looking in /var/log/maillog...

Dec 11 17:47:08 myhost postfix/smtpd[48290]: connect from
  unknown[89.73.201.168]
Dec 11 17:47:10 myhost postfix/smtpd[48290]: NOQUEUE: reject:
  RCPT from unknown[89.73.201.168]: 450 4.7.1 Client host
rejected: cannot find your reverse hostname, [89.73.201.168];
  from= to=
  proto=ESMTP helo=<89-73-201-168.dynamic.chello.pl>
Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
  after DATA from unknown[89.73.201.168]
Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from
  unknown[89.73.201.168]

This particular one occurred seven times in a row, in quick
succession.

I've searched on this *fairly* seriously and come up with nothing.
Anybody got any idea what this is?

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

RE: virtual_alias_maps / mysql problem

[James Day]

I think you need to be using virtual_mailbox_maps to create a list of valid 
recipients.

Also I can see that dovecot has also accepted the message so you must have 
configured something like "allow_all_users=yes".


From: owner-postfix-us...@postfix.org [owner-postfix-us...@postfix.org] On 
Behalf Of lupin...@gmx.net [lupin...@gmx.net]
Sent: Sunday, December 11, 2011 4:31 PM
To: postfix-users@postfix.org
Subject: Re: virtual_alias_maps / mysql problem

thank you for the hint!
i activated the query-log and the query is executed ok. i also checked it via
postmap -q hutzenp...@domain.de mysql:/etc/postfix/mysql-virtual.cf
(which correctly did not return anything)
and
postmap -q correctu...@domain.de mysql:/etc/postfix/mysql-virtual.cf
which did return the correct entry, e.g. user169
so it seems mysql is not at fault.

also, when i tested it with a hash-file, it sent "successfully" to an address 
that was not listed in said file.

unfortunately, now i guess i´ll have to check any and all other config 
parameters that have anything to do with virtual delivery ^_^;

here goes the postconf -n:
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
inet_interfaces = 192.168.12.7 127.0.0.1
mailbox_size_limit = 0
message_size_limit = 2048
mydestination = localhost
mydomain = domain.de
myhostname = mail.domain.de
mynetworks = 192.168.12.0/24 127.0.0.0/8
myorigin = $mydomain
relayhost =
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, 
permit_sasl_authenticated, reject_non_fqdn_recipient, 
reject_unknown_recipient_domain, reject_unauth_destination, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = mail.domain.de
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/certs/cert.pem
smtpd_tls_cert_file = /etc/certs/cert.pem
smtpd_tls_key_file = /etc/certs/key.pem
smtpd_tls_received_header = no
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
virtual_mailbox_domains = domain.de
virtual_transport = dovecot

transport_maps reads thus:
domain.de   :
.domain.de  :
*  smtp:192.168.12.8  (this is the external "firewall"-postfix-server)

the mail.log reads thus:
Dec 11 17:05:05 mehl postfix/smtpd[16897]: connect from unknown[192.168.12.1]
Dec 11 17:05:05 mehl postfix/smtpd[16897]: DD60514A03F3: 
client=unknown[192.168.12.1], sasl_method=PLAIN, sasl_username=user169
Dec 11 17:05:05 mehl postfix/cleanup[16901]: DD60514A03F3: 
message-id=<4ee4d4b2.2020...@domain.de>
Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: from=, 
size=858, nrcpt=1 (queue active)
Dec 11 17:05:06 mehl postfix/smtpd[16897]: disconnect from unknown[192.168.12.1]
Dec 11 17:05:06 mehl postfix/pipe[16902]: DD60514A03F3: 
to=, relay=dovecot, delay=0.32, delays=0.18/0/0/0.14, 
dsn=2.0.0, status=sent (delivered via dovecot service)
Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: removed

the address grmblash does not really exist ;-), when i send to an existing 
address, the only "difference" is that postfix/pipe has the correct target as 
to, e.g. user...@dmain.de

thank you all for you hints, i hope this help shed some light on the problem. =)

best regards
sil

 Original-Nachricht 
> Datum: Sun, 11 Dec 2011 15:26:40 +0100
> Von: Reindl Harald 
> An: postfix-users@postfix.org
> Betreff: Re: virtual_alias_maps / mysql problem

>
>
> Am 11.12.2011 15:18, schrieb lupin...@gmx.net:
> > thank you for you reply.
> > virtual_mailbox_domains is set, as is virtual_transport.
> > do you mean using a hash-file to test it or for permanent use?
> > there are some 500 mail-users on the server, who change relatively often
> and who have each a number of aliases..i´d rather avoid using a hash
> file, especially because the mysql-query is supposed to work =)
> >
> > is there some handy way of testing, what postfix receives from this
> mysql-check?
>
> what about activate querylog in mysqld to look what really happens and
> c&p interesting queries into a mysql-shell to look at the results?
>

--
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone


--
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: Changing Users' Mail Spool Destination

[Jim Seymour]

On Sun, 11 Dec 2011 19:30:12 +
Duane Hill  wrote:

[snip]
> 
> You  could  also  use  Dovecot  LDA  or  LMTP. Dovecot will create
> the directory  structure  automatically  upon  the  first login or
> message delivery.

Wouldn't I lose Postfix' header and body processing if I did that?
There's also the "+"d address support, .forward, etc.

I think I can also handle the automatic creation of the ~/mail
directory, and perhaps empty inbox mbox file, in the Linux user
creation stuff.  (Never looked into that yet.)

Anyway: My question was more one of: If I wanted to do it the way I
described: Were the configs I noted really all I need do?

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: recipient_delimiter

[Wietse Venema]

Jose Renato Attab Braga:
> Hi
> I need use the address aaa+xyz@domain when I have the only the
> address aaa@domain.
> In my main.cf I have recipient_delimiter = +.
> I use Mysql to emails adress and domains.
> What do I need to configurate this?

In Postfix, nothing. Postfix will look up aaa+xyz@domain (with the
extension), then aaa@domain (no extension). After Postfix finds
that the address without extension exists, it will accept the email.

You may need to configure Dovecot for the recipient delimiter.

Wietse
> 
> 
> My main.cf
> smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
> biff = no
> append_dot_mydomain = no
> readme_directory = /usr/share/doc/postfix
> smtpd_tls_cert_file = /etc/postfix/smtpd.cert
> smtpd_tls_key_file = /etc/postfix/smtpd.key
> smtpd_use_tls = yes
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> myhostname = mail.example.com.br
> alias_maps = hash:/etc/aliases
> alias_database = hash:/etc/aliases
> myorigin = /etc/mailname
> mydestination = mail.exemple.com, localhost, localhost.localdomain
> relayhost = 
> mynetworks = 127.0.0.0/8
> mailbox_size_limit = 0
> recipient_delimiter = +
> inet_interfaces = all
> html_directory = /usr/share/doc/postfix/html
> message_size_limit = 3072
> virtual_alias_domains = 
> virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, 
> mysql:/etc/postfix/mysql-virtual_email2email.cf
> virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
> virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
> virtual_mailbox_base = /home/vmail
> virtual_uid_maps = static:5000
> virtual_gid_maps = static:5000
> smtpd_sasl_auth_enable = yes
> broken_sasl_auth_clients = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
> reject_unauth_destination
> virtual_create_maildirsize = yes
> virtual_maildir_extended = yes
> proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps 
> $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains 
> $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps 
> $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks 
> $virtual_mailbox_limit_maps
> virtual_transport = dovecot
> dovecot_destination_recipient_limit = 1

Re: Changing Users' Mail Spool Destination

[Duane Hill]

On Sunday, December 11, 2011 at 18:38:07 UTC, jseym...@linxnet.com confabulated:

> On Sun, 11 Dec 2011 13:15:28 -0500 (EST)
> Wietse Venema  wrote:

> [snip]
>> 
>> To turn on maildir support, append a trailing '/' to the name.

> Yes, I caught that.  (But thanks for the note, anyway).  I plan to
> let inbox be mbox format, just like it is in a "normal" mail spool.
> Dovecot is perfectly happy with that.

>> 
>> I don't know if Postfix will auto-create ~user/mail directories.

> That's easily addressed with a simply shell or Perl script I can
> create.  Heck, I could even set up a cron job to make sure they all
> exist, in case I got absent-minded when creating a new user.

You  could  also  use  Dovecot  LDA  or  LMTP. Dovecot will create the
directory  structure  automatically  upon  the  first login or message
delivery.

-- 
If at first you don't succeed, so much for skydiving.

recipient_delimiter

[Jose Renato Attab Braga]

Hi
I need use the address aaa+xyz@domain when I have the only the address 
aaa@domain.
In my main.cf I have recipient_delimiter = +.
I use Mysql to emails adress and domains.
What do I need to configurate this?
Thanks


My main.cf
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
readme_directory = /usr/share/doc/postfix
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
myhostname = mail.example.com.br
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.exemple.com, localhost, localhost.localdomain
relayhost = 
mynetworks = 127.0.0.0/8
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
html_directory = /usr/share/doc/postfix/html
message_size_limit = 3072
virtual_alias_domains = 
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, 
mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /home/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination
virtual_create_maildirsize = yes
virtual_maildir_extended = yes
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps 
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains 
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps 
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks 
$virtual_mailbox_limit_maps
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

Re: Changing Users' Mail Spool Destination

[Jim Seymour]

On Sun, 11 Dec 2011 13:15:28 -0500 (EST)
Wietse Venema  wrote:

[snip]
> 
> To turn on maildir support, append a trailing '/' to the name.

Yes, I caught that.  (But thanks for the note, anyway).  I plan to
let inbox be mbox format, just like it is in a "normal" mail spool.
Dovecot is perfectly happy with that.

> 
> I don't know if Postfix will auto-create ~user/mail directories.

That's easily addressed with a simply shell or Perl script I can
create.  Heck, I could even set up a cron job to make sure they all
exist, in case I got absent-minded when creating a new user.

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: memcache client for Postfix

[Pau Amma]

On Sun, December 11, 2011 5:44 pm, Wietse Venema wrote:
> Combining memcache and proxymap
> ---
>
> It seems that memcache is best for (surprise) doing what it was
> designed for: a cache layer on top of a persistent database, where
> the cache is maintained by the clients of the persistent database.
>
> This means doing something like this:
>
> /etc/postfix/main.cf:
> postscreen_cache_map = memcache:/etc/postfix/postscreen-cache
>
> /etc/postfix/postscreen-cache:
> # Where is the memcache server?
> hosts = host1:port1
>
> # Where is the persistent database?
> persistence = proxymap:inet:host2:port2:persistent-database
>
> # Future: sharding (key hashing) to spread the load across
> # multiple memory caches and persistent databases.

For memcache-level sharding (in the presence of dead/unreachable servers)
you could just do something similar to Cache::Memcached->get_sock and
Cache::Memcached::_hashfunc (see
http://code.livejournal.org/trac/memcached/browser/trunk/api/perl/lib/Cache/Memcached.pm).
Maybe for persistent sharding too, but they can use different functions
for selecting servers.

Re: Changing Users' Mail Spool Destination

[Wietse Venema]

Jim Seymour:
> G'day Postfix'ers,
> 
> I'm in the process of building-up a new company mail server.  It'll
> be an IMAP4 beast, using Maildir, and so I allocated the vast majority
> of the freespace to /home, for IMAP folder storage.  Then it occurred
> to me: I know my users have poor habits, and tend to leave much of
> their email in INBOX forever and ever.  Hmmm... 
> 
> Then it occurred to me: I was pretty certain I'd read that I could
> have both Postfix and Dovecot use per-user inboxen in their home
> directories.
> 
> Do I understand correctly that all I need do is, in main.cf:
> 
> home_mailbox = mail/inbox

To turn on maildir support, append a trailing '/' to the name.

I don't know if Postfix will auto-create ~user/mail directories.

Wietse

Changing Users' Mail Spool Destination

[Jim Seymour]

G'day Postfix'ers,

I'm in the process of building-up a new company mail server.  It'll
be an IMAP4 beast, using Maildir, and so I allocated the vast majority
of the freespace to /home, for IMAP folder storage.  Then it occurred
to me: I know my users have poor habits, and tend to leave much of
their email in INBOX forever and ever.  Hmmm... 

Then it occurred to me: I was pretty certain I'd read that I could
have both Postfix and Dovecot use per-user inboxen in their home
directories.

Do I understand correctly that all I need do is, in main.cf:

home_mailbox = mail/inbox

and in (a bit OT for this list, but while I'm at it), in dovecot.conf:

mail_location = maildir:~/Maildir:INBOX=~/mail/inbox

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: memcache client for Postfix

[Wietse Venema]

One missing word makes all the difference.

Wietse

Wietse Venema:
>> This week I implemented a memcache client for Postfix in the hope
>> that it would be useful to share postscreen(8) or verify(8) caches
>> among multiple MTAs.  
...
> Considering that memcache patches are floating around with several
> problems, and the amount of time that I put into this, I have made
> the Postfix memcache client part of the 2.9 release. This version
> will at least reliably report problems with memcache servers.

Stan Hoeppner:
> Could a (heavily) modified proxymap/proxywrite daemon serve this multi
> host cache sharing duty?  Or would that require more work than writing
> something from scratch?

Short answer: I think we need both to share the postscreen database
among multiple MTAs with adequate performance.  The reason is that
proxymap and memcache solve very different problems.

Below is the long answer, based on an analysis of the different
problems that proxymap and memcache try to solve.

First a few bits of insight about memcache, then a quick look at
proxymap, and finally, how the two can be combined to get the best
of both worlds.

Quick look at memcache
--

Each memcache server is effectively a world-writable network ramdisk
(with obvious security implications).  If used by itself, a memcache
server would be suitable for storing low-value, easy-to-recreate,
data such as the postscreen or verify cache for a cluster of Postfix
MTAs.  All read/writes are from/to memory so they can be very fast.

The advantage of memcache is that it already exists. The protocol
is so simple that I ripped out libmemcache last night and wrote
my own memcache client in a few hours (and that was mostly
pasting little blocks of existing Postfix code together).

Quick look at proxymap
--

The Postfix proxymap server shares connections to (usually persistent)
databases.  In principle, this could be used to share a postscreen or
verify cache between different hosts, after adding some new code:

- proxymap client/server support to forward first/next method calls.
  These are needed for postscreen / verify cache cleanup support.
  Only one proxymap client should invoke these methods.

- proxymap server support for network access control (by default,
  only local client access should be allowed). As before, a proxymap
  reader or writer process will open only databases that are listed
  in main.cf:proxy_read_maps (or proxy_write_maps).

Limitations:

- Only one proxymap writer process per Postfix Berkeley DB database.
  The database can quickly become a performance bottleneck.

Combining memcache and proxymap
---

It seems that memcache is best for (surprise) doing what it was
designed for: a cache layer on top of a persistent database, where
the cache is maintained by the clients of the persistent database.

This means doing something like this:

/etc/postfix/main.cf:
postscreen_cache_map = memcache:/etc/postfix/postscreen-cache

/etc/postfix/postscreen-cache:
# Where is the memcache server?
hosts = host1:port1

# Where is the persistent database?
persistence = proxymap:inet:host2:port2:persistent-database

# Future: sharding (key hashing) to spread the load across
# multiple memory caches and persistent databases.

The idea is that the memcache client delegates persistent database
access to the proxymap server.  Whenever the memcache client looks
up or modifies the persistent database, it updates the memcache
server to keep the cache up-to-date (clearly, cache consistency
won't be perfect, so information should be cached for only a limited
time).

Adding persistence to the Postfix memcache client requires adding
1) interfaces for delete and first/next methods, 2) support to
access a persistent database and 3) support to update the memcache
server whenever the Postfix memcache client looks up or modifies
the persistent database.

I am aware of memcachedb, which combines memcached with Berkeley DB.
The advantage of the approach above is that it would combine memcache
with any persistent database, for example, mysql, once Postfix write
support is completed. That said, Postfix will never allow the use
of memcache for security-sensitive data.

Wietse

Re: memcache client for Postfix

[Wietse Venema]

Wietse Venema:
>> This week I implemented a memcache client for Postfix in the hope
>> that it would be useful to share postscreen(8) or verify(8) caches
>> among multiple MTAs.  
...
> Considering that memcache patches are floating around with several
> problems, and the amount of time that I put into this, I have made
> the Postfix memcache client part of the 2.9 release. This version
> will at least reliably report problems with memcache servers.

Stan Hoeppner:
> Could a (heavily) modified proxymap/proxywrite daemon serve this multi
> host cache sharing duty?  Or would that require more work than writing
> something from scratch?

Short answer: I think we need both to share the postscreen database
among multiple MTAs with adequate performance.  The reason is that
proxymap and memcache solve very different problems.

Below is the long answer, based on an analysis of the different
problems that proxymap and memcache try to solve.

First a few bits of insight about memcache, then a quick look at
proxymap, and finally, how the two can be combined to get the best
of both worlds.

Quick look at memcache
--

Each memcache server is effectively a world-writable network ramdisk
(with obvious security implications).  If used by itself, a memcache
server would be suitable for storing low-value, easy-to-recreate,
data such as the postscreen or verify cache for a cluster of Postfix
MTAs.  All read/writes are from/to memory so they can be very fast.

The advantage of memcache is that it already exists. The protocol
is so simple that I ripped out libmemcache last night and wrote
my own memcache client in a few hours (and that was mostly
pasting little blocks of existing Postfix code together).

Quick look at proxymap
--

The Postfix proxymap server shares connections to (usually persistent)
databases.  In principle, this could be used to share a postscreen or
verify cache between different hosts, after adding some new code:

- proxymap client/server support to forward first/next method calls.
  These are needed for postscreen / verify cache cleanup support.
  Only one proxymap client should invoke these methods.

- proxymap server support for network access control (by default,
  only local client access should be allowed). As before, a proxymap
  reader or writer process will open only databases that are listed
  in main.cf:proxy_read_maps (or proxy_write_maps).

Limitations:

- Only one proxymap writer process per Postfix Berkeley DB database.
  The database can quickly become a performance bottleneck.

Combining memcache and proxymap
---

It seems that memcache is best for (surprise) doing what it was
designed for: a cache layer on top of a persistent database, where
the cache is maintained by the clients of the persistent database.

This means doing something like this:

/etc/postfix/main.cf:
postscreen_cache_map = memcache:/etc/postfix/postscreen-cache

/etc/postfix/postscreen-cache:
# Where is the memcache server?
hosts = host1:port1

# Where is the persistent database?
persistence = proxymap:inet:host2:port2:persistent-database

# Future: sharding (key hashing) to spread the load across
# multiple memory caches and persistent databases.

The idea is that the memcache delegates persistent database access
to the proxymap server.  Whenever the memcache client looks up or
modifies the persistent database, it updates the memcache server
to keep the cache up-to-date (clearly, cache consistency won't be
perfect, so information should be cached for only a limited time).

Adding persistence to the Postfix memcache client requires adding
1) interfaces for delete and first/next methods, 2) support to
access a persistent database and 3) support to update the memcache
server whenever the Postfix memcache client looks up or modifies
the persistent database.

I am aware of memcachedb, which combines memcached with Berkeley DB.
The advantage of the approach above is that it would combine memcache
with any persistent database, for example, mysql, once Postfix write
support is completed. That said, Postfix will never allow the use
of memcache for security-sensitive data.

Wietse

Re: virtual_alias_maps / mysql problem

[Lupin5th]

thank you for the hint!
i activated the query-log and the query is executed ok. i also checked it via 
postmap -q hutzenp...@domain.de mysql:/etc/postfix/mysql-virtual.cf
(which correctly did not return anything)
and
postmap -q correctu...@domain.de mysql:/etc/postfix/mysql-virtual.cf
which did return the correct entry, e.g. user169
so it seems mysql is not at fault.

also, when i tested it with a hash-file, it sent "successfully" to an address 
that was not listed in said file.

unfortunately, now i guess i´ll have to check any and all other config 
parameters that have anything to do with virtual delivery ^_^;

here goes the postconf -n:
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
inet_interfaces = 192.168.12.7 127.0.0.1
mailbox_size_limit = 0
message_size_limit = 2048
mydestination = localhost
mydomain = domain.de
myhostname = mail.domain.de
mynetworks = 192.168.12.0/24 127.0.0.0/8
myorigin = $mydomain
relayhost =
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, 
permit_sasl_authenticated, reject_non_fqdn_recipient, 
reject_unknown_recipient_domain, reject_unauth_destination, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = mail.domain.de
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/certs/cert.pem
smtpd_tls_cert_file = /etc/certs/cert.pem
smtpd_tls_key_file = /etc/certs/key.pem
smtpd_tls_received_header = no
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
virtual_mailbox_domains = domain.de
virtual_transport = dovecot

transport_maps reads thus:
domain.de   :
.domain.de  :
*  smtp:192.168.12.8  (this is the external "firewall"-postfix-server)

the mail.log reads thus:
Dec 11 17:05:05 mehl postfix/smtpd[16897]: connect from unknown[192.168.12.1]
Dec 11 17:05:05 mehl postfix/smtpd[16897]: DD60514A03F3: 
client=unknown[192.168.12.1], sasl_method=PLAIN, sasl_username=user169
Dec 11 17:05:05 mehl postfix/cleanup[16901]: DD60514A03F3: 
message-id=<4ee4d4b2.2020...@domain.de>
Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: from=, 
size=858, nrcpt=1 (queue active)
Dec 11 17:05:06 mehl postfix/smtpd[16897]: disconnect from unknown[192.168.12.1]
Dec 11 17:05:06 mehl postfix/pipe[16902]: DD60514A03F3: 
to=, relay=dovecot, delay=0.32, delays=0.18/0/0/0.14, 
dsn=2.0.0, status=sent (delivered via dovecot service)
Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: removed

the address grmblash does not really exist ;-), when i send to an existing 
address, the only "difference" is that postfix/pipe has the correct target as 
to, e.g. user...@dmain.de

thank you all for you hints, i hope this help shed some light on the problem. =)

best regards
sil

 Original-Nachricht 
> Datum: Sun, 11 Dec 2011 15:26:40 +0100
> Von: Reindl Harald 
> An: postfix-users@postfix.org
> Betreff: Re: virtual_alias_maps / mysql problem

> 
> 
> Am 11.12.2011 15:18, schrieb lupin...@gmx.net:
> > thank you for you reply.
> > virtual_mailbox_domains is set, as is virtual_transport.
> > do you mean using a hash-file to test it or for permanent use?
> > there are some 500 mail-users on the server, who change relatively often
> and who have each a number of aliases..i´d rather avoid using a hash
> file, especially because the mysql-query is supposed to work =)
> > 
> > is there some handy way of testing, what postfix receives from this
> mysql-check?
> 
> what about activate querylog in mysqld to look what really happens and
> c&p interesting queries into a mysql-shell to look at the results?
> 

-- 
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone


-- 
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: virtual_alias_maps / mysql problem

[Reindl Harald]

Am 11.12.2011 15:18, schrieb lupin...@gmx.net:
> thank you for you reply.
> virtual_mailbox_domains is set, as is virtual_transport.
> do you mean using a hash-file to test it or for permanent use?
> there are some 500 mail-users on the server, who change relatively often and 
> who have each a number of aliases..i´d rather avoid using a hash file, 
> especially because the mysql-query is supposed to work =)
> 
> is there some handy way of testing, what postfix receives from this 
> mysql-check?

what about activate querylog in mysqld to look what really happens and
c&p interesting queries into a mysql-shell to look at the results?



signature.asc
Description: OpenPGP digital signature

Re: virtual_alias_maps / mysql problem

[/dev/rob0]

On Sunday 11 December 2011 07:21:13 lupin...@gmx.net wrote:
> i´m not quite sure if the problem is directly the
> virtual_alias_maps or something it interacts with, so to say. in
> main.cf i set
> virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf

'postmap -q virtual@alias mysql:/etc/postfix/mysql-virtual.cf' lets 
you test how your lookups work.

http://www.postfix.org/DATABASE_README.html#preparing

> unverified_recipient_reject_code = 550
> unknown_local_recipient_reject_code = 550

Those do not appear to be relevant to this post nor issue.

> and in mysql-virtual.cf
> # the user name and password to log into the mysql server
> hosts = 127.0.0.1
> user = mailcheck
> password = secretpassword
> dbname = mails
> table = virtual
> select_field = dest
> where_field = alias

This is deprecated query syntax.

http://www.postfix.org/mysql_table.5.html
http://www.postfix.org/MYSQL_README.html

> now, if i try to send to an address on the server that does not
> exist, it should refuse, right? unfortunately it, postfix just
> hands it over to dovecot, as if everything was fine =(

If you had showed us the logs of this along with the 'postconf -n' 
output, we could have explained why this happened. As it is, we can 
only guess. My guess from the problem description is that you are 
using a flawed testing method, perhaps sending from a client in 
mynetworks, thus being accepted and bounced.

That's the way it is supposed to work for a client in mynetworks.

> I´m currently not completely sure, if the problem lies with the
> postfix-configuration or with the mysql-query (e.g. if it always
> returns "ok", even if the entry wasn´t found). But I´m currently

That would be wrong, see aforementioned DATABASE_README.

> not sure, how to test this. When i directly make the query in sql,
> it works fine (aka, it returns an empty result, if the mailaddress
> is not equal to one of the aliases).

This sounds right.

> i also tried to change the mysql-virtual.cf so that it uses a query
> (query = SELECT dest FROM virtual WHERE alias = "%s";), but the
> behavior did not change. mind you, when there´s an error in this
> file, i can´t send any mails, so it seems to be used in some way
> or other. -_-;

Possibly so! Impossible to guess, from here.

> any hints would be appreciated =)

http://www.postfix.org/DEBUG_README.html#mail

 * * *

On Sunday 11 December 2011 08:04:15 James Day wrote:
> First make sure that the domain you are sending to is set
> as a virtual mailbox domain.

This is possibly relevant, but misleading advice.

> It sounds like you've already set the
> virtual transport to dovecot which is right.

No, the "right" thing is usually to set up virtual(8) to deliver 
properly before venturing out into any third-party software.

> If you think mysql is the issue try making a
> virtual alias maps hash file.

This is good advice, essentially the same message as from the 
aforementioned DATABASE_README.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: virtual_alias_maps / mysql problem

[James Day]

Well a hash file would be the simplest thing to ensure that postfix is 
configured properly. I would have thought that all the information you need to 
see what is going on would be in the mail log and the mysql log.

***Sent via RoadSync® for Android™

-Original Message-
From: lupin...@gmx.net
Sent: Dec 11, 2011 2:19 PM
To: postfix-users@postfix.org
Subject: Re: RE: virtual_alias_maps / mysql problem




thank you for you reply.
virtual_mailbox_domains is set, as is virtual_transport.
do you mean using a hash-file to test it or for permanent use?
there are some 500 mail-users on the server, who change relatively often and 
who have each a number of aliases..i´d rather avoid using a hash file, 
especially because the mysql-query is supposed to work =)

is there some handy way of testing, what postfix receives from this mysql-check?

best regards
sil

 Original-Nachricht 
> Datum: Sun, 11 Dec 2011 14:04:15 +
> Von: James Day 
> An: "lupin...@gmx.net" , "postfix-users@postfix.org" 
> 
> Betreff: RE: virtual_alias_maps / mysql problem

> First make sure that the domain you are sending to is set as a virtual
> mailbox domain. It sounds like you've already set the virtual transport to
> dovecot which is right. If you think mysql is the issue try making a virtual
> alias maps hash file.
>
> ***Sent via RoadSync® for Android™
>
> -Original Message-
> From: lupin...@gmx.net
> Sent: Dec 11, 2011 1:21 PM
> To: postfix-users@postfix.org
> Subject: virtual_alias_maps / mysql problem
>
>
>
>
> Hello!
>
> i´m not quite sure if the problem is directly the virtual_alias_maps or
> something it interacts with, so to say.
> in main.cf i set
> virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
> unverified_recipient_reject_code = 550
> unknown_local_recipient_reject_code = 550
>
> and in mysql-virtual.cf
> # the user name and password to log into the mysql server
> hosts = 127.0.0.1
> user = mailcheck
> password = secretpassword
> dbname = mails
> table = virtual
> select_field = dest
> where_field = alias
>
> now, if i try to send to an address on the server that does not exist, it
> should refuse, right? unfortunately it, postfix just hands it over to
> dovecot, as if everything was fine =(
>
> I´m currently not completely sure, if the problem lies with the
> postfix-configuration or with the mysql-query (e.g. if it always returns 
> "ok", even
> if the entry wasn´t found).
> But I´m currently not sure, how to test this. When i directly make the
> query in sql, it works fine (aka, it returns an empty result, if the
> mailaddress is not equal to one of the aliases).
>
> i also tried to change the mysql-virtual.cf so that it uses a query (query
> = SELECT dest FROM virtual WHERE alias = "%s";), but the behavior did not
> change. mind you, when there´s an error in this file, i can´t send any
> mails, so it seems to be used in some way or other. -_-;
>
> any hints would be appreciated =)
>
> best regards
> sil
>
>
> --
> --
> "Do you know what happens to a toad struck by lightning..?
> The same thing that happens to anything else..."
> --
>
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

--
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: RE: virtual_alias_maps / mysql problem

[Lupin5th]

thank you for you reply.
virtual_mailbox_domains is set, as is virtual_transport.
do you mean using a hash-file to test it or for permanent use?
there are some 500 mail-users on the server, who change relatively often and 
who have each a number of aliases..i´d rather avoid using a hash file, 
especially because the mysql-query is supposed to work =)

is there some handy way of testing, what postfix receives from this mysql-check?

best regards
sil

 Original-Nachricht 
> Datum: Sun, 11 Dec 2011 14:04:15 +
> Von: James Day 
> An: "lupin...@gmx.net" , "postfix-users@postfix.org" 
> 
> Betreff: RE: virtual_alias_maps / mysql problem

> First make sure that the domain you are sending to is set as a virtual
> mailbox domain. It sounds like you've already set the virtual transport to
> dovecot which is right. If you think mysql is the issue try making a virtual
> alias maps hash file.
> 
> ***Sent via RoadSync® for Android™
> 
> -Original Message-
> From: lupin...@gmx.net
> Sent: Dec 11, 2011 1:21 PM
> To: postfix-users@postfix.org
> Subject: virtual_alias_maps / mysql problem
> 
> 
> 
> 
> Hello!
> 
> i´m not quite sure if the problem is directly the virtual_alias_maps or
> something it interacts with, so to say.
> in main.cf i set
> virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
> unverified_recipient_reject_code = 550
> unknown_local_recipient_reject_code = 550
> 
> and in mysql-virtual.cf
> # the user name and password to log into the mysql server
> hosts = 127.0.0.1
> user = mailcheck
> password = secretpassword
> dbname = mails
> table = virtual
> select_field = dest
> where_field = alias
> 
> now, if i try to send to an address on the server that does not exist, it
> should refuse, right? unfortunately it, postfix just hands it over to
> dovecot, as if everything was fine =(
> 
> I´m currently not completely sure, if the problem lies with the
> postfix-configuration or with the mysql-query (e.g. if it always returns 
> "ok", even
> if the entry wasn´t found).
> But I´m currently not sure, how to test this. When i directly make the
> query in sql, it works fine (aka, it returns an empty result, if the
> mailaddress is not equal to one of the aliases).
> 
> i also tried to change the mysql-virtual.cf so that it uses a query (query
> = SELECT dest FROM virtual WHERE alias = "%s";), but the behavior did not
> change. mind you, when there´s an error in this file, i can´t send any
> mails, so it seems to be used in some way or other. -_-;
> 
> any hints would be appreciated =)
> 
> best regards
> sil
> 
> 
> --
> --
> "Do you know what happens to a toad struck by lightning..?
> The same thing that happens to anything else..."
> --
> 
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

-- 
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

RE: virtual_alias_maps / mysql problem

[James Day]

First make sure that the domain you are sending to is set as a virtual mailbox 
domain. It sounds like you've already set the virtual transport to dovecot 
which is right. If you think mysql is the issue try making a virtual alias maps 
hash file.

***Sent via RoadSync® for Android™

-Original Message-
From: lupin...@gmx.net
Sent: Dec 11, 2011 1:21 PM
To: postfix-users@postfix.org
Subject: virtual_alias_maps / mysql problem




Hello!

i´m not quite sure if the problem is directly the virtual_alias_maps or 
something it interacts with, so to say.
in main.cf i set
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
unverified_recipient_reject_code = 550
unknown_local_recipient_reject_code = 550

and in mysql-virtual.cf
# the user name and password to log into the mysql server
hosts = 127.0.0.1
user = mailcheck
password = secretpassword
dbname = mails
table = virtual
select_field = dest
where_field = alias

now, if i try to send to an address on the server that does not exist, it 
should refuse, right? unfortunately it, postfix just hands it over to dovecot, 
as if everything was fine =(

I´m currently not completely sure, if the problem lies with the 
postfix-configuration or with the mysql-query (e.g. if it always returns "ok", 
even if the entry wasn´t found).
But I´m currently not sure, how to test this. When i directly make the query in 
sql, it works fine (aka, it returns an empty result, if the mailaddress is not 
equal to one of the aliases).

i also tried to change the mysql-virtual.cf so that it uses a query (query = 
SELECT dest FROM virtual WHERE alias = "%s";), but the behavior did not change. 
mind you, when there´s an error in this file, i can´t send any mails, so it 
seems to be used in some way or other. -_-;

any hints would be appreciated =)

best regards
sil


--
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

virtual_alias_maps / mysql problem

[Lupin5th]

Hello!

i´m not quite sure if the problem is directly the virtual_alias_maps or 
something it interacts with, so to say.
in main.cf i set
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
unverified_recipient_reject_code = 550
unknown_local_recipient_reject_code = 550

and in mysql-virtual.cf 
# the user name and password to log into the mysql server
hosts = 127.0.0.1
user = mailcheck
password = secretpassword
dbname = mails
table = virtual
select_field = dest
where_field = alias

now, if i try to send to an address on the server that does not exist, it 
should refuse, right? unfortunately it, postfix just hands it over to dovecot, 
as if everything was fine =(

I´m currently not completely sure, if the problem lies with the 
postfix-configuration or with the mysql-query (e.g. if it always returns "ok", 
even if the entry wasn´t found).
But I´m currently not sure, how to test this. When i directly make the query in 
sql, it works fine (aka, it returns an empty result, if the mailaddress is not 
equal to one of the aliases).

i also tried to change the mysql-virtual.cf so that it uses a query (query = 
SELECT dest FROM virtual WHERE alias = "%s";), but the behavior did not change. 
mind you, when there´s an error in this file, i can´t send any mails, so it 
seems to be used in some way or other. -_-;

any hints would be appreciated =)

best regards
sil


-- 
--
"Do you know what happens to a toad struck by lightning..?
The same thing that happens to anything else..."
--

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: memcache client for Postfix

[Stan Hoeppner]

On 12/9/2011 7:57 PM, Wietse Venema wrote:
> Wietse Venema:
>> This week I implemented a memcache client for Postfix in the hope
>> that it would be useful to share postscreen(8) or verify(8) caches
>> among multiple MTAs.  
>>
>> The implementation is based on libmemcache.  This was not too much
>> work, given a few examples (libmemcache is under-documented).
>>
>> However, robustness tests (with a single memcache server) proved
>> disappointing.
> 
> Considering that memcache patches are floating around with several
> problems, and the amount of time that I put into this, I have made
> the Postfix memcache client part of the 2.9 release. This version
> will at least reliably report problems with memcache servers.
> 
> The Postfix memcache client will compile only with libmemcache
> 1.4.0. The reason is that some API details were documented by looking
> at libmemcache source code. Such details will likely change when
> (if it ever happens) libmemcache is updated.
> 
>   Wietse

Could a (heavily) modified proxymap/proxywrite daemon serve this multi
host cache sharing duty?  Or would that require more work than writing
something from scratch?

-- 
Stan