Re: Mapping one domain to another (mysql)

[Tom Hendrikx]

On 8/7/12 8:58 PM, email builder wrote:
>>> Probably the best lesson to learn from postfixadmin is: you can
>>> have
> 
>>> more than one lookup table in postfix per main.cf directive. 
>>> Postfixadmin uses 2 separate queries for "regular" aliases and 
>>> domain aliases.
>>> 
>>> from main.cf: virtual_alias_maps =
>>> /etc/postfix/mysql_virtual_alias_maps.cf 
>>> /etc/postfix/virtual_alias_domain_maps.cf
>>> 
>>> where each file contains a simple db query. Makes it much easier
>>> to write the correct query, on the expense of some more db load.
>> 
>> Thanks Tom for making it more clear.
>> 
>> However, if you split to two queries, you still need a complex
>> query for the mapped domain. In my example, still like:
>> 
>> query = select if ('%d' = 'example-2.com', IFNULL((select dest from
>> aliases where addr = '%u...@example.com'), (select addr from users 
>> where addr = '%u...@example.com')), NULL)
>> 
>> I've found that in conjunction with a 2nd query (the original
>> normal one), everything seems to work as expected (including
>> aliases with only local parts like "postmaster")
>> 
>> But I'm still unsure if this kind of query is correct, if I'm on
>> the right track. Can anyone tell me if there's a better way to do
>> it?
>> 
>> Where are all those examples that are supposedly posted on this
>> list previously?
> 
> Bump - surely there's someone out there who has done this and can
> tell me if the kind of query above is either misguided or
> approximately what is needed to achieve this feature.
> 
> ie, Do I really have to query the alias table AND the account table?
> 
> 
> People have said on this list that other examples have been posted,
> but I can't find them.  Can someone please help?
> 

You have been pointed to postfixadmin before, which has all of this
builtin. Did you check their documentation? Every existing db-based
postfix adminsitration suite should have an example for you.

My query for alias domains on postgres, using postfixadmin database model:

query = SELECT goto FROM postfix_alias AS alias, postfix_alias_domain AS
alias_domain WHERE alias_domain.alias_domain = '%d' AND alias.address =
'%u' || '@' || alias_domain.target_domain AND alias.active = '1' AND
alias_domain.active = '1'

Definitely less hurting the head than your query this early in the
morning, imho.

--
Tom

Re: strange behaviours with sender_dependent_default_transport_maps

[zorg]

Le 07/08/2012 18:14, Viktor Dukhovni a écrit :

On Tue, Aug 07, 2012 at 05:51:43PM +0200, zorg wrote:


Reading the manual, it explain that
sender_dependent_default_transport_maps override default_transport

Which selects the delivery agent and nexthop for *external* recipients
based on the sender. This is NOT an access control mechanism.


first I want to white-list sender address allow to sender mail to
other domain

You're abusing the feature as an access control mechanism. Don't
do that.

http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/access.5.html

--
Viktor.

Thanks a lot
now I'm using
smtpd_sender_restrictions

Re: soft_bounce=yes in postmulti setup

[mailing list subscriber]

Hi,
I asked this earlier but maybe skipped your attention.

In summary,

Why do body/header checks generate 5xx rejects even with soft_bounce=yes?

Thanks.

On Mon, Jul 30, 2012 at 1:21 AM, mailing list subscriber
 wrote:
> Hi,
> I have two issues.
> After hard reading of MULTI_INSTANCE_README I've come to a setup as below.
> I've been so far satisfied with achieving splitting postfix-2.9.3
> (ubuntu 12.04 amd64) into incoming mail, submission and delivery to
> cyrus. Just before switching old box with new one, I have enabled
> soft_bounce = yes. The mail delivery was interrupted for a couple of
> hours, so incoming mail hit my isp backed-up mx during this time, to
> which I connected and manually issued an ETRN.
>
> It seems however that once deliveries started, logfiles show 5xx
> rejects instead of expected 4xx. Is this normal?

[...]

Re: Failover gateway server

[Nikolaos Milas]

On 8/8/2012 3:41 πμ, Stan Hoeppner wrote:


Yes, this is not a Postfix issue but a mail store issue.  Nikolaos, what
mail server are you using?  Cyrus, Dovecot, other?

As Viktor points out, building an HA mail server is not trivial.  But we
can probably point you to HA docs, and mailing lists, relevant to your
mail server if we know what it is.


It's Dovecot 2.0. Planning to move to 2.1 soon (currently in test env).

We are using Dovecot LDA delivery (from Postfix). All servers are KVM 
VMs (on a cloud where we don't have control on the host, but on highly 
reliable hardware/networks). User accounts are LDAP-based.


We can have VMs on different clouds and we also have multiple 
connections to the cloud(s) (to support HA).


Any directions will be appreciated. Hoping to design an HA architecture 
but aiming to keep it simple and (as much as possible) easily 
maintainable one.


Thanks for your response and help,
Nick

Re: Mapping one domain to another (mysql)

[email builder]

>>>  query = select if ('%d' = 'example-2.com', 

>>> IFNULL((select dest from
>>>  aliases where addr = '%u...@example.com'), (select addr from users 
>>>  where addr = '%u...@example.com')), NULL)
>>> 
>>>  I've found that in conjunction with a 2nd query (the original
>>>  normal one), everything seems to work as expected (including
>>>  aliases with only local parts like "postmaster")
>>> 
>>>  But I'm still unsure if this kind of query is correct, if I'm 
>>> on
>>>  the right track. Can anyone tell me if there's a better way to do
>>>  it?
>>> 
>>>  Where are all those examples that are supposedly posted on this
>>>  list previously?
>
> You have been pointed to postfixadmin before, which has all of this
> builtin. Did you check their documentation? Every existing db-based
> postfix adminsitration suite should have an example for you.

Sorry, I hoped not to have to learn a whole new tool when it was said there 
were already examples posted to this list. I'll try to take a look and see how 
easy it is to pick up parts like this

> My query for alias domains on postgres, using postfixadmin database model:
> 
> query = SELECT goto FROM postfix_alias AS alias, postfix_alias_domain AS
> alias_domain WHERE alias_domain.alias_domain = '%d' AND alias.address =
> '%u' || '@' || alias_domain.target_domain AND alias.active = 
> '1' AND
> alias_domain.active = '1'
> 
> Definitely less hurting the head than your query this early in the
> morning, imho.

Beauty is in the eye of the beholder I guess. I also gave pseudocode and after 
staring at your query, it does part of what mine does, but I have a question 
why it does not do the other part. 

What my tests have shown to work is:

0) if %d isn't the aliased domain "example-2.com" then forget it
1) Look in alias table to see if there is an alias for "user" in the 
target/primary domain "example.com", if there is, return it
2) If there was not an alias, we must look in the account table to find if 
there is a real account address for "user" in the target/primary domain 
"example.com", if there is, return it
3) otherwise, return NULL so postfix can reject the address

Your query only does steps 0 and 1. I found that if you skip step 2 mail will 
only be delivered for addresses that happen to have aliases in the 
target/primary domain.

Why does yours work? Do you ALSO have another query just like the one you show 
here that does the same thing in your account maps lookup query?  That might 
explain this.  And in that case, my query does both in one place - is there any 
reason why my approach would be dangerous?

Thanks a bunches for taking the time to help me

Re: Failover gateway server

