On Wed, Nov 23, 2005 at 11:52:40AM +0800, Jason wrote:

> version : postfix-2.2.5-3.rhel4.rpm
> OS : Centos 4.2
>
> After this setup, emails sent to otherusers@... will be having
> "aaazzzaaazzzaaazzzaaazzzaaazzz" in the body.
>
> content of generic :
>
> sender_a    sender_a@...
> sender_b    sender_b@...
> etc
>
> I have seen some posts on forums claiming that this may be caused by virus,
> but I don't think so. What's wrong with generic?
>

This is a new behaviour of the Postfix 2.2 release, to spread the word
that Postfix now has a complete "A-to-Z" feature set.

Some cynics argue instead that there may be issues with your hardware
or the Centos compiler toolchain, userland or kernel, but they are
clearly wrong as evidenced by this message, sent from my system which
only has Postfix 2.2 in common with yours and yet still includes the
offending text.

--
	 Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@...?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

No, I'm NOT using the postfix server that I'm asking for help to send this
  email. In fact, this email is not sent by postfix, it's by sendmail +
  Mailscanner. And the postfix server that's in problem is not using
  mailscanner.

  Jason

> ----- Original Message -----
> From: "Nicolas Riendeau" <knightr@...>
> To: <postfix-users@...>
> Sent: Wednesday, November 23, 2005 12:12 PM
> Subject: Re: I'm sending "aaazzzaaazzzaaazzzaaazzzaaazzz" emails
>
>
>> Hi!
>>
>>>
>>> This is a new behaviour of the Postfix 2.2 release, to spread the word
>>> that Postfix now has a complete "A-to-Z" feature set.
>>>
>>> Some cynics argue instead that there may be issues with your hardware
>>> or the Centos compiler toolchain, userland or kernel, but they are
>>> clearly wrong as evidenced by this message, sent from my system which
>>> only has Postfix 2.2 in common with yours and yet still includes the
>>> offending text.
>>>
>>
>> Unless I'm reading the headers of his message wrong he is using
>> Mailscanner with Postfix... ***
>>
>> Need I say more...
>>
>> Have a nice day!
>>
>> *** not a recommended configuration...
>>
>>
>>
>>
>

So, will it be the problem of rpm? Or do I have to switch back to the
standard centos' 2.1.x distribution of postfix to resolve the problem?

Jason


----- Original Message -----
From: "Victor Duchovni" <Victor.Duchovni@...>
To: <postfix-users@...>
Sent: Wednesday, November 23, 2005 12:03 PM
Subject: Re: I'm sending "aaazzzaaazzzaaazzzaaazzzaaazzz" emails


> On Wed, Nov 23, 2005 at 11:52:40AM +0800, Jason wrote:
>
>> version : postfix-2.2.5-3.rhel4.rpm
>> OS : Centos 4.2
>>
>> After this setup, emails sent to otherusers@... will be having
>> "aaazzzaaazzzaaazzzaaazzzaaazzz" in the body.
>>
>> content of generic :
>>
>> sender_a    sender_a@...
>> sender_b    sender_b@...
>> etc
>>
>> I have seen some posts on forums claiming that this may be caused by
>> virus,
>> but I don't think so. What's wrong with generic?
>>
>
> This is a new behaviour of the Postfix 2.2 release, to spread the word
> that Postfix now has a complete "A-to-Z" feature set.
>
> Some cynics argue instead that there may be issues with your hardware
> or the Centos compiler toolchain, userland or kernel, but they are
> clearly wrong as evidenced by this message, sent from my system which
> only has Postfix 2.2 in common with yours and yet still includes the
> offending text.
>
> --
> Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> <mailto:majordomo@...?body=unsubscribe%20postfix-users>
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
>

Hi!

>
> This is a new behaviour of the Postfix 2.2 release, to spread the word
> that Postfix now has a complete "A-to-Z" feature set.
>
> Some cynics argue instead that there may be issues with your hardware
> or the Centos compiler toolchain, userland or kernel, but they are
> clearly wrong as evidenced by this message, sent from my system which
> only has Postfix 2.2 in common with yours and yet still includes the
> offending text.
>

Unless I'm reading the headers of his message wrong he is using
Mailscanner with Postfix... ***

Need I say more...

Have a nice day!

*** not a recommended configuration...

version : postfix-2.2.5-3.rhel4.rpm
OS : Centos 4.2
local host : chinamail (only for intranet, not fqdn)
public domain : newhonest.com

I have my new postfix set up recently for my intranet. I have some
restriction settings in main.cf

smtpd_recipient_restrictions = check_sender_access
hash:/etc/postfix/restricted_senders, permit_mynetworks,
reject_unauth_destination

#
smtpd_restriction_classes = local_only nh_only
local_only = check_recipient_access hash:/etc/postfix/local_domains,
reject_unauth_destination
nh_only = check_recipient_access hash:/etc/postfix/nh_domain,
reject_unauth_destination
#

(nh_domain, local_domains and restricted_senders are created and postmap-ed)
With the above config, everything is working well, except when email is sent
to our own domain (newhonest.com, but bot chinamial), the sender's address
looks like sender@chinamail. In order to make it looks like
sender@..., I added the following line, and created the file
/etc/postfix/generic, the postmap it:

#
smtp_generic_maps = hash:/etc/postfix/generic
#

After this setup, emails sent to otherusers@... will be having
"aaazzzaaazzzaaazzzaaazzzaaazzz" in the body.

content of generic :

sender_a    sender_a@...
sender_b    sender_b@...
etc

I have seen some posts on forums claiming that this may be caused by virus,
but I don't think so. What's wrong with generic?

Jason

On Tue, 2005-11-22 at 22:44 +0100, Magnus Bäck wrote:
> On Tuesday, November 22, 2005 at 15:55 CET,
>      Varun <varun_saa@...> wrote:
>
> > Basically I have my mailserver working using :
> >
> > http://www.jennings.homelinux.net/mailserver_config.html
> >
> > Now I would like to improve on it by using :
> >
> > http://www.howtoforge.com/virtual_postfix_mysql_quota_courier
> >
> > One doubt I have is do I have uninstall procmail & fetchmail
> > that I used in the first place.
>
> In any case you obviously don't have to remove those tools from your
> system, but since procmail does not really support virtual users you
> can't use it anymore unless you perform some ugly tricks.
>
> > If yes then how the functionality of both is achieved then ?
>
> fetchmail, on the other hand, is completely independent from how Postfix
> delivers and stores the messages. fetchmail collects messages via
> POP/IMAP and delivers them to certain addresses via SMTP (typically).
> That behaviour won't be affected.
>
> > And why do we call it virtual users ?
>
> Because they are not real system users. They are only known to the mail
> system and cannot log in otherwise.
>
> What problem are you trying to solve?