[Nikolaos Milas]

On 8/8/2012 12:24 μμ, Nikolaos Milas wrote:


It's Dovecot 2.0.


Addendum: We use Maildir and the load is low (aside spam). Only about 
250 users/mailboxes (4G each). All servers are CentOS 5.8 (planning move 
to 6.3).


Currently we have only one internal mail server (Postfix/Dovecot), 
receiving mail from a gateway server (filtering spam/viruses) - a Cisco 
Ironport - which we are considering to replace with one (or a set of) 
cloud-based Postfix/SpamAssassin/ClamAV VMs (currently in testing mode).


Mail is very important to us (National Observatory Of Athens, a 
non-profit Research Foundation), that's why we are considering HA now - 
for the first time - although the lack of (human and many other) 
resources...


Regards,
Nick

Re: orig_to missing in logs

[Michal Lipka]

On Tue, 7 Aug 2012, Wietse Venema wrote:


Michal Lipka:

Hello,
today I noticed I don;t have orig_to in my log file even that the address
is rewrited.


Incorrect. Postfix logs orig_to only if the address is rewritten
before it is delivered.

For example Postfix does not log orig_to AFTER a content filter, when
virtual alias expansion happened BEFORE the content filter.




Actually I don't have any content filter here. This mail is addressed to 
michal.li...@abc.pl and after virtual_alias_maps (select goto from alias) 
is rewrited to mli...@abc.pl and then delievered via dovecot service.


Aug  8 13:55:16 mailserver postfix/smtpd[29457]: connect from 
unknown[10.0.15.24]
Aug  8 13:55:16 mailserver postfix/smtpd[29457]: DA81C6250A9: 
client=unknown[10.0.15.24]
Aug  8 13:55:16 mailserver postfix/cleanup[25642]: DA81C6250A9: 
message-id=
Aug  8 13:55:16 mailserver postfix/qmgr[14715]: DA81C6250A9: 
from=, size=1678, nrcpt=2 (queue active)
Aug  8 13:55:16 mailserver postfix/smtpd[29457]: disconnect from 
unknown[10.0.15.24]
Aug  8 13:55:17 mailserver postfix/pipe[20777]: DA81C6250A9: 
to=, relay=dovecot, delay=0.24, delays=0.1/0.01/0/0.14, 
dsn=2.0.0, status=sent (delivered via dovecot service)

Aug  8 13:55:17 mailserver postfix/qmgr[14715]: DA81C6250A9: removed

Is there any possibility that I will have in logs something like:
to=, orig_to=, relay=dovecot

Maybe it is somehow connected but variable $original_recipient is empty 
when I'm trying to use it in master.cf as a vacation script parameter.



Michal

Re: Mapping one domain to another (mysql)

[Tom Hendrikx]

On 8/8/12 11:27 AM, email builder wrote:
> 
 query = select if ('%d' = 'example-2.com',
> 
 IFNULL((select dest from aliases where addr =
 '%u...@example.com'), (select addr from users where addr =
 '%u...@example.com')), NULL)
 
 I've found that in conjunction with a 2nd query (the original 
 normal one), everything seems to work as expected (including 
 aliases with only local parts like "postmaster")
 
 But I'm still unsure if this kind of query is correct, if I'm 
 on the right track. Can anyone tell me if there's a better way
 to do it?
 
 Where are all those examples that are supposedly posted on
 this list previously?
>> 
>> You have been pointed to postfixadmin before, which has all of
>> this builtin. Did you check their documentation? Every existing
>> db-based postfix adminsitration suite should have an example for
>> you.
> 
> Sorry, I hoped not to have to learn a whole new tool when it was said
> there were already examples posted to this list. I'll try to take a
> look and see how easy it is to pick up parts like this
> 
>> My query for alias domains on postgres, using postfixadmin database
>> model:
>> 
>> query = SELECT goto FROM postfix_alias AS alias,
>> postfix_alias_domain AS alias_domain WHERE
>> alias_domain.alias_domain = '%d' AND alias.address = '%u' || '@' ||
>> alias_domain.target_domain AND alias.active = '1' AND 
>> alias_domain.active = '1'
>> 
>> Definitely less hurting the head than your query this early in the 
>> morning, imho.
> 
> Beauty is in the eye of the beholder I guess. 

This is not beauty, this is KISS. ;)

I also gave pseudocode
> and after staring at your query, it does part of what mine does, but
> I have a question why it does not do the other part.
> 
> What my tests have shown to work is:
> 
> 0) if %d isn't the aliased domain "example-2.com" then forget it 
> 1) Look in alias table to see if there is an alias for "user" in the
> target/primary domain "example.com", if there is, return it 
> 2) If there was not an alias, we must look in the account table to
> find if there is a real account address for "user" in the target/primary
> domain "example.com", if there is, return it 
> 3) otherwise, return NULL so postfix can reject the address

pfa has this covered by adding a record in the alias table for both
aliases (b...@example.com->a...@example.com) and mailboxes
(a...@example.com->a...@example.com). This means that a list of all mail
addresses (aliases and mailboxes) are available in alias.address, and
that a single query on that table is enough to check all variants.

If you don't like that design (I don't, but I have other things to worry
about), write a difficult query or again, split the work over separate
lookups: one for aliases in alias domains, and one for accounts in alias
domains.

--
Tom

mailtail

[Sascha Hüdepohl]

Hi!

A very little tool to watch mail.log in color:
http://sascha.huedepohl.de/mailtail

Sascha

Re: soft_bounce=yes in postmulti setup

[Noel Jones]

On 8/8/2012 4:22 AM, mailing list subscriber wrote:
> Hi,
> I asked this earlier but maybe skipped your attention.
> 
> In summary,
> 
> Why do body/header checks generate 5xx rejects even with soft_bounce=yes?


soft_bounce works as documented. The log may show a 5.x.x extended
status code, but the client receives a 4xx response and a 4.x.x status.




  -- Noel Jones

Re: mailtail

[Alvin Wong]

With just a single binary I have 80% thought of it being a Trojan.

2012/8/8 Sascha Hüdepohl 

> Hi!
>
> A very little tool to watch mail.log in color:
> http://sascha.huedepohl.de/mailtail
>
> Sascha
>

Re: postfix thinks mysql managed email address is remote

[Scott Brown]

Rob,
thank you very much for the pointers on reposting.

I turned off the -v setting on smtpd

The old virtual domain is resumearrow.com.  The new, mysql-managed domain, is 
parallelemail.com

If I run a postmap -q on my email address under both domains, the results are 
the same:
[root@miltermatic log]# postmap -q sbr...@resumearrow.com 
mysql:/etc/postfix/mysql-virtual.cf
scottwb...@yahoo.com
[root@miltermatic log]# postmap -q sbr...@parallelemail.com 
mysql:/etc/postfix/mysql-virtual.cf
scottwb...@yahoo.com

Because postfix rejects the session at the RCPT command, I don't believe any 
further details of the session are available for the parallelemail domain:
[root@miltermatic log]# grep "sbr...@parallelemail.com" maillog
Aug  8 10:33:21 miltermatic postfix/smtpd[10117]: NOQUEUE: reject: RCPT from 
mail-qc0-f170.google.com[209.85.216.170]: 554 5.7.1 : 
Relay access denied; from= to= 
proto=ESMTP helo=

Postfix did assign a message identifier to the email to resumearrow.com, so I 
can provide more, non-verbose, session details on that:
[root@miltermatic log]# grep "sbr...@resumearrow.com" maillog
Aug  8 10:33:07 miltermatic postfix/smtp[10081]: 971C814A805F: 
to=, orig_to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.58/0/0/4.8, dsn=2.0.0, 
status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
as 6919414A8066)
[root@miltermatic log]# grep "971C814A805F" maillog
Aug  8 10:33:02 miltermatic postfix/smtpd[10119]: 971C814A805F: 
client=mail-qa0-f49.google.com[209.85.216.49]
Aug  8 10:33:02 miltermatic postfix/cleanup[10060]: 971C814A805F: 
message-id=
Aug  8 10:33:02 miltermatic postfix/qmgr[10053]: 971C814A805F: 
from=, size=5732, nrcpt=1 (queue active)
Aug  8 10:33:07 miltermatic postfix/smtp[10081]: 971C814A805F: 
to=, orig_to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.58/0/0/4.8, dsn=2.0.0, 
status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
as 6919414A8066)
Aug  8 10:33:07 miltermatic postfix/qmgr[10053]: 971C814A805F: removed

Here's the postconf -n output:
[root@miltermatic log]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
body_checks = regexp:$config_directory/usermanaged/body_checks
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisd-new:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 3
default_process_limit = 30
header_checks = regexp:$config_directory/usermanaged/header_checks
html_directory = /usr/share/doc/postfix-2.5.1-documentation/html
inet_interfaces = $myhostname, localhost
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydomain = miltermatic.hiresites.com
myhostname = miltermatic.hiresites.com
mynetworks = 67.22.105.2 67.22.105.3 127.0.0.1 67.22.101.154 10.10.17.56
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.5.1-documentation/readme
relayhost = 67.22.105.2
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_connection_cache_destinations = 
smtp_connection_cache_on_demand = no
smtpd_banner = $myhostname ESMTP MilterMatician (0.1)
                                reject_unknown_recipient_domain
smtpd_sereject_rbl_client relays.mail-abuse.org.org, 
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf

Thanks again - I look forward to your ideas on how to troubleshoot further

Scott


- Original Message -
From: /dev/rob0 
To: postfix-users@postfix.org
Cc: 
Sent: Tuesday, August 7, 2012 6:50 PM
Subject: Re: postfix thinks mysql managed email address is remote

On Tue, Aug 07, 2012 at 03:28:45PM -0700, Scott Brown wrote:
> I recently switched from using flat virtual files to using mysql
> to manage a virtual table.

http://www.postfix.org/DATABASE_README.html#preparing is worth a 
read.

> Email addresses that were set up prior to the switchover can be 
> reached.  But emails set up afterwards can't.

postmap -q new@address mysql:/path/to/your/query

> I added verbose logging to the smtp processes by adding the -v 
> parameter in master.cf

It looks like you added it to smtpd, not smtp. Probably was not 
necessary.

> With old email addresses set up prior to mysql, the resolve_clnt 
> function seems to recognize that the domain is local, even though 
> it doesn't initially see the email address in the virtual alias 
> table (not sure why)

Your post should have included "postconf -n" also. This would have 
been more useful than verbose logs.

> With the new email addresses that are managed by mysql, 
> resolve_clnt doesn't seem to be looking up the email in the virtual 
> table.  Instead, it comes back with the host IP address -- this is 
> the relayhost value set in main.cf.
> 
> Here are the maillog entries for the email set up prior to the 
> mysql switch:
> [root@milte

Re: mysql query suppressed?

[Wietse Venema]

email builder:
> 2) it's not intuitive to me that the query I have given to postifx
> is conditionally executed. 

And THAT is precisely what the documentation says.

Wietse

Re: orig_to missing in logs

[Viktor Dukhovni]

On Wed, Aug 08, 2012 at 02:03:56PM +0200, Michal Lipka wrote:

> On Tue, 7 Aug 2012, Wietse Venema wrote:
> 
> >Incorrect. Postfix logs orig_to only if the address is rewritten
> >before it is delivered.
> >
> >For example Postfix does not log orig_to AFTER a content filter, when
> >virtual alias expansion happened BEFORE the content filter.
> 
> Actually I don't have any content filter here. This mail is
> addressed to michal.li...@abc.pl and after virtual_alias_maps
> (select goto from alias) is rewrited to mli...@abc.pl and then
> delievered via dovecot service.

Then the message is rewritten upstream, perhaps on 10.0.15.24

> Aug  8 13:55:16 mailserver postfix/smtpd[29457]: connect from
> unknown[10.0.15.24]
> Aug  8 13:55:16 mailserver postfix/smtpd[29457]: DA81C6250A9:
> client=unknown[10.0.15.24]
> Aug  8 13:55:16 mailserver postfix/cleanup[25642]: DA81C6250A9:
> message-id=
> Aug  8 13:55:16 mailserver postfix/qmgr[14715]: DA81C6250A9:
> from=, size=1678, nrcpt=2 (queue active)

This message had two recipients.

> Aug  8 13:55:16 mailserver postfix/smtpd[29457]: disconnect from
> unknown[10.0.15.24]
> Aug  8 13:55:17 mailserver postfix/pipe[20777]: DA81C6250A9:
> to=, relay=dovecot, delay=0.24,
> delays=0.1/0.01/0/0.14, dsn=2.0.0, status=sent (delivered via
> dovecot service)
> Aug  8 13:55:17 mailserver postfix/qmgr[14715]: DA81C6250A9: removed

You show only one delivery. The logs are incomplete, but perhaps
this is fine if the other recipient is unrelated to the issue at
hand.

-- 
Viktor.

Re: Best way to protect backup-mx?

[tobi]

Thanks for this very plausible reason for not doing what I wanted :-) I
did not think about such circumstances.

Cheers

tobi

Am 07.08.2012 22:25, schrieb Reindl Harald:
> 
> be carfeul with such things
> 
> that you primary MX is up from the connection of your
> backup-MX means virtually nothing because this does
> not mean it is also from the route the delivering MTA
> takes
> 
> i have a practical example where i would 100% say it is
> impossible if someone tells me the same:
> 
> * Class C IP-Range
> * two IP-Addresses on the same server
> * one customer with a website on both ip-addresses
> * customer has one www-domain and another domain with ip-based SSL host
> 
> our ISP had terrible routing problems from and to all sort of
> networks over some hours caused by a dying core-router
> 
> my customer was sitting in his office on the same machine and
> was able to connect to 91.118.73.6 without any problem while
> he could not connect to 91.118.73.7 from the same machine while
> other customers could even not connect to 91.118.73.6
> 
> so we had
> 
> * the same client
> * the same network hardware on the client side
> * the same ISP on the client side
> * the same ISp on oour side
> * the same route
> * the same network hardware on our side
> * even the same physical server on our side
> * after ISP has solved his troubles all went to normal operations
> 
> so nobody can explain me how this was possible
> but this shows me that make the decision "my primary MX is up"
> is finally danherous and says virtually nothing if he is
> up for any incoming connect from somewhere else and if the
> primary MX is down from the delivering MTA he is absolutely
> right to try the backup-MX!
> 
> 

Re: Best way to protect backup-mx?

[tobi]