Nothing yet.

Just wanted a little clarification before
I started.

Thanks

Varun

This was relatively easy to implement, given that all the building
blocks were already lying around somewhere.

The updated transport manual page summarizes how relayhost etc.
play together.

	 Wietse

TRANSPORT(5)                                                      TRANSPORT(5)
...
DESCRIPTION
        ...
        This  mapping overrides the default transport:nexthop selection that is
        built into Postfix:

        local_transport (default: local:$myhostname)
               ...

        virtual_transport (default: virtual:)
               ...

        relay_transport (default: relay:)
               This is the default for remote delivery to domains  listed  with
               relay_domains.  The  relayhost and sender_relayhost_maps parame-
               ters specify the default nexthop destination. When none is spec-
               ified, the nexthop destination is the recipient domain.

        default_transport (default: smtp:)
               This  is  the default for remote delivery to other destinations.
               The relayhost and sender_relayhost_maps parameters  specify  the
               default nexthop destination. When none is specified, the nexthop
               destination is the recipient domain.

Covington, Chris a écrit :
> Guys,
>
> This is what I've setup:
>
> fauxmx01.plusone.com MX 10 (fake MX, non-responding <network> IP)
> nymeta01.plusone.com MX 20 (real MX)
> nymeta02.plusone.com MX 20 (real MX)
> fauxmx02.plusone.com MX 30 (fake MX, non-responding <broadcast> IP)
>
> This will slow down the "sneak in through the presumably
> less-restrictive, lower-priority MX" as well as the "go
> straight to the highest-priority MX" direct-to-MXers.  And
> it uses no IPs, if you use your network and broadcast IPs.
> I wonder if this can be used in place of greylisting...

no, this is different than GL:

here, every host (legit or not) will try MX1, then if compliant, will
try MX2. legit systems are thus somewhat penalized.

In GL, once a host has been "automatically whitelisted", it is no more
deferred.


Also here, a spamware that tries second MX won't be blocked. while in GL
it will be deferred.

so the approaches may be used together. I personally don't feel playing
these MX games.

Hi Mouss,

I did It too, I forgot to mention about that on early mail. The file remains
empty, no entries was recorded.

Bye,

Sergio


>>>>>-----Original Message-----
>>>>>From: owner-postfix-users@...
>>>>>[mailto:owner-postfix-users@...] On Behalf Of mouss
>>>>>Sent: Tuesday, November 22, 2005 5:24 PM
>>>>>To: Sérgio Ferreira
>>>>>Cc: postfix-users@...
>>>>>Subject: maildrop not delivering to the right maildir
>>>>>[Was: Postfix + MDA]
>>>>>
>>>>>Sérgio Ferreira a écrit :
>>>>>> Hi Mouss,
>>>>>>
>>>>>> I ran Maildrop -V 9 -d .....
>>>>>>
>>>>>> This is what I found in tmp.out
>>>>>>
>>>>>> HOME=/home/data/sergio.ferreira/Maildir/,
>>>>>> MAILDIR=/home/data/sergio.ferreira/Maildir/
>>>>>>
>>>>>
>>>>>I meant send a message via postfix and look at the above.
>>>>>My feeling is that it has to do with trusted_users.

Hi Mouss,

I ran Maildrop -V 9 -d .....

This is what I found in tmp.out

HOME=/home/data/sergio.ferreira/Maildir/,
MAILDIR=/home/data/sergio.ferreira/Maildir/


Thanks,


Sergio


>>>>>-----Original Message-----
>>>>>From: owner-postfix-users@...
>>>>>[mailto:owner-postfix-users@...] On Behalf Of mouss
>>>>>Sent: Tuesday, November 22, 2005 4:27 PM
>>>>>To: Sérgio Ferreira
>>>>>Cc: postfix-users@...
>>>>>Subject: Re: Postfix + MDA
>>>>>
>>>>>Sérgio Ferreira a écrit :
>>>>>> Hi Ralf,
>>>>>>
>>>>>> that is the problem... When:
>>>>>>
>>>>>> Nov 22 11:06:09 gaia postfix/pipe[9725]: 186E94C095:
>>>>>> to=<sergio.ferreira@...>, relay=maildrop, delay=0,
>>>>>> status=sent
>>>>>> (gaia.cultura.gov.br)
>>>>>>
>>>>>> is logged the message is send back to sender and Maildrop do not
>>>>>> delivery the nessage to Maildir. I checked my setup against the
>>>>>> informations available on Postfix site, but I didn´t
>>>>>find out any differences on It.
>>>>>> Working with maildrop in manual mode (maildrop -V 9 -d ...) the
>>>>>> message is delivered correctly. I belive there is some misplaced
>>>>>> configuration option on Postfix setup.
>>>>>>
>>>>>> I set Maildrop to verbose mode at master.cf. Maildrop
>>>>>sent out the
>>>>>> message which an acceptable action and It is why no
>>>>>error is encoutered.
>>>>>>
>>>>>>
>>>>>> Have you some directions?
>>>>>
>>>>>add this to your maildroprc:
>>>>>`echo HOME=$HOME, MAILDIR=$DEFAULT > /tmp/maildrop.out`
>>>>>and send a test message. then look at the value of MAILDIR
>>>>>in /tmp/maildrop.out.
>>>>>
>>>>>I've seen this today when using the official pkgsrc for
>>>>>maildrop but didn't have the time to check why that
>>>>>happens. probably ./configure options issue...

Guys,

This is what I've setup:

fauxmx01.plusone.com MX 10 (fake MX, non-responding <network> IP)
nymeta01.plusone.com MX 20 (real MX)
nymeta02.plusone.com MX 20 (real MX)
fauxmx02.plusone.com MX 30 (fake MX, non-responding <broadcast> IP)

This will slow down the "sneak in through the presumably
less-restrictive, lower-priority MX" as well as the "go
straight to the highest-priority MX" direct-to-MXers.  And
it uses no IPs, if you use your network and broadcast IPs.
I wonder if this can be used in place of greylisting...

We'll see how it works.

---
Chris Covington
IT
Plus One Health Management
75 Maiden Lane Suite 801
NY, NY 10038
646-312-6269
http://www.plusoneactive.com

On Tuesday, November 22, 2005 at 15:55 CET,
      Varun <varun_saa@...> wrote:

> Basically I have my mailserver working using :
>
> http://www.jennings.homelinux.net/mailserver_config.html
>
> Now I would like to improve on it by using :
>
> http://www.howtoforge.com/virtual_postfix_mysql_quota_courier
>
> One doubt I have is do I have uninstall procmail & fetchmail
> that I used in the first place.