Am 07.08.2012 22:40, schrieb Ansgar Wiechers:
> 
> Why do you consider this a problem? Your backup MX should neither accept
> nor allow anything the primary MX wouldn't.
> 
Actually I do not consider this a real "problem" My setups on my
backup-mx are as identical as possible to my main-mx. It's just annoying
if spammers try my backups first but not a real problem ;-)
Anyway because of the example that Harald sent I throw my idea over board
Thanks and cheers

tobi

Re: orig_to missing in logs

[michal]

On Wed, 8 Aug 2012, Viktor Dukhovni wrote:


On Wed, Aug 08, 2012 at 02:03:56PM +0200, Michal Lipka wrote:


On Tue, 7 Aug 2012, Wietse Venema wrote:


Incorrect. Postfix logs orig_to only if the address is rewritten
before it is delivered.

For example Postfix does not log orig_to AFTER a content filter, when
virtual alias expansion happened BEFORE the content filter.


Actually I don't have any content filter here. This mail is
addressed to michal.li...@abc.pl and after virtual_alias_maps
(select goto from alias) is rewrited to mli...@abc.pl and then
delievered via dovecot service.


Then the message is rewritten upstream, perhaps on 10.0.15.24



10.0.15.24 is my mail frontend (receives mails from internet and then 
relays them to appropriate server inside). it does only virus scanning 
(with spamassassin). Is it important what's going on with message on other 
server?



Aug  8 13:55:16 mailserver postfix/smtpd[29457]: connect from
unknown[10.0.15.24]
Aug  8 13:55:16 mailserver postfix/smtpd[29457]: DA81C6250A9:
client=unknown[10.0.15.24]
Aug  8 13:55:16 mailserver postfix/cleanup[25642]: DA81C6250A9:
message-id=
Aug  8 13:55:16 mailserver postfix/qmgr[14715]: DA81C6250A9:
from=, size=1678, nrcpt=2 (queue active)


This message had two recipients.



there was only one envelope recipient (michal.li...@abc.pl), the other one 
was added with always_bcc in main.cf - I think it is unrelated but I can 
be wrong of course - correct me please if I am.



Aug  8 13:55:16 mailserver postfix/smtpd[29457]: disconnect from
unknown[10.0.15.24]
Aug  8 13:55:17 mailserver postfix/pipe[20777]: DA81C6250A9:
to=, relay=dovecot, delay=0.24,
delays=0.1/0.01/0/0.14, dsn=2.0.0, status=sent (delivered via
dovecot service)
Aug  8 13:55:17 mailserver postfix/qmgr[14715]: DA81C6250A9: removed


You show only one delivery. The logs are incomplete, but perhaps
this is fine if the other recipient is unrelated to the issue at
hand.




sorry for the incomplete log. As I mentioned before I think it is 
unrelated but to clarify:
Aug  8 13:55:17 zeus-postfix postfix/pipe[23748]: DA81C6250A9: 
to=, relay=logi, delay=0.14, 
delays=0.1/0.01/0/0.03, dsn=2.0.0, status=sent (delivered via logi 
service)


"logi" in master.cf is my own script which is handling copies of all 
mails.

always_bcc = logowa...@logowanie.abc


Michal

Re: Failover gateway server

[Stan Hoeppner]

On 8/8/2012 4:24 AM, Nikolaos Milas wrote:
> On 8/8/2012 3:41 πμ, Stan Hoeppner wrote:
> 
>> Yes, this is not a Postfix issue but a mail store issue.  Nikolaos, what
>> mail server are you using?  Cyrus, Dovecot, other?
>>
>> As Viktor points out, building an HA mail server is not trivial.  But we
>> can probably point you to HA docs, and mailing lists, relevant to your
>> mail server if we know what it is.
> 
> It's Dovecot 2.0. Planning to move to 2.1 soon (currently in test env).
> 
> We are using Dovecot LDA delivery (from Postfix). All servers are KVM
> VMs (on a cloud where we don't have control on the host, but on highly
> reliable hardware/networks). User accounts are LDAP-based.
> 
> We can have VMs on different clouds and we also have multiple
> connections to the cloud(s) (to support HA).
> 
> Any directions will be appreciated. Hoping to design an HA architecture
> but aiming to keep it simple and (as much as possible) easily
> maintainable one.
> 
> Thanks for your response and help,

You need to take this to the Dovecot list:

http://dovecot.org/cgi-bin/mailman/listinfo/dovecot

-- 
Stan

Re: mailtail

[Ben Rosengart]

On Wed, Aug 08, 2012 at 09:48:40PM +0800, Alvin Wong wrote:
> With just a single binary I have 80% thought of it being a Trojan.

23 lines of non-obfuscated bash.

-- 
  Ben Rosengart   "Like all those possessing a library,
  Sendmail, Inc.   Aurelian was aware that he was guilty of
  +1 718 431 3822  not knowing his in its entirety [...]"
  -- Jorge Luis Borges

NOTICE: If received in error, please destroy and notify sender.
Sender does not waive confidentiality or privilege, and use is prohibited.

Re: orig_to missing in logs

[Viktor Dukhovni]

On Wed, Aug 08, 2012 at 07:53:34PM +0200, mic...@lipka.waw.pl wrote:

> On Wed, 8 Aug 2012, Viktor Dukhovni wrote:
> 
> >On Wed, Aug 08, 2012 at 02:03:56PM +0200, Michal Lipka wrote:
> >
> >>On Tue, 7 Aug 2012, Wietse Venema wrote:
> >>
> >>>Incorrect. Postfix logs orig_to only if the address is rewritten
> >>>before it is delivered.
> >>>
> >>>For example Postfix does not log orig_to AFTER a content filter, when
> >>>virtual alias expansion happened BEFORE the content filter.
> >>
> >>Actually I don't have any content filter here. This mail is
> >>addressed to michal.li...@abc.pl and after virtual_alias_maps
> >>(select goto from alias) is rewrited to mli...@abc.pl and then
> >>delievered via dovecot service.
> >
> >Then the message is rewritten upstream, perhaps on 10.0.15.24
> 
> 10.0.15.24 is my mail frontend (receives mails from internet and
> then relays them to appropriate server inside). it does only virus
> scanning (with spamassassin). Is it important what's going on with
> message on other server?

Naturally, since it is highly likely the rewrite took place there,
the Postfix server that does the rewrite records any change in the
envelope address. Downstream servers that don't rewrite don't record
the change they did not make.

--
Viktor.

Re: orig_to missing in logs

[michal]

On Wed, 8 Aug 2012, Viktor Dukhovni wrote:


On Wed, Aug 08, 2012 at 07:53:34PM +0200, mic...@lipka.waw.pl wrote:


On Wed, 8 Aug 2012, Viktor Dukhovni wrote:


On Wed, Aug 08, 2012 at 02:03:56PM +0200, Michal Lipka wrote:


On Tue, 7 Aug 2012, Wietse Venema wrote:


Incorrect. Postfix logs orig_to only if the address is rewritten
before it is delivered.

For example Postfix does not log orig_to AFTER a content filter, when
virtual alias expansion happened BEFORE the content filter.


Actually I don't have any content filter here. This mail is
addressed to michal.li...@abc.pl and after virtual_alias_maps
(select goto from alias) is rewrited to mli...@abc.pl and then
delievered via dovecot service.


Then the message is rewritten upstream, perhaps on 10.0.15.24


10.0.15.24 is my mail frontend (receives mails from internet and
then relays them to appropriate server inside). it does only virus
scanning (with spamassassin). Is it important what's going on with
message on other server?


Naturally, since it is highly likely the rewrite took place there,
the Postfix server that does the rewrite records any change in the
envelope address. Downstream servers that don't rewrite don't record
the change they did not make.




It is impossible for upstream server to do this rewrite because it doesn't 
know anything about aliases.
In my first mail I included report from cleanup -v from downstream server 
which clearly (for me) shows it does the rewrite.

What am I missing?

Michal

Re: Best way to protect backup-mx?

[Sebastian Wiesinger]

* tobi  [2012-08-07 18:46]:
> Hi list,

Sorry list, hi Tobi:


I wanted to tell you that your DNSSEC for brain-force.ch is broken so
resolvers which validate DNSSEC will not be able to resolve your
domain (and so I can't send you mails directly). You might want to fix
this.

http://dnsviz.net/d/brain-force.ch/dnssec/

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant

Re: orig_to missing in logs

[Wietse Venema]

mic...@lipka.waw.pl:
> >> 10.0.15.24 is my mail frontend (receives mails from internet and
> >> then relays them to appropriate server inside). it does only virus
> >> scanning (with spamassassin). Is it important what's going on with
> >> message on other server?
> >
> > Naturally, since it is highly likely the rewrite took place there,
> > the Postfix server that does the rewrite records any change in the
> > envelope address. Downstream servers that don't rewrite don't record
> > the change they did not make.
> 
> It is impossible for upstream server to do this rewrite because it doesn't 
> know anything about aliases.
> In my first mail I included report from cleanup -v from downstream server 
> which clearly (for me) shows it does the rewrite.
> What am I missing?

It is really simple. Postfix compares the unrewritten address to
the current form, and if the two differ, it logs orig_to=.

HOWEVER, the cleanup server does not save the unrewritten address
unless "enable_original_recipient = yes" (which is the default).

Also, the two addresses will be identical if the rewriting happened
up-stream, before Postfix received the address.

Wietse

Re: Mapping one domain to another (mysql)

[email builder]

>  I've found that in conjunction with a 2nd query (the 

> original 
>  normal one), everything seems to work as expected (including 
>  aliases with only local parts like "postmaster")
> 
>  But I'm still unsure if this kind of query is correct, if 
> I'm 
>  on the right track. Can anyone tell me if there's a better 
> way
>  to do it?
> 
>  Where are all those examples that are supposedly posted on
>  this list previously?
>>> 
>>>  You have been pointed to postfixadmin before, which has all of
>>>  this builtin. Did you check their documentation? Every existing
>>>  db-based postfix adminsitration suite should have an example for
>>>  you.
>> 
>>  Sorry, I hoped not to have to learn a whole new tool when it was said
>>  there were already examples posted to this list. I'll try to take a
>>  look and see how easy it is to pick up parts like this
>> 
>>>  My query for alias domains on postgres, using postfixadmin database
>>>  model:
>>> 
>>>  query = SELECT goto FROM postfix_alias AS alias,
>>>  postfix_alias_domain AS alias_domain WHERE
>>>  alias_domain.alias_domain = '%d' AND alias.address = 
>>> '%u' || '@' ||
>>>  alias_domain.target_domain AND alias.active = '1' AND 
>>>  alias_domain.active = '1'
>>> 
>>>  Definitely less hurting the head than your query this early in the 
>>>  morning, imho.
>> 
>>  Beauty is in the eye of the beholder I guess. 
> 
> This is not beauty, this is KISS. ;)

I don't think mine is so confusing as you suggest if you take a second to 
understand it.  Maybe if you read it with some whitespace:

select 
    if ('%d' = 'example-2.com',
    IFNULL(
    (select dest from aliases where addr = '%u...@example.com'),
    (select addr from users where addr = '%u...@example.com')
    ),
    NULL)

Or, adding some pseudocode back to it

select 
    if ('%d' = 'example-2.com', THEN {
    IF THE FOLLOWING ISN'T NULL THEN USE IT {
    (select dest from aliases where addr = '%u...@example.com'),
    } ELSE {
    (select addr from users where addr = '%u...@example.com')
    }
    } ELSE NULL)

Where you can substitute your "target_domain" for "example.com" and 
"alias_domain" for "example-2.com"

But again, to each his own, and I'm glad to see your query to confirm if I'm 
not doing something terribly wrong.

>> I also gave pseudocode
>>  and after staring at your query, it does part of what mine does, but
>>  I have a question why it does not do the other part.
>> 
>>  What my tests have shown to work is:
>> 
>>  0) if %d isn't the aliased domain "example-2.com" then forget 
> it 
>>  1) Look in alias table to see if there is an alias for "user" in 
> the
>>  target/primary domain "example.com", if there is, return it 
>>  2) If there was not an alias, we must look in the account table to
>>  find if there is a real account address for "user" in the 
> target/primary
>>  domain "example.com", if there is, return it 
>>  3) otherwise, return NULL so postfix can reject the address
> 
> pfa has this covered by adding a record in the alias table for both
> aliases (b...@example.com->a...@example.com) and mailboxes
> (a...@example.com->a...@example.com). This means that a list of all mail
> addresses (aliases and mailboxes) are available in alias.address, and
> that a single query on that table is enough to check all variants.

Eiw.  Not very normalized.  :)  But OK, that explains things.

> If you don't like that design (I don't, but I have other things to worry
> about), write a difficult query or again, split the work over separate
> lookups: one for aliases in alias domains, and one for accounts in alias
> domains.

My query takes care of the situation by checking for aliases first and falling 
back to checking the accounts if no alias was found.  

I think if you wanted to make your query work if you didn't have the accounts 
listed in the alias table, you can simply stuff the whole query inside the 
first argument of the IFNULL function (not sure what the pgsql equivalent of 
IFNULL is).  Then the second argument to IFNULL would be a copy of the same 
query aimed at the account table instead of the alias table.

I think if you wanted to maintain two separate queries and make it work similar 
to my query, this might work (untested):

alias lookup:

select 
    if ('%d' = 'example-2.com',
    IFNULL(
    (select dest from aliases where addr = '%u...@example.com'),
    (NULL)
    ),
    NULL)

account lookup:

select 
    if ('%d' = 'example-2.com',
    IFNULL(
    (select addr from users where addr = '%u...@example.com'),
    (NULL)
    ),
    NULL)

again, these need to be *additional* queries to the normal ones configured for 
the alias maps and account maps.

I'm glad someone could respond on this thread, so thank you, Tom

Re: mysql query suppressed?

[email builder]

>>  2) it's not intuitive to me that the query I have given to postifx

>>  is conditionally executed. 
> 
> And THAT is precisely what the documentation says.


And THAT is merely what I was asking to have confirmation of (not sure why that 
is so difficult)... because it's not intuitive, and also because this fact is 
IMO buried too deep in the documentation.  If you can set up queries but they 
might get ignored based on a naive scan of the query text, I think it might be 
good to make a more prominent note of this.  But thanks anyway

postfix/clamsmpt/clam msgs from quarantine?

[Len Conrad]

a bad MBL sig quarantined a few 1000 legit msgs.

Thanks
Len

postfix/clamsmpt/clam msgs from quarantine?

[Len Conrad]