In any case you obviously don't have to remove those tools from your
system, but since procmail does not really support virtual users you
can't use it anymore unless you perform some ugly tricks.

> If yes then how the functionality of both is achieved then ?

fetchmail, on the other hand, is completely independent from how Postfix
delivers and stores the messages. fetchmail collects messages via
POP/IMAP and delivers them to certain addresses via SMTP (typically).
That behaviour won't be affected.

> And why do we call it virtual users ?

Because they are not real system users. They are only known to the mail
system and cannot log in otherwise.

What problem are you trying to solve?

--
Magnus Bäck
magnus@...

* S?rgio Ferreira <sergio.ferreira@...>:

> Nov 22 17:37:02 gaia postfix/pipe[12985]: AB4204C095:
> to=<sergio.ferreira@...>, relay=maildrop, delay=0, status=bounced
> (user unknown. Command output: Invalid user specified. )

There's your problem
maildrop doesn't know the user.

--
Ralf Hildebrandt (Ralf.Hildebrandt@...)          spamtrap@...
Postfix - Einrichtung, Betrieb und Wartung       Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Never underestimate the bandwidth of a station wagon full of tapes.
                               -- Dr. Warren Jackson, Director, UTCS

Aaron Harwood a écrit :
>
> /usr/sbin/serviceconf reports that sendmail is not running.
>
> Something must be calling it, but what?
>

the sendmail daemon is not running, but the sendmail command is used by
your mail program. configure /etc/mailer.conf to use postfix sendmail
compatibility command.

but it's simpler to uninstall sendmail sinc eyou probably don't need it.

On Sun Nov 20 22:04:01 2005, postfix-users wrote:

>On Sun, Nov 20, 2005 at 08:58:31PM -0500, Tom Allison wrote:
>
>> >1 /etc/postfix/main.cf:
>> >2  smtp_generic_maps = hash:/etc/postfix/generic
>
>Postfix version? Unmodified table contents? Sample output from "postmap
>-q" demonstrating the relevant table lookups work? Required "postconf -n"
>output? Once again with the logs (resend all the evidence together).
>

Didn't need all that, thank you.
key word: masquarade.

Hi Ralf,

>>>>>> I need any help with Maildir delivery process. When a message is
>>>>>> received It isn?t delivered to Maildir, but It is send
>>>>>back to sender
>>>>>> and postfix log It as success process. See the log below:
>>>>>>
>>>>>> Nov 22 16:12:41 gaia postfix/smtp[12696]: 67C304C09C:
>>>>>> to=<sergio.ferreira@...>,
>>>>>> relay=mx1.minc.gov.br[200.198.204.69],
>>>>>> delay=0,
>>>>>>
>>>>>> status=sent (250 Requested mail action okay, completed.)
>>>>>>
>>>>>> The message into (brackets) above should be "delivered
>>>>>to maildir"
>>>>>> instead of (250 .....)
>>>>>
>>>>>Postfix doesn't work that way.

I thought that because I changed the transport either virtual or local and
the output was like I wrote above.

>>>>>Check your logs to see what
>>>>>happened with 67C304C09C
>>>>>

Below, It is the log concerning the message 67C304C09C:

Nov 22 16:12:41 gaia postfix/cleanup[12692]: open incoming/6/67C304C09C
Nov 22 16:12:41 gaia postfix/cleanup[12692]: cleanup_open: open
incoming/6/67C304C09C
Nov 22 16:12:41 gaia postfix/cleanup[12692]: send attr queue_id = 67C304C09C
Nov 22 16:12:41 gaia postfix/bounce[12695]: input attribute value:
67C304C09C
Nov 22 16:12:41 gaia postfix/cleanup[12692]: cleanup_header_callback:
'Received: by localhost (Postfix)??id 67C304C09C; Tue, 22 Nov 2005 16:12:41
-0200 (BRST)'
Nov 22 16:12:41 gaia postfix/cleanup[12692]: 67C304C09C:
message-id=<20051122181241.67C304C09C@localhost>
Nov 22 16:12:41 gaia postfix/qmgr[12688]: qmgr_active_feed:
incoming/6/67C304C09C
Nov 22 16:12:41 gaia postfix/qmgr[12688]: qmgr_message_alloc: active
67C304C09C
Nov 22 16:12:41 gaia postfix/qmgr[12688]: 67C304C09C: from=<>, size=2683,
nrcpt=1 (queue active)
Nov 22 16:12:41 gaia postfix/qmgr[12688]: qmgr_peer_select: 67C304C09C smtp
minc.gov.br (1 of 5)
Nov 22 16:12:41 gaia postfix/qmgr[12688]: qmgr_job_retire: 67C304C09C
Nov 22 16:12:41 gaia postfix/qmgr[12688]: send attr queue_id = 67C304C09C
Nov 22 16:12:41 gaia postfix/smtp[12696]: input attribute value: 67C304C09C
Nov 22 16:12:41 gaia postfix/smtp[12696]: deliver_request_get: file
active/6/67C304C09C
Nov 22 16:12:41 gaia postfix/smtp[12696]: 67C304C09C:
to=<sergio.ferreira@...>, relay=mx1.minc.gov.br[200.198.204.69],
delay=0, status=sent (250 Requested mail action okay, completed.)
Nov 22 16:12:41 gaia postfix/qmgr[12688]: qmgr_active_done: 67C304C09C
Nov 22 16:12:41 gaia postfix/qmgr[12688]: 67C304C09C: removed
Nov 22 16:12:41 gaia postfix/qmgr[12688]: qmgr_job_free: 67C304C09C smtp


>>>>>Show complete logs for a delivery of a mail that should go
>>>>>to a local Maildir/
>>>>>

I pasted the whole process of a message, only smtpd and maildrop are
verbose.