a bad MBL sig quarantined a few 1000 legit msgs.

Thanks
Len

Re: Mapping one domain to another (mysql)

[Brian Evans - Postfix List]

On 8/8/2012 3:03 PM, email builder wrote:
>
> I don't think mine is so confusing as you suggest if you take a second to 
> understand it.  Maybe if you read it with some whitespace:
>
> select 
> if ('%d' = 'example-2.com',
> IFNULL(
> (select dest from aliases where addr = '%u...@example.com'),
> (select addr from users where addr = '%u...@example.com')
> ),
> NULL)
>

You almost never want to return a NULL result to Postfix using a SQL lookup.
This actually can mean an affirmative instead of a negative result.

A better query might be:
(SELECT dest from aliases where addr = '%u...@example.com' AND '%d' =
'example.net') UNION
(SELECT addr from users where addr = '%u...@example.com' AND '%d' =
'example.net') LIMIT 1

Postfix expects an empty set (i.e. no rows returned) if it is to respond
negatively that a virtual alias does not exist.
Returning NULL does not equal no rows returned.

Brian

N.B. Test all suggested queries before putting into production,
including mine.

Re: mysql query suppressed?

[Viktor Dukhovni]

On Wed, Aug 08, 2012 at 12:07:09PM -0700, email builder wrote:

> >>  2) it's not intuitive to me that the query I have given to postifx
> >>  is conditionally executed. 
> > 
> > And THAT is precisely what the documentation says.
> 
> And THAT is merely what I was asking to have confirmation of
> (not sure why that is so difficult)...

It is difficult only because you prefer to believe fanciful
interpretations a plainly stated behaviour. The query is
suppressed, it never happens, .

The documentation is concise, but not (at least in this case)
ambiguous.

> because it's not intuitive,

It is intuititive if you understand that Postfix makes multiple
lookups for a single key, some of which contain only the user or
the domain part. The low-level table driver (LDAP, MySQL, ...)
does not know which part of the address it is handed, or even
whether the lookup key is an address at all.

Thus, when a lookup key does not resembe an full email address, it
is not possible to determine whether the key has a domain part or
not. Instead of making meaningless queries that may produce incorrect
results, Postfix suppresses the query.

> and also because this fact is IMO buried too deep in the documentation.

It is documented in the paragraph that describes the "%d" syntax.
Don't use "%d" in queries without reading what it does. There is
surely no better place to describe "%d" semantics than in the
associated paragraph of the query syntax definitions.

-- 
Viktor.

Re: Mapping one domain to another (mysql)

[email builder]

>>  I don't think mine is so confusing as you suggest if you take a second 

> to understand it.  Maybe if you read it with some whitespace:
>> 
>>  select 
>>      if ('%d' = 'example-2.com',
>>          IFNULL(
>>              (select dest from aliases where addr = 
> '%u...@example.com'),
>>              (select addr from users where addr = '%u...@example.com')
>>          ),
>>      NULL)
>> 
> 
> You almost never want to return a NULL result to Postfix using a SQL lookup.
> This actually can mean an affirmative instead of a negative result.

Thank you for the tip.

> A better query might be:
> (SELECT dest from aliases where addr = '%u...@example.com' AND '%d' 
> =
> 'example.net') UNION
> (SELECT addr from users where addr = '%u...@example.com' AND '%d' =
> 'example.net') LIMIT 1

Funny, I think I posted almost the same query earlier on.  :)

And I like this version better because it seems more standardized SQL

> Postfix expects an empty set (i.e. no rows returned) if it is to respond
> negatively that a virtual alias does not exist.
> Returning NULL does not equal no rows returned.

Are you sure?  I ask only because the query I posted above DOES work - it does 
reject invalid addresses normally (for the primary or secondary domain or other 
unrelated domains on the server).  Maybe postfix even unintentionally gets a 
NULL back, tries to do something with it but fails and ultimately produces the 
same result?

Re: Mapping one domain to another (mysql)

[Wietse Venema]

email builder:
> Postfix expects an empty set (i.e. no rows returned) if it is to respond
> negatively that a virtual alias does not exist.
> Returning NULL does not equal no rows returned.

email builder:
>Are you sure?? 

100% confirmed. To return NOTFOUND, you MUST return NO RESULT.

Wietse

Re: Mapping one domain to another (mysql)

[Viktor Dukhovni]

On Wed, Aug 08, 2012 at 04:08:03PM -0400, Wietse Venema wrote:

> email builder:
> > Postfix expects an empty set (i.e. no rows returned) if it is to respond
> > negatively that a virtual alias does not exist.
> > Returning NULL does not equal no rows returned.
> 
> email builder:
> >Are you sure?? 
> 
> 100% confirmed. To return NOTFOUND, you MUST return NO RESULT.

The common code that underlies the MySQL, PgSQL and LDAP table
drivers ignores empty result values with a warning. While NULL
result values are silently ignored you should not depend on this
undocumented behaviour.

We should update the documentation for empty results, right now
the documentation of "%s" in the result format only says that empty
results are skipped, without mentioning the warning and that queries
should not be constructed to yield empty result columns.

The situation with "%u" and "%d" in the result format is a bit more
subtle, since these are potentially empty parts of a non-empty
address, so no warnings are issued when "%u" or "%d" are empty,
but the result value is still skipped.

-- 
Viktor.

Re: postfix thinks mysql managed email address is remote

[/dev/rob0]

On Wed, Aug 08, 2012 at 07:40:22AM -0700, Scott Brown wrote:
> The old virtual domain is resumearrow.com.  The new, mysql-managed 
> domain, is parallelemail.com
> 
> If I run a postmap -q on my email address under both domains, the 
> results are the same:
> [root@miltermatic log]# postmap -q sbr...@resumearrow.com 
> mysql:/etc/postfix/mysql-virtual.cf
> scottwb...@yahoo.com
> [root@miltermatic log]# postmap -q sbr...@parallelemail.com 
> mysql:/etc/postfix/mysql-virtual.cf
> scottwb...@yahoo.com

This is virtual_alias_maps. You don't show a setting below for 
virtual_alias_domains, and the default is "$virtual_alias_maps". So 
try this:

postmap -q resumearrow.com mysql:/etc/postfix/mysql-virtual.cf
postmap -q parallelemail.com mysql:/etc/postfix/mysql-virtual.cf

As I said, the domain lookup is failing. Therefore it is considered 
an unauthorized destination, and reject_unauth_destination blocks 
your mail.

http://www.postfix.org/ADDRESS_CLASS_README.html#virtual_alias_class
http://www.postfix.org/VIRTUAL_README.html#virtual_alias

BTW, same-envelope forwarding of mail to domains you do not control 
(yahoo.com) is likely to be troublesome. When you get and forward 
spam, they might flag you as a spam source.

> Because postfix rejects the session at the RCPT command, I don't 
> believe any further details of the session are available for the 
> parallelemail domain:
> [root@miltermatic log]# grep "sbr...@parallelemail.com" maillog
> Aug  8 10:33:21 miltermatic postfix/smtpd[10117]: NOQUEUE: reject: RCPT from 
> mail-qc0-f170.google.com[209.85.216.170]: 554 5.7.1 
> : Relay access denied; from= 
> to= proto=ESMTP helo=
> 
> Postfix did assign a message identifier to the email to 
> resumearrow.com, so I can provide more, non-verbose, session 
> details on that:
> [root@miltermatic log]# grep "sbr...@resumearrow.com" maillog
> Aug  8 10:33:07 miltermatic postfix/smtp[10081]: 971C814A805F: 
> to=, orig_to=, 
> relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.58/0/0/4.8, dsn=2.0.0, 
> status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
> as 6919414A8066)
> [root@miltermatic log]# grep "971C814A805F" maillog
> Aug  8 10:33:02 miltermatic postfix/smtpd[10119]: 971C814A805F: 
> client=mail-qa0-f49.google.com[209.85.216.49]
> Aug  8 10:33:02 miltermatic postfix/cleanup[10060]: 971C814A805F: 
> message-id=
> Aug  8 10:33:02 miltermatic postfix/qmgr[10053]: 971C814A805F: 
> from=, size=5732, nrcpt=1 (queue active)
> Aug  8 10:33:07 miltermatic postfix/smtp[10081]: 971C814A805F: 
> to=, orig_to=, 
> relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.58/0/0/4.8, dsn=2.0.0, 
> status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
> as 6919414A8066)
> Aug  8 10:33:07 miltermatic postfix/qmgr[10053]: 971C814A805F: removed
> 
> Here's the postconf -n output:
> [root@miltermatic log]# postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> body_checks = regexp:$config_directory/usermanaged/body_checks
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = amavisd-new:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 3
> default_process_limit = 30
> header_checks = regexp:$config_directory/usermanaged/header_checks
> html_directory = /usr/share/doc/postfix-2.5.1-documentation/html
> inet_interfaces = $myhostname, localhost
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> mydomain = miltermatic.hiresites.com
> myhostname = miltermatic.hiresites.com
> mynetworks = 67.22.105.2 67.22.105.3 127.0.0.1 67.22.101.154 10.10.17.56
> myorigin = $myhostname
> newaliases_path = /usr/bin/newaliases.postfix
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.5.1-documentation/readme
> relayhost = 67.22.105.2

Enclose that in [] to inhibit MX lookup, which obviously won't find 
anything for "67.22.105.2". Also, having a relayhost in mynetworks 
might not always be a good idea. If that host thought mail should go 
back to you for some reason, you'd have a mail loop.

> sample_directory = /etc/postfix
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_connection_cache_destinations = 
> smtp_connection_cache_on_demand = no
> smtpd_banner = $myhostname ESMTP MilterMatician (0.1)
>                                 reject_unknown_recipient_domain
> smtpd_sereject_rbl_client relays.mail-abuse.org.org, 

Looks like a copy-paste error here. "relays.mail-abuse.org.org" does 
not exist, of course.

> unknown_local_recipient_reject_code = 550
> virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf
> 
> Thanks again - I look forward to your ideas on how to troubleshoot 
> further
> 
> - Original Message -
> From: /dev/rob0 
> To: postfix-users@postfix.org
> Cc: 
> Sent: Tuesday, August 7, 2012 6:50 PM
> Subject: Re: postfix thinks mysql managed email address is remote
> 
> On Tue, A

Re: postfix thinks mysql managed email address is remote

[Scott Brown]

Rob,
Thank you very much for your help.  It looks like the missing 
virtual_alias_domains was the problem.  

Scott


- Original Message -
From: /dev/rob0 
To: postfix-users@postfix.org
Cc: 
Sent: Wednesday, August 8, 2012 5:24 PM
Subject: Re: postfix thinks mysql managed email address is remote

On Wed, Aug 08, 2012 at 07:40:22AM -0700, Scott Brown wrote:
> The old virtual domain is resumearrow.com.  The new, mysql-managed 
> domain, is parallelemail.com
> 
> If I run a postmap -q on my email address under both domains, the 
> results are the same:
> [root@miltermatic log]# postmap -q sbr...@resumearrow.com 
> mysql:/etc/postfix/mysql-virtual.cf
> scottwb...@yahoo.com
> [root@miltermatic log]# postmap -q sbr...@parallelemail.com 
> mysql:/etc/postfix/mysql-virtual.cf
> scottwb...@yahoo.com

This is virtual_alias_maps. You don't show a setting below for 
virtual_alias_domains, and the default is "$virtual_alias_maps". So 
try this:

postmap -q resumearrow.com mysql:/etc/postfix/mysql-virtual.cf
postmap -q parallelemail.com mysql:/etc/postfix/mysql-virtual.cf

As I said, the domain lookup is failing. Therefore it is considered 
an unauthorized destination, and reject_unauth_destination blocks 
your mail.

http://www.postfix.org/ADDRESS_CLASS_README.html#virtual_alias_class
http://www.postfix.org/VIRTUAL_README.html#virtual_alias

BTW, same-envelope forwarding of mail to domains you do not control 
(yahoo.com) is likely to be troublesome. When you get and forward 
spam, they might flag you as a spam source.

> Because postfix rejects the session at the RCPT command, I don't 
> believe any further details of the session are available for the 
> parallelemail domain:
> [root@miltermatic log]# grep "sbr...@parallelemail.com" maillog
> Aug  8 10:33:21 miltermatic postfix/smtpd[10117]: NOQUEUE: reject: RCPT from 
> mail-qc0-f170.google.com[209.85.216.170]: 554 5.7.1 
> : Relay access denied; from= 
> to= proto=ESMTP helo=
> 
> Postfix did assign a message identifier to the email to 
> resumearrow.com, so I can provide more, non-verbose, session 
> details on that:
> [root@miltermatic log]# grep "sbr...@resumearrow.com" maillog
> Aug  8 10:33:07 miltermatic postfix/smtp[10081]: 971C814A805F: 
> to=, orig_to=, 
> relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.58/0/0/4.8, dsn=2.0.0, 
> status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
> as 6919414A8066)
> [root@miltermatic log]# grep "971C814A805F" maillog
> Aug  8 10:33:02 miltermatic postfix/smtpd[10119]: 971C814A805F: 
> client=mail-qa0-f49.google.com[209.85.216.49]
> Aug  8 10:33:02 miltermatic postfix/cleanup[10060]: 971C814A805F: 
> message-id=
> Aug  8 10:33:02 miltermatic postfix/qmgr[10053]: 971C814A805F: 
> from=, size=5732, nrcpt=1 (queue active)
> Aug  8 10:33:07 miltermatic postfix/smtp[10081]: 971C814A805F: 
> to=, orig_to=, 
> relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.58/0/0/4.8, dsn=2.0.0, 
> status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
> as 6919414A8066)
> Aug  8 10:33:07 miltermatic postfix/qmgr[10053]: 971C814A805F: removed
> 
> Here's the postconf -n output:
> [root@miltermatic log]# postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> body_checks = regexp:$config_directory/usermanaged/body_checks
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = amavisd-new:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 3
> default_process_limit = 30
> header_checks = regexp:$config_directory/usermanaged/header_checks
> html_directory = /usr/share/doc/postfix-2.5.1-documentation/html
> inet_interfaces = $myhostname, localhost
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> mydomain = miltermatic.hiresites.com
> myhostname = miltermatic.hiresites.com
> mynetworks = 67.22.105.2 67.22.105.3 127.0.0.1 67.22.101.154 10.10.17.56
> myorigin = $myhostname
> newaliases_path = /usr/bin/newaliases.postfix
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.5.1-documentation/readme
> relayhost = 67.22.105.2