Nov 22 17:37:02 gaia postfix/smtpd[12982]: connection established
Nov 22 17:37:02 gaia postfix/smtpd[12982]: master_notify: status 0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: name_mask: resource
Nov 22 17:37:02 gaia postfix/smtpd[12982]: name_mask: software
Nov 22 17:37:02 gaia postfix/smtpd[12982]: connect from
mx1.minc.gov.br[200.198.204.69]
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_list_match:
mx1.minc.gov.br: no match
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_list_match: 200.198.204.69:
no match
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_list_match:
mx1.minc.gov.br: no match
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_list_match: 200.198.204.69:
no match
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >
mx1.minc.gov.br[200.198.204.69]: 220 localhost ESMTP Postfix
Nov 22 17:37:02 gaia postfix/smtpd[12982]: watchdog_pat: 0x806a7e0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: <
mx1.minc.gov.br[200.198.204.69]: HELO mx1.minc.gov.br
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >
mx1.minc.gov.br[200.198.204.69]: 250 localhost
Nov 22 17:37:02 gaia postfix/smtpd[12982]: watchdog_pat: 0x806a7e0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: <
mx1.minc.gov.br[200.198.204.69]: MAIL FROM:<sergio.ferreira@...>
Nov 22 17:37:02 gaia postfix/smtpd[12982]: extract_addr: input:
<sergio.ferreira@...>
Nov 22 17:37:02 gaia postfix/smtpd[12982]: smtpd_check_addr:
addr=sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: ctable_locate: move existing
entry key sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: extract_addr: result:
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: fsspace: .: block size 4096,
blocks free 11350962
Nov 22 17:37:02 gaia postfix/smtpd[12982]: smtpd_check_size: blocks 4096
avail 11350962 min_free 0 msg_size_limit 10240000
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >
mx1.minc.gov.br[200.198.204.69]: 250 Ok
Nov 22 17:37:02 gaia postfix/smtpd[12982]: watchdog_pat: 0x806a7e0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: <
mx1.minc.gov.br[200.198.204.69]: RCPT TO:<sergio.ferreira@...>
Nov 22 17:37:02 gaia postfix/smtpd[12982]: extract_addr: input:
<sergio.ferreira@...>
Nov 22 17:37:02 gaia postfix/smtpd[12982]: smtpd_check_addr:
addr=sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: ctable_locate: move existing
entry key sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: extract_addr: result:
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >>> START Recipient address
RESTRICTIONS <<<
Nov 22 17:37:02 gaia postfix/smtpd[12982]: generic_checks:
name=permit_mynetworks
Nov 22 17:37:02 gaia postfix/smtpd[12982]: permit_mynetworks:
mx1.minc.gov.br 200.198.204.69
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_hostname: mx1.minc.gov.br
~? 10.0.0.0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_hostaddr: 200.198.204.69 ~?
10.0.0.0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_hostname: mx1.minc.gov.br
~? 127.0.0.0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_hostaddr: 200.198.204.69 ~?
127.0.0.0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_hostname: mx1.minc.gov.br
~? 200.198.204.64/27
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_hostaddr: 200.198.204.69 ~?
200.198.204.64/27
Nov 22 17:37:02 gaia postfix/smtpd[12982]: generic_checks:
name=permit_mynetworks status=1
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >>> CHECKING RECIPIENT MAPS <<<
Nov 22 17:37:02 gaia postfix/smtpd[12982]: ctable_locate: leave existing
entry key sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: maps_find:
recipient_canonical_maps: sergio.ferreira@...: not found
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_string: cultura.gov.br ~?
localhost
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_string: cultura.gov.br ~?
localhost.cultura.gov.br
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_string: cultura.gov.br ~?
localhost
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_list_match: cultura.gov.br:
no match
Nov 22 17:37:02 gaia postfix/smtpd[12982]: maps_find:
recipient_canonical_maps: @cultura.gov.br: not found
Nov 22 17:37:02 gaia postfix/smtpd[12982]: mail_addr_find:
sergio.ferreira@... -> (not found)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: maps_find: canonical_maps:
sergio.ferreira@...: not found
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_string: cultura.gov.br ~?
localhost
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_string: cultura.gov.br ~?
localhost.cultura.gov.br
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_string: cultura.gov.br ~?
localhost
Nov 22 17:37:02 gaia postfix/smtpd[12982]: match_list_match: cultura.gov.br:
no match
Nov 22 17:37:02 gaia postfix/smtpd[12982]: maps_find: canonical_maps:
@cultura.gov.br: not found
Nov 22 17:37:02 gaia postfix/smtpd[12982]: mail_addr_find:
sergio.ferreira@... -> (not found)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: dict_ldap_lookup: In
dict_ldap_lookup
Nov 22 17:37:02 gaia postfix/smtpd[12982]: dict_ldap_lookup: Using existing
connection for LDAP source ldapalias
Nov 22 17:37:02 gaia postfix/smtpd[12982]: dict_ldap_lookup: Searching with
filter
(&(|(mail=sergio.ferreira@...)(mailAlternateAddress=sergio.ferrei
ra@...)))
Nov 22 17:37:02 gaia slapd[2677]: conn=1383 op=2 SRCH
base="ou=Users,dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(|(mail=sergio.ferreira@...)(mailAlternateAddress=sergi
o.ferreira@...)))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1383 op=2 SRCH attr=mail
Nov 22 17:37:02 gaia slapd[2677]: conn=1383 op=2 SEARCH RESULT tag=101 err=0
nentries=1 text=
Nov 22 17:37:02 gaia postfix/smtpd[12982]: dict_ldap_get_values[1]: Search
found 1 match(es)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: dict_ldap_get_values[1]: search
returned 1 value(s) for requested result attribute mail
Nov 22 17:37:02 gaia postfix/smtpd[12982]: dict_ldap_get_values[1]: Leaving
dict_ldap_get_values
Nov 22 17:37:02 gaia postfix/smtpd[12982]: dict_ldap_lookup: Search returned
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: maps_find: virtual_alias_maps:
ldap:ldapalias(0,100): sergio.ferreira@... =
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: mail_addr_find:
sergio.ferreira@... -> sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: connect to subsystem
public/cleanup
Nov 22 17:37:02 gaia postfix/smtpd[12982]: public/cleanup socket: wanted
attribute: queue_id
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute name: queue_id
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute value: AB4204C095
Nov 22 17:37:02 gaia postfix/smtpd[12982]: public/cleanup socket: wanted
attribute: (list terminator)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute name: (end)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: send attr flags = 50
Nov 22 17:37:02 gaia postfix/smtpd[12982]: AB4204C095:
client=mx1.minc.gov.br[200.198.204.69]
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >
mx1.minc.gov.br[200.198.204.69]: 250 Ok
Nov 22 17:37:02 gaia postfix/smtpd[12982]: watchdog_pat: 0x806a7e0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: <
mx1.minc.gov.br[200.198.204.69]: DATA
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >
mx1.minc.gov.br[200.198.204.69]: 354 End data with <CR><LF>.<CR><LF>
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=4 SRCH
base="ou=Users,dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(|(mail=sergio.ferreira@...)(mailAlternateAddress=sergi
o.ferreira@...)))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=4 SRCH attr=mail
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=4 SEARCH RESULT tag=101 err=0
nentries=1 text=
Nov 22 17:37:02 gaia postfix/smtpd[12982]: public/cleanup socket: wanted
attribute: status
Nov 22 17:37:02 gaia postfix/cleanup[12984]: AB4204C095:
message-id=<20051122193702.AB4204C095@localhost>
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute name: status
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute value: 0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: public/cleanup socket: wanted
attribute: reason
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute name: reason
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute value: (end)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: public/cleanup socket: wanted
attribute: (list terminator)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: input attribute name: (end)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >
mx1.minc.gov.br[200.198.204.69]: 250 Ok: queued as AB4204C095
Nov 22 17:37:02 gaia postfix/qmgr[12980]: AB4204C095:
from=<sergio.ferreira@...>, size=988, nrcpt=1 (queue active)
Nov 22 17:37:02 gaia postfix/smtpd[12982]: watchdog_pat: 0x806a7e0
Nov 22 17:37:02 gaia slapd[2677]: conn=1382 op=5 SRCH
base="ou=Users,dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(|(mail=cultura.gov.br)(mailAlternateAddress=cultura.gov.br)))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1382 op=5 SRCH attr=mail
Nov 22 17:37:02 gaia slapd[2677]: conn=1382 op=5 SEARCH RESULT tag=101 err=0
nentries=0 text=
Nov 22 17:37:02 gaia postfix/pipe[12985]: connection established
Nov 22 17:37:02 gaia postfix/pipe[12985]: master_notify: status 0
Nov 22 17:37:02 gaia postfix/pipe[12985]: deliver_request_initial: send
initial status
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr status = 0
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
flags
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: flags
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: 3
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
queue_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: queue_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: active
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
queue_id
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: queue_id
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: AB4204C095
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
offset
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: offset
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: 327
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
size
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: size
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: 988
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
nexthop
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: nexthop
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
cultura.gov.br
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
encoding
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: encoding
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: (end)
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
sender
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: sender
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
errors-to
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: errors-to
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
return-receipt
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name:
return-receipt
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: (end)
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
time
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: time
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: 1132688222
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
client_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: client_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
mx1.minc.gov.br
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
client_address
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name:
client_address
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
200.198.204.69
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
protocol_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name:
protocol_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: SMTP
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
helo_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: helo_name
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
mx1.minc.gov.br
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
offset
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: offset
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: 293
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
original_recipient
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name:
original_recipient
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
recipient
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: recipient
Nov 22 17:37:02 gaia postfix/smtpd[12982]: <
mx1.minc.gov.br[200.198.204.69]: QUIT
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value:
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/smtpd[12982]: >
mx1.minc.gov.br[200.198.204.69]: 221 Bye
Nov 22 17:37:02 gaia postfix/pipe[12985]: maildrop socket: wanted attribute:
offset
Nov 22 17:37:02 gaia postfix/smtpd[12982]: disconnect from
mx1.minc.gov.br[200.198.204.69]
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: offset
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: 0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: master_notify: status 1
Nov 22 17:37:02 gaia postfix/smtpd[12982]: connection closed
Nov 22 17:37:02 gaia postfix/pipe[12985]: deliver_request_get: file
active/A/AB4204C095
Nov 22 17:37:02 gaia postfix/smtpd[12982]: watchdog_stop: 0x806a7e0
Nov 22 17:37:02 gaia postfix/smtpd[12982]: watchdog_start: 0x806a7e0
Nov 22 17:37:02 gaia postfix/pipe[12985]: deliver_message: from
<sergio.ferreira@...>
Nov 22 17:37:02 gaia authdaemond: received userid lookup request:
sergio.ferreira@...
Nov 22 17:37:02 gaia authdaemond: authldap: trying this module
Nov 22 17:37:02 gaia authdaemond: using search filter:
(&(objectClass=posixAccount)(uid=sergio.ferreira@...))
Nov 22 17:37:02 gaia slapd[2677]: conn=1387 op=2 SRCH
base="ou=Users,dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=sergio.ferreira@...))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1387 op=2 SRCH attr=mailMessageStore
mailMessageStore cn userPassword uid
Nov 22 17:37:02 gaia slapd[2677]: conn=1387 op=2 SEARCH RESULT tag=101 err=0
nentries=0 text=
Nov 22 17:37:02 gaia authdaemond: number of entries returned: 0 (but we need
exactly 1)
Nov 22 17:37:02 gaia authdaemond: authldap: REJECT - try next module
Nov 22 17:37:02 gaia authdaemond: FAIL, all modules rejected
Nov 22 17:37:02 gaia slapd[2677]: conn=1391 fd=32 ACCEPT from
IP=127.0.0.1:34250 (IP=0.0.0.0:389)
Nov 22 17:37:02 gaia slapd[2677]: conn=1391 op=0 BIND dn="" method=128
Nov 22 17:37:02 gaia slapd[2677]: conn=1391 op=0 RESULT tag=97 err=0 text=
Nov 22 17:37:02 gaia slapd[2677]: conn=1391 op=1 SRCH
base="dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=sergio.ferreira@...))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1391 op=1 SRCH attr=uid userPassword
uidNumber gidNumber cn homeDirectory loginShell gecos description
objectClass
Nov 22 17:37:02 gaia slapd[2677]: conn=1391 op=1 SEARCH RESULT tag=101 err=0
nentries=0 text=
Nov 22 17:37:02 gaia slapd[2677]: conn=1391 fd=32 closed
Nov 22 17:37:02 gaia postfix/pipe[12985]: connect to subsystem
private/bounce
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr nrequest = 0
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr flags = 0
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr queue_id = AB4204C095
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr original_recipient =
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr recipient =
sergio.ferreira@...
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr offset = 293
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr status = 5.0.0
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr action = failed
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr reason = user unknown.
Command output: Invalid user specified.
Nov 22 17:37:02 gaia postfix/pipe[12985]: private/bounce socket: wanted
attribute: status
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: status
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute value: 0
Nov 22 17:37:02 gaia postfix/pipe[12985]: private/bounce socket: wanted
attribute: (list terminator)
Nov 22 17:37:02 gaia postfix/pipe[12985]: input attribute name: (end)
Nov 22 17:37:02 gaia postfix/pipe[12985]: AB4204C095:
to=<sergio.ferreira@...>, relay=maildrop, delay=0, status=bounced
(user unknown. Command output: Invalid user specified. )
Nov 22 17:37:02 gaia postfix/pipe[12985]: deliver_request_final: send: "" 0
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr reason =
Nov 22 17:37:02 gaia postfix/pipe[12985]: send attr status = 0
Nov 22 17:37:02 gaia postfix/pipe[12985]: master_notify: status 1
Nov 22 17:37:02 gaia postfix/pipe[12985]: connection closed
Nov 22 17:37:02 gaia postfix/pipe[12985]: watchdog_stop: 0x80547c8
Nov 22 17:37:02 gaia postfix/pipe[12985]: watchdog_start: 0x80547c8
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=5 SRCH
base="ou=Users,dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(|(mail=sergio.ferreira@...)(mailAlternateAddress=sergio.f
erreira@...)))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=5 SRCH attr=mail
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=5 SEARCH RESULT tag=101 err=0
nentries=0 text=
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=6 SRCH
base="ou=Users,dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(|(mail=@...)(mailAlternateAddress=@...)))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=6 SRCH attr=mail
Nov 22 17:37:02 gaia slapd[2677]: conn=1385 op=6 SEARCH RESULT tag=101 err=0
nentries=0 text=
Nov 22 17:37:02 gaia postfix/cleanup[12984]: BB1B94C097:
message-id=<20051122193702.BB1B94C097@localhost>
Nov 22 17:37:02 gaia postfix/qmgr[12980]: BB1B94C097: from=<>, size=2682,
nrcpt=1 (queue active)
Nov 22 17:37:02 gaia slapd[2677]: conn=1382 op=6 SRCH
base="ou=Users,dc=cultura,dc=gov,dc=br" scope=2 deref=0
filter="(&(|(mail=minc.gov.br)(mailAlternateAddress=minc.gov.br)))"
Nov 22 17:37:02 gaia slapd[2677]: conn=1382 op=6 SRCH attr=mail
Nov 22 17:37:02 gaia slapd[2677]: conn=1382 op=6 SEARCH RESULT tag=101 err=0
nentries=0 text=
Nov 22 17:37:02 gaia postfix/qmgr[12980]: AB4204C095: removed
Nov 22 17:37:03 gaia postfix/smtp[12988]: BB1B94C097:
to=<sergio.ferreira@...>, relay=mx1.minc.gov.br[200.198.204.69],
delay=1, status=sent (250 Requested mail action okay, completed.)
Nov 22 17:37:03 gaia postfix/qmgr[12980]: BB1B94C097: removed
Nov 22 17:37:12 gaia postfix/smtpd[12982]: rewrite stream disconnect
Nov 22 17:37:12 gaia postfix/smtpd[12982]: watchdog_stop: 0x806a7e0
Nov 22 17:37:12 gaia postfix/smtpd[12982]: watchdog_start: 0x806a7e0