Enclose that in [] to inhibit MX lookup, which obviously won't find 
anything for "67.22.105.2". Also, having a relayhost in mynetworks 
might not always be a good idea. If that host thought mail should go 
back to you for some reason, you'd have a mail loop.

> sample_directory = /etc/postfix
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_connection_cache_destinations = 
> smtp_connection_cache_on_demand = no
> smtpd_banner = $myhostname ESMTP MilterMatician (0.1)
>                                 reject_unknown_recipient_domain
> smtpd_sereject_rbl_client relays.mail-abuse.org.org, 

Looks like a copy-paste error here. "relays.mail-abuse.org.org" does 
not exist, of course.

> unknown_local_recipient_reject_code = 550
> virtual_alias_maps = mysql:/etc/postfix/mysql-vi

Re: soft_bounce=yes in postmulti setup

[mailing list subscriber]

On Wed, Aug 8, 2012 at 4:19 PM, Noel Jones  wrote:
> On 8/8/2012 4:22 AM, mailing list subscriber wrote:
>> Hi,
>> I asked this earlier but maybe skipped your attention.
>>
>> In summary,
>>
>> Why do body/header checks generate 5xx rejects even with soft_bounce=yes?
>
>
> soft_bounce works as documented. The log may show a 5.x.x extended
> status code, but the client receives a 4xx response and a 4.x.x status.
>

thanks for explanation, I did not know that!

Wietse, why would anyone want to read false information in the logs?
for example "user unknown" shows 4xx with soft_bounce=yes. are there
any others? where can I find a list of rejects that lie to me with 5xx
and I actually send a 4xx?

Re: mailtail

[ml]

is a guilty network for "a freedom"

Le 2012-08-08 20:07, Ben Rosengart a écrit :

On Wed, Aug 08, 2012 at 09:48:40PM +0800, Alvin Wong wrote:

With just a single binary I have 80% thought of it being a Trojan.


23 lines of non-obfuscated bash.


--
  http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC2626742
  gpg --keyserver pgp.mit.edu --recv-key C2626742

  http://about.me/fakessh
  http://urlshort.eu fakessh @
  http://gplus.to/sshfake
  http://gplus.to/sshswilting
  http://gplus.to/john.swilting
  https://lists.fakessh.eu/mailman/
  This list is moderated by me, but all applications will be accepted
  provided they receive a note of presentation

Re: always_bcc

[Fernando Maior]

Hi Saldanha,

As per your config file:

   - myhostname = labmail.temp.com
   - allways_bcc = t...@temp.com

Maybe I am guessing wrong, but I believe you are trying to deliver the
allways_bcc messages to a domain that is hosted by the server
labmail.temp.com ; if that is the case, I sugest
you should try one
of these things:

   1. configure allways_bcc to a domain that is hosted at the other server;
   or
   2. configure /etc/postfix/transport to send mail posted to
t...@temp.comto the other server.

The second sugestion is my first choice of procedure. You may have
a look at the transport table doc at http://www.postfix.org/transport.5.html

Fernando Maior


On Tue, Aug 7, 2012 at 9:54 AM, Alfredo Saldanha
wrote:

> Hi there,
>
> I'm trying to implement always_bcc to send a copy of all received messages
> to another server.
> My idea is disable any notification messages back in the second server (if
> something goes wrong) and discard all messages after received.
> This way is like the "clean" solution to ensure that the always_bcc
> destination never bounces or refuses a message.
> It seems weird, but is only a test that I need to do.
>
> 1st problem: aways_bcc is not working.
> 2nd problem: I have no idea how to disable notification messages.
>
> My main.cf: http://dpaste.com/782638/
> My master.cf: http://dpaste.com/782639/
>
> Thank you.
>

Re: Mapping one domain to another (mysql)

[email builder]

>>  Postfix expects an empty set (i.e. no rows returned) if it is to respond

>>  negatively that a virtual alias does not exist.
>>  Returning NULL does not equal no rows returned.
> 
> email builder:
>> Are you sure?? 
> 
> 100% confirmed. To return NOTFOUND, you MUST return NO RESULT.

So with NULL, Postfix must be trying to do something, like what, map and 
deliver to n...@example.com and failing? Because I'm finding the same result 
when returning NULL (rejected after RCPT TO with "Recipient address rejected: 
User unknown")

In any case, this is helpful to know so I can adjust my query appropriately.

Re: Mapping one domain to another (mysql)

[email builder]

>>  >> Postfix expects an empty set (i.e. no rows returned) if it is to 

>> >> respond
>>  >> negatively that a virtual alias does not exist.
>>  >> Returning NULL does not equal no rows returned.
>> 
>>  >Are you sure?? 
>> 
>>  100% confirmed. To return NOTFOUND, you MUST return NO RESULT.
> 
> The common code that underlies the MySQL, PgSQL and LDAP table
> drivers ignores empty result values with a warning. While NULL
> result values are silently ignored you should not depend on this
> undocumented behaviour.

Ah, OK, that explains it.  Thanks.

Re: mysql query suppressed?

[email builder]

>>  >>  2) it's not intuitive to me that the query I have given to 

>> >> postifx
>>  >>  is conditionally executed. 
>>  > 
>>  > And THAT is precisely what the documentation says.
>> 
>>  And THAT is merely what I was asking to have confirmation of
>>  (not sure why that is so difficult)...
> 
> It is difficult only because you prefer to believe fanciful
> interpretations a plainly stated behaviour. 

NO. If you read my inquiry, I did read the documentation and understand it 
correctly.  I merely had some lingering doubts and was asking for simple 
confirmation.  Everyone's steadfast refusal to confirm (nothing more than "yes" 
would have been necessary), instead responding with hostile responses like 
yours is alienating, especially to a polite inquiry.  Is this how you treat 
people face to face as well?

Everyone has their own interpretations of what they read, based on varying 
degrees of expertise. If you refuse to hear the impression others get from 
reading the documentation, then maybe it will never improve.

> It is intuititive if you understand that Postfix makes multiple
> lookups for a single key, some of which contain only the user or
> the domain part. The low-level table driver (LDAP, MySQL, ...)
> does not know which part of the address it is handed, or even
> whether the lookup key is an address at all.
>
> Thus, when a lookup key does not resembe an full email address, it
> is not possible to determine whether the key has a domain part or
> not. Instead of making meaningless queries that may produce incorrect
> results, Postfix suppresses the query.

If Postfix knows what's going on, then it may be able to communicate the
 situation through to the backend. I don't follow you entirely, since my
 response to this would be that if the query needs to know what part of the 
address the key is, it should be able to learn this by examining 
%u or %d to be empty/NULL when the key doesn't have @ in it.  Of course, the 
query would only need to do this if it had advanced requirements.

But I don't have the level of intimate knowledge of the workings and only speak 
as a user, so I guess you can dismiss my input with a Monty Python wisecrack.

>>  and also because this fact is IMO buried too deep in the documentation.
> 
> It is documented in the paragraph that describes the "%d" syntax.
> Don't use "%d" in queries without reading what it does. There is
> surely no better place to describe "%d" semantics than in the
> associated paragraph of the query syntax definitions.

I am not suggesting that text be removed, only that it is surprising to learn 
that the query is ignored in some cases and this might be a good thing to note 
elsewhere in addition. But it doesn't really sound like you want feedback 
anyway.