Thanks,

Sergio


>>>>>--
>>>>>Ralf Hildebrandt (Ralf.Hildebrandt@...)
>>>>>spamtrap@...
>>>>>Postfix - Einrichtung, Betrieb und Wartung       Tel. +49
>>>>>(0)30-450 570-155
>>>>>http://www.postfix-buch.com
>>>>>Given the opacity of the product, how could a Windows
>>>>>admin ever know as much about Windows as a UNIX admin does
>>>>>about UNIX?! (Roger B. A.
>>>>>Klorese on Postfix Mailing List)

* S?rgio Ferreira <sergio.ferreira@...>:
> Hi list,
>
> I need any help with Maildir delivery process. When a message is received It
> isn?t delivered to Maildir, but It is send back to sender and postfix log It
> as success process. See the log below:
>
> Nov 22 16:12:41 gaia postfix/smtp[12696]: 67C304C09C:
> to=<sergio.ferreira@...>, relay=mx1.minc.gov.br[200.198.204.69],
> delay=0,
>
> status=sent (250 Requested mail action okay, completed.)
>
> The message into (brackets) above should be "delivered to maildir" instead
> of (250 .....)

Postfix doesn't work that way. Check your logs to see what happened
with 67C304C09C

Show complete logs for a delivery of a mail that should go to a local
Maildir/

--
Ralf Hildebrandt (Ralf.Hildebrandt@...)          spamtrap@...
Postfix - Einrichtung, Betrieb und Wartung       Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Given the opacity of the product, how could a Windows admin ever know
as much about Windows as a UNIX admin does about UNIX?! (Roger B. A.
Klorese on Postfix Mailing List)

Hi list,

I need any help with Maildir delivery process. When a message is received It
isn´t delivered to Maildir, but It is send back to sender and postfix log It
as success process. See the log below:

Nov 22 16:12:41 gaia postfix/smtp[12696]: 67C304C09C:
to=<sergio.ferreira@...>, relay=mx1.minc.gov.br[200.198.204.69],
delay=0,

status=sent (250 Requested mail action okay, completed.)

The message into (brackets) above should be "delivered to maildir" instead
of (250 .....)

I belive there is an configuration error with Postfix setup. I am guessing,
perhaps with the path of user Maildir. It is stored at LDAP directory in the
"mailMessageStore" attribute (/home/vmail/"username"/Maildir).

My setup involves Postfix + LDAP + Courier IMAP + Courier Maildrop + Virtual
Domains.

I pasted the main.cf below:

myhostname = localhost
mydomain = cultura.gov.br
mynetworks = 10.0.0.0, 127.0.0.0
inet_interfaces = all
alias_maps = ldap:ldapalias
recipient_delimiter = +
virtual_mailbox_base = /
virtual_mailbox_maps = ldap:ldapvirtual
virtual_uid_maps = static:10010
virtual_gid_maps = static:15000
virtual_minimum_uid = 10000
virtual_alias_maps = ldap:ldapalias
virtual_mailbox_domains = $mydomain monumenta.gov.br
ldapvirtual_server_host = $myhostname
ldapvirtual_server_port = 389
ldapvirtual_bind = yes
ldapvirtual_bind_dn = cn=admin,dc=cultura,dc=gov,dc=br
ldapvirtual_bind_pw = temppass
ldapvirtual_search_base = ou=Users,dc=cultura,dc=gov,dc=br
ldapvirtual_query_filter = (&(|(mail=%s)(mailAlternateAddress=%s)))
ldapvirtual_result_attribute = mailMessageStore
virtual_alias_domains = $virtual_alias_maps
virtual_maps = ldap:ldapalias
ldapalias_server_host = $myhostname
ldapalias_server_port = 389
ldapalias_bind = yes
ldapalias_bind_dn = cn=replica,dc=cultura,dc=gov,dc=br
ldapalias_bind_pw = temppass
ldapalias_search_base = ou=Users,dc=cultura,dc=gov,dc=br
ldapalias_query_filter = (&(|(mail=%s)(mailAlternateAddress=%s)))
ldapalias_result_attribute = mail
local_recipient_maps = $alias_maps $virtual_mailbox_maps unix:passwd.byname
local_recipient_maps = $alias_maps
home_mailbox = Maildir/
mailbox_command = /usr/bin/maildrop
mailbox_transport = maildrop
fallback_transport = maildrop
virtual_transport = maildrop
maildrop_destination_recipient_limit = 1

and master.cf:


smtp      inet  n       -       -       -       -       smtpd -v
pickup    fifo  n       -       -       60      1       pickup -v
cleanup   unix  n       -       -       -       0       cleanup -v
qmgr      fifo  n       -       -       300     1       qmgr -v
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce -v
defer     unix  -       -       -       -       0       bounce -v
trace     unix  -       -       -       -       0       bounce -v
verify    unix  -       -       -       -       1       verify -v
flush     unix  n       -       -       1000?   0       flush -v
proxymap  unix  -       -       n       -       -       proxymap -v
smtp      unix  -       -       -       -       -       smtp -v
relay     unix  -       -       -       -       -       smtp -v
showq     unix  n       -       -       -       -       showq -v
error     unix  -       -       -       -       -       error -v
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
maildrop  unix  -       n       n       -       -       pipe -v
   flags=DRhu user=mailadmin argv=/usr/bin/maildrop -d ${user}@${nexthop}
${extension} ${recipient} ${user} ${nexthop}
uucp      unix  -       n       n       -       -       pipe
   flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
ifmail    unix  -       n       n       -       -       pipe
   flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
   flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender
$recipient
scalemail-backend unix  -       n       n       -       2       pipe
   flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
${nexthop} ${user} ${extension}


Thanks,

Sergio

Nathanael Hoyle a écrit :
>
> If you would please note, I used the bottom end network boundary, not
> the top-end broadcast address.  To my understanding, this would be
> accurate in describing broadcast address behavior, but not network
> boundary address behavier. Would this in fact still apply for, for
> intance the .0 address in a class C?
>

- We live in CIDR. so remote client don't care.
- broadcast and network addresses are valid (try a ping). so as Wietse
says, packets will timeout, unless one of your routers returns an error.

Sérgio Ferreira a écrit :
> Hi Mouss,
>
> I ran Maildrop -V 9 -d .....
>
> This is what I found in tmp.out
>
> HOME=/home/data/sergio.ferreira/Maildir/,
> MAILDIR=/home/data/sergio.ferreira/Maildir/
>

I meant send a message via postfix and look at the above. My feeling is
that it has to do with trusted_users.

Nathanael Hoyle a écrit :
>
> The IP is a network boundary address.  i.e., if it were a class C
> network (/24). the address would be x.x.x.0, rather than 1-254 or
> broadcast (255).  Because this IP refers to the *network* rather than a
> host therein, it cannot actually be assigned to a host.  This means I
> both avoid wasting an otherwise usable IP, and have no worries that
> something might ever be assigned that IP which would interact in an
> undersired manner with mail delivery attempts.  In my particular case
> (which you can find out from the MX records anyhow):
>
> MX 10 nosoupforyou.speedexpress.net
> MX 100 mail.speedexpress.net
>
> nosoupforyou.speedexpress.net A 66.142.28.32
> mail.speedexpress.net  A 66.142.28.50
>
> The 66.142.28.32 address is the network boundary for 66.142.28.32/28
> (255.255.255.240 subnet, with .33 as the first usable IP).
>
>
>> the advantage I see is that the connect
>>
>>
>>>attempt will fail notably faster than it would if it had to time out,
>>>which reduces the burden on legitimate hosts, but is still just as
>>>undeliverable, keeping the desired effect.  I will post with further
>>>results as I have the opportunity to observe them.
>>>
>>
>
>

The remote system has no idea how your network is subnetted. so the
failure will mostly be caused by a routing error (no route to host)
generated in your network. A tcp rst (generated by an existing host)
would be as fast. I think the advantage is in resource usage (no need to
go through an ip filter or a tcp stack) in addition to what you said
above (no need to use a real host's IP).

Nathanael Hoyle:
> >>The IP is a network boundary address.  i.e., if it were a class C
> >>network (/24). the address would be x.x.x.0, rather than 1-254 or
> >>broadcast (255).  Because this IP refers to the *network* rather than a
> >>host therein, it cannot actually be assigned to a host.  This means I
> >
> >
> > Oh yes it can.
> >
> > Your broadcast address is meaningful only for hosts on your subnet.
> >
> > Your broadcast address has no meaning for hosts on other subnets.
> >
> > Assign your broadcast address to an MX host record, and clients will
> > experience TCP timeout waits just as if they connect to a host that
> > is turned off.
> >
> >  Wietse
>
> If you would please note, I used the bottom end network boundary, not
> the top-end broadcast address.  To my understanding, this would be
> accurate in describing broadcast address behavior, but not network
> boundary address behavier. Would this in fact still apply for, for
> intance the .0 address in a class C?

It does not matter.

The all-bits-0 (old broadcast) and all-bits-1 broadcast address
have meaning only for hosts on your own subnet.

The all-bits-0 (old broadcast) and all-bits-1 broadcast address
have no meaning for hosts on other subnets.

Assigning either of these to an MX host record means that clients
will experience TCP timeout waits just as if they connect to a host
that is turned off.

	 Wietse

On Tue, 22 Nov 2005 17:01:00 -0200
Sérgio Ferreira <sergio.ferreira@...> wrote:

> Hi list,
>
> I need any help with Maildir delivery process. When a message is received It
> isn´t delivered to Maildir, but It is send back to sender and postfix log It
> as success process. See the log below:
>
> Nov 22 16:12:41 gaia postfix/smtp[12696]: 67C304C09C:
> to=<sergio.ferreira@...>, relay=mx1.minc.gov.br[200.198.204.69],
> delay=0,
>
> status=sent (250 Requested mail action okay, completed.)
>
> The message into (brackets) above should be "delivered to maildir" instead
> of (250 .....)
>
> I belive there is an configuration error with Postfix setup. I am guessing,
> perhaps with the path of user Maildir. It is stored at LDAP directory in the
> "mailMessageStore" attribute (/home/vmail/"username"/Maildir).
>


Try /home/vmail/"username"/Maildir/   - note the final '/'.


--
Due to excessive spam as a result of archiving of this list I only accept mail
through the list server.

Wietse Venema wrote:
> Nathanael Hoyle:
>
>>mouss wrote:
>>
>>>Nathanael Hoyle a ?crit :
>>>
>>>
>>>>I liked Jorey's idea enough to give it a shot.  Actually implemented it
>>>>yesterday.  I debated about having the 'dead' MX host point at a system
>>>>which dropped the requests but logged them (via iptables or similar),
>>>>not so much to see how much legitimate email made it through (which
>>>>seems to be pretty much all of it so far), but to see how much nasty
>>>>traffic hit the primary 'dead' host that failed to retry on the second.
>>>> For now, I have gone with a somewhat different approach.  I actually
>>>>have the primary MX listed as an IP that is a network boundary (and
>>>>therefore flatly unusable),
>>>
>>>what do you mean here?
>>
>>The IP is a network boundary address.  i.e., if it were a class C
>>network (/24). the address would be x.x.x.0, rather than 1-254 or
>>broadcast (255).  Because this IP refers to the *network* rather than a
>>host therein, it cannot actually be assigned to a host.  This means I
>
>
> Oh yes it can.
>
> Your broadcast address is meaningful only for hosts on your subnet.
>
> Your broadcast address has no meaning for hosts on other subnets.
>
> Assign your broadcast address to an MX host record, and clients will
> experience TCP timeout waits just as if they connect to a host that
> is turned off.
>
>  Wietse

If you would please note, I used the bottom end network boundary, not
the top-end broadcast address.  To my understanding, this would be
accurate in describing broadcast address behavior, but not network
boundary address behavier. Would this in fact still apply for, for
intance the .0 address in a class C?

--
Nathanael Hoyle
Systems and Networking
Speed Express Networks, LLC
nhoyle@...
432.837.2811

Nathanael Hoyle:
> mouss wrote:
> > Nathanael Hoyle a ?crit :
> >
> >>
> >> I liked Jorey's idea enough to give it a shot.  Actually implemented it
> >> yesterday.  I debated about having the 'dead' MX host point at a system
> >> which dropped the requests but logged them (via iptables or similar),
> >> not so much to see how much legitimate email made it through (which
> >> seems to be pretty much all of it so far), but to see how much nasty
> >> traffic hit the primary 'dead' host that failed to retry on the second.
> >>  For now, I have gone with a somewhat different approach.  I actually
> >> have the primary MX listed as an IP that is a network boundary (and
> >> therefore flatly unusable),
> >
> > what do you mean here?
>
> The IP is a network boundary address.  i.e., if it were a class C
> network (/24). the address would be x.x.x.0, rather than 1-254 or
> broadcast (255).  Because this IP refers to the *network* rather than a
> host therein, it cannot actually be assigned to a host.  This means I

Oh yes it can.

Your broadcast address is meaningful only for hosts on your subnet.

Your broadcast address has no meaning for hosts on other subnets.

Assign your broadcast address to an MX host record, and clients will
experience TCP timeout waits just as if they connect to a host that
is turned off.

	 Wietse

Jon Miller a écrit :
> I've noticed in the mail log that there are a lot of bounced e-mails.  My
question is it good practice these days to have a system bounce the mail or drop
the mail seeing that it's possible that the bounce mail is being sent from a
spammer.  Doesn't this just notify the spammer(s) that this is a valid server
running, just the name is not accepted.  Or is there a better way of handling
this?


spam is generally sent with a forged sender address. bouncing it results
in backscatter. see the backscatter readme.

Try to reject instead of bounce. in particular, implement recipient
validation correctly. Also, don't configure your spam filter to bounce.
   tag and deliver or quarantine.

mouss wrote:
> Nathanael Hoyle a écrit :
>
>>
>> I liked Jorey's idea enough to give it a shot.  Actually implemented it
>> yesterday.  I debated about having the 'dead' MX host point at a system
>> which dropped the requests but logged them (via iptables or similar),
>> not so much to see how much legitimate email made it through (which
>> seems to be pretty much all of it so far), but to see how much nasty
>> traffic hit the primary 'dead' host that failed to retry on the second.
>>  For now, I have gone with a somewhat different approach.  I actually
>> have the primary MX listed as an IP that is a network boundary (and
>> therefore flatly unusable),
>
>
> what do you mean here?

The IP is a network boundary address.  i.e., if it were a class C
network (/24). the address would be x.x.x.0, rather than 1-254 or
broadcast (255).  Because this IP refers to the *network* rather than a
host therein, it cannot actually be assigned to a host.  This means I
both avoid wasting an otherwise usable IP, and have no worries that
something might ever be assigned that IP which would interact in an
undersired manner with mail delivery attempts.  In my particular case
(which you can find out from the MX records anyhow):

MX 10 nosoupforyou.speedexpress.net
MX 100 mail.speedexpress.net

nosoupforyou.speedexpress.net A 66.142.28.32
mail.speedexpress.net  A 66.142.28.50

The 66.142.28.32 address is the network boundary for 66.142.28.32/28
(255.255.255.240 subnet, with .33 as the first usable IP).

>
>  the advantage I see is that the connect
>
>> attempt will fail notably faster than it would if it had to time out,
>> which reduces the burden on legitimate hosts, but is still just as
>> undeliverable, keeping the desired effect.  I will post with further
>> results as I have the opportunity to observe them.
>>
>


--
Nathanael Hoyle
Systems and Networking
Speed Express Networks, LLC
nhoyle@...
432.837.2811

Nathanael Hoyle wrote:

>  For now, I have gone with a somewhat different approach.  I actually
> have the primary MX listed as an IP that is a network boundary (and
> therefore flatly unusable), the advantage I see is that the connect
> attempt will fail notably faster than it would if it had to time out,
> which reduces the burden on legitimate hosts, but is still just as
> undeliverable, keeping the desired effect.  I will post with further
> results as I have the opportunity to observe them.

I'm using a host that has no A record (NXDOMAIN) as the dead primary in
some of my configurations. While it applies less of a penalty, it isn't
RFC-compliant, so I'm not strongly recommending it:

RFC 2181, 10.3. MX and NS records:

    This domain name must have as its value one or more address records.

It's conceivable that someone would filter on this criteria (although I
think it would be misguided, as long as there was a valid MX in the
list). Many people filter on the presence of bogons, so avoid using
these at all costs. Network boundary addresses come dangerously close to
   being easily identified as invalid, so be cautious with this approach.

Wietse offered this advice in an earlier exchange:

"If you're concerned about listing a primary MX record without valid
A record, you could instead supply an IP address that immediately
returns a TCP RESET. This could be done with a packet filter rule,
or by giving a machine a second external IP address without an SMTP
listener on it."

Using a packet filter offers the opportunity for logging.

Nathanael Hoyle a écrit :
>
> I liked Jorey's idea enough to give it a shot.  Actually implemented it
> yesterday.  I debated about having the 'dead' MX host point at a system
> which dropped the requests but logged them (via iptables or similar),
> not so much to see how much legitimate email made it through (which
> seems to be pretty much all of it so far), but to see how much nasty
> traffic hit the primary 'dead' host that failed to retry on the second.
>  For now, I have gone with a somewhat different approach.  I actually
> have the primary MX listed as an IP that is a network boundary (and
> therefore flatly unusable),

what do you mean here?

   the advantage I see is that the connect
> attempt will fail notably faster than it would if it had to time out,
> which reduces the burden on legitimate hosts, but is still just as
> undeliverable, keeping the desired effect.  I will post with further
> results as I have the opportunity to observe them.
>