date:20090209

David Cottle wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have got RBL tests and I got a client on godaddy. Naturally their
outgoing server (secureserver.net) is listed. I made changes to postfix
but its still rejecting, here is the extract of the main.cf and the rules.

I don't understand why its not working.. If I remove all the rbl checks
the emails arrive..

Any ideas?

Here is the configs that apply:

smtpd_client_restrictions = check_client_access
hash:/etc/postfix/whitelist,

OK.

check_client_access
hash:/etc/postfix/check_backscatterer, check_client_access
hash:/etc/postfix/check_spamcannibal,

The above two checks will never match anything. You need to
use check_sender_access, not check_client_access.

Make sure you leave the default setting of
smtpd_delay_reject = yes
so postfix knows the sender when it does this check.

reject_rbl_client bl.spamcop.net,

OK.

reject_rbl_client pbl.spamhaus.org, reject_rbl_client
sbl-xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org,

You should drop all the above and use zen.spamhaus.org.
If you want to differentiate rejections, you can break them
out by the reject code.

reject_rbl_client dnsbl-1.uceprotect.net, reject_rbl_client
dnsbl-2.uceprotect.net, reject_rbl_client dnsbl-3.uceprotect.net,

UCEPROTECT will give you tons of false positives when used
this way. Better to use it in a scoring type system, such as
SpamAssassin or a scoring policy server. Or just don't use it
at all. Here, it gave so many false positives that it wasn't
even particularly useful for scoring.

reject_rbl_client 2.0.0.127.b.barracudacentral.org

This will never match anything. Must be
reject_rbl_client b.barracudacentral.org

if you're trying to limit rejects to a specific response code,
the syntax is

reject_rbl_client b.barracudacentral.org=127.0.0.2

the /etc/postfix/whitelist file (yes its been mapped to .cf)

k2smtpout01-01.prod.mesa1.secureserver.net OK
k2smtpout02-01.prod.mesa1.secureserver.net OK
k2smtpout03-01.prod.mesa1.secureserver.net OK
k2smtpout04-01.prod.mesa1.secureserver.net OK
k2smtpout05-01.prod.mesa1.secureserver.net OK
k2smtpout06-01.prod.mesa1.secureserver.net OK

you need only one entry.

prod.mesa1.secureserver.net OK

If you've changed the default setting of
parent_domain_matches_subdomains then use

.prod.mesa1.secureserver.net OK

http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains
http://www.postfix.org/access.5.html

But whitelisting by name only works if postfix knows the
client name.

Feb 9 09:36:55 server postfix/smtpd[26671]: connect from unknown[64.202.189.90]
Feb 8 22:36:57 server postfix/smtpd[26671]: NOQUEUE: reject: RCPT from unknown[64.202.189.90]:
554 5.7.1 Service unavailable; Client host [64.202.189.90] blocked using dnsbl-1.uceprotect.net;
IP 64.202.189.90 is UCEPROTECT-Level 1 listed. See
http://www.uceprotect.net/rblcheck.php?ipr=64.202.189.90;
from=psa...@server.aussiefrogs.com to=dcot...@idb.com.au proto=SMTP
helo=k2smtpout02-01.prod.mesa1.secureserver.net
Feb 8 22:36:57 server postfix/smtpd[26671]: disconnect from unknown[64.202.189.90]

Ah, postfix does not know the client name. You'll need to
whitelist them by IP address.

Hmmm.
% host 64.202.189.90
90.189.202.64.in-addr.arpa domain name pointer
k2smtpout02-01.prod.mesa1.secureserver.net.

% host k2smtpout02-01.prod.mesa1.secureserver.net.
k2smtpout02-01.prod.mesa1.secureserver.net has address
64.202.189.90

Looks as if your DNS is broken. If you DNS had been working,
I don't believe this would have been labeled unknown.

Does postfix label every client as unknown?

the check_backscatterer (also mapped)

reject_rbl_client ips.backscatterer.org
postmaster reject_rbl_client ips.backscatterer.org
MAILER-DAEMON reject_rbl_client ips.backscatterer.org

The postmaster and MAILER-DAEMON entries are unlikely to match
anything; remember you're checking the envelope sender, not a
header. I suppose some broken mailers could use the sender
postmas...@example.com or mailer-dae...@example.com; you would
need a regexp map to match those, and you won't see many of
them. Ditto for your spamcannibal map.

--
Noel Jones

Re: reject_unverified_sender vs greylisting

2009-02-09 Thread João Miguel Neves

Charles Marcus escreveu:
 On 2/8/2009, João Miguel Neves (joao.ne...@intraneia.com) wrote:
   
 I recently enabled reject_unverified_sender in my postfix configuration,
 but it seems like it fails when the server against which the sender is
 verified uses greylisting. I've been getting log entries like (@ were
 replaced by _AT_):
 

 You're not trying to verify ALL senders are you? This ia a really bad
 idea, and will get you blacklisted by a lot of providers, especially if
 you have high traffic .
   
Yes, I was. Thanks for the heads up. I don't have high traffic, but I'm
limiting the effect of SAV.
 You should only perform SAV against servers that YOU control, or at
 least have an agreement ahead of time with them.
   
That would mean that the most useful use of SAV is negated. Or is there
some prior arrangement that would allow me to do that to hotmail.com,
gmail.com, yahoo.com*?

I'm going to reduce the target domains, but is there a known agreement
with MS, Google or Yahoo to use SAV against their servers?

Thanks in advance,
João Miguel Neves

-- 
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Delaying some email addresses

2009-02-09 Thread João Miguel Neves

Good morning,

I'm using spamassassin thru amavisd. I also have a bunch of spamtraps
(addresses that were never used by persons, but that receive spam
regularly) feeding automatically its bayes filter. Sometimes I get some
spam that goes to regular addresses and to the spamtraps around the same
time. Is there a way or, what is the correct way of delaying some addresses?

Best regards,
João Miguel Neves

-- 
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: reject_unverified_sender vs greylisting

2009-02-09 Thread Charles Marcus

On 2/9/2009 9:36 AM, João Miguel Neves wrote:
 That would mean that the most useful use of SAV is negated. Or is there
 some prior arrangement that would allow me to do that to hotmail.com,
 gmail.com, yahoo.com*?
 
 I'm going to reduce the target domains, but is there a known agreement
 with MS, Google or Yahoo to use SAV against their servers?

No...

Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts

-- 

Best regards,

Charles

Re: Delaying some email addresses

2009-02-09 Thread Martin Schmitt

João Miguel Neves schrieb:

 I'm using spamassassin thru amavisd. I also have a bunch of spamtraps
 (addresses that were never used by persons, but that receive spam
 regularly) feeding automatically its bayes filter. Sometimes I get some
 spam that goes to regular addresses and to the spamtraps around the same
 time. Is there a way or, what is the correct way of delaying some addresses?

You might use greylisting and exclude your spamtrap addresses from it.

-martin

-- 
Martin Schmitt / Schmitt Systemberatung / www.scsy.de
-- http://www.pug.org/index.php/Benutzer:Martin --



signature.asc
Description: OpenPGP digital signature

Re: Delaying some email addresses

2009-02-09 Thread João Miguel Neves

Martin Schmitt escreveu:
 João Miguel Neves schrieb:

   
 I'm using spamassassin thru amavisd. I also have a bunch of spamtraps
 (addresses that were never used by persons, but that receive spam
 regularly) feeding automatically its bayes filter. Sometimes I get some
 spam that goes to regular addresses and to the spamtraps around the same
 time. Is there a way or, what is the correct way of delaying some addresses?
 

 You might use greylisting and exclude your spamtrap addresses from it.

 -martin
   
I'd like to avoid greylisting if possible (I've measured delays of over
an hour, thanks to the retry times), but that's always a possibility.

Thanks in advance,
João Miguel Neves

-- 
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: Delaying some email addresses

On Mon, Feb 09, 2009 at 02:44:09PM +, Jo?o Miguel Neves wrote:

 Good morning,
 
 I'm using spamassassin thru amavisd. I also have a bunch of spamtraps
 (addresses that were never used by persons, but that receive spam
 regularly) feeding automatically its bayes filter. Sometimes I get some
 spam that goes to regular addresses and to the spamtraps around the same
 time. Is there a way or, what is the correct way of delaying some addresses?
 

Don't delay, if your spamtrap addresses are well chosen, have
never existed as valid email addresses, and are unlikely to be mistyped
accidentally by a human sender, you can just REDIRECT all mail for
a spamtrap address to that same spamtrap address, this drops all the
other recipients.

-- 
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:majord...@postfix.org?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.

Re: Delaying some email addresses


João Miguel Neves wrote:

Martin Schmitt escreveu:

João Miguel Neves schrieb:

  

I'm using spamassassin thru amavisd. I also have a bunch of spamtraps
(addresses that were never used by persons, but that receive spam
regularly) feeding automatically its bayes filter. Sometimes I get some
spam that goes to regular addresses and to the spamtraps around the same
time. Is there a way or, what is the correct way of delaying some addresses?


You might use greylisting and exclude your spamtrap addresses from it.

-martin
  

I'd like to avoid greylisting if possible (I've measured delays of over
an hour, thanks to the retry times), but that's always a possibility.

Thanks in advance,
João Miguel Neves



Some other choices...

- Use a check_recipient_access table that returns HOLD for the 
spamtrap address; HOLD affects all recipients of the message.
You can then use postcat to examine the message, and 
postsuper to either release or delete it.  Use this if 
occasional ham is sent to the spamtrap address.


- Use a check_recipient_access table that returns REDIRECT to 
send the message to some other address; REDIRECT affects all 
recipients of a message.  Use this if these are clean 
spamtraps that get 100% spam.


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

--
Noel Jones

Re: Delaying some email addresses

2009-02-09 Thread Terry Carmen


Victor Duchovni wrote:

On Mon, Feb 09, 2009 at 02:44:09PM +, Jo?o Miguel Neves wrote:

  

Good morning,

I'm using spamassassin thru amavisd. I also have a bunch of spamtraps
(addresses that were never used by persons, but that receive spam
regularly) feeding automatically its bayes filter. Sometimes I get some
spam that goes to regular addresses and to the spamtraps around the same
time. Is there a way or, what is the correct way of delaying some addresses?




Don't delay, if your spamtrap addresses are well chosen, have
never existed as valid email addresses, and are unlikely to be mistyped
accidentally by a human sender, you can just REDIRECT all mail for
a spamtrap address to that same spamtrap address, this drops all the
other recipients.
  


Does this mean that if a single message has multiple recipients, and one 
of the recipients is spamt...@mydomain, that the message will only be 
delivered to spamt...@mydomain?


Terry

Re: Delaying some email addresses

On Mon, Feb 09, 2009 at 12:00:12PM -0500, Terry Carmen wrote:

 Don't delay, if your spamtrap addresses are well chosen, have
 never existed as valid email addresses, and are unlikely to be mistyped
 accidentally by a human sender, you can just REDIRECT all mail for
 a spamtrap address to that same spamtrap address, this drops all the
 other recipients.
   

 Does this mean that if a single message has multiple recipients, and one of 
 the recipients is spamt...@mydomain, that the message will only be 
 delivered to spamt...@mydomain?

Yes. A lot of spam is sent to one recipient at a time, so this won't
solve your spam problem, but there is no point in delivering spam trap
messages to additional users when that does happen.

-- 
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:majord...@postfix.org?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.

Building postfix for packaging

2009-02-09 Thread Quanah Gibson-Mount

We currently use postfix as a part of our overall product, which means that 
it ends up being packaged inside our own RPM (or deb, etc) packages, and 
then redeployed when our product is installed.  One thing I've noticed 
about the postfix build system in this is that it assumes you are building 
postfix specifically to be run on the box you're building it on, which in 
what we are doing is not really the case.


As a part of all this, we also allow people to check out and build the FOSS 
edition of our product.  To make it easier on those who want to do this, 
I'm trying to make it so they can build postfix as whatever user they want, 
since our own install process takes care of setting up permission, etc, for 
postfix.  However, the postfix-install script doesn't seem to have a 
concept of this, which makes it somewhat annoying to use, as I have to 
essentially patch around it.  Of the numerous software applications we 
build as the underlying components to our product, Postfix is the only one 
that goes to such pains.  Is there a way that I'm missing to turn off this 
behavior in postfix-install besides patching it to turn off its checks?


Thanks,
Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Building postfix for packaging

2009-02-09 Thread Wietse Venema

Quanah Gibson-Mount:
 We currently use postfix as a part of our overall product, which means that 
 it ends up being packaged inside our own RPM (or deb, etc) packages, and 
 then redeployed when our product is installed.  One thing I've noticed 
 about the postfix build system in this is that it assumes you are building 
 postfix specifically to be run on the box you're building it on, which in 
 what we are doing is not really the case.

The Postfix build procedure assumes that the build machine is
representative for the environment where the software will be used.
For example, it builds FreeBSD binaries on FreeBSD not on Solaris.

 As a part of all this, we also allow people to check out and build the FOSS 
 edition of our product.  To make it easier on those who want to do this, 
 I'm trying to make it so they can build postfix as whatever user they want, 
 since our own install process takes care of setting up permission, etc, for 
 postfix.  However, the postfix-install script doesn't seem to have a 
 concept of this, which makes it somewhat annoying to use, as I have to 
 essentially patch around it.

The postfix build and install procedures have documented processes
to set up file locations, as well file and directory permissions
and ownerships.  

If the documented processes are inadequate, then perhaps you could
share specific information. Postfix is a more complex system than
the average UNIX app, and I am notoriously bad at guessing people's
thoughts.

Wietse

Re: Building postfix for packaging

On Mon, Feb 09, 2009 at 09:41:49AM -0800, Quanah Gibson-Mount wrote:

 We currently use postfix as a part of our overall product, which means that 
 it ends up being packaged inside our own RPM (or deb, etc) packages, and 
 then redeployed when our product is installed.  One thing I've noticed 
 about the postfix build system in this is that it assumes you are building 
 postfix specifically to be run on the box you're building it on, which in 
 what we are doing is not really the case.

Please explain what you mean by this.

 As a part of all this, we also allow people to check out and build the FOSS 
 edition of our product.  To make it easier on those who want to do this, 
 I'm trying to make it so they can build postfix as whatever user they want, 
 since our own install process takes care of setting up permission, etc, for 
 postfix.

I build and install (for deployment to other systems) Postfix as viktor
all the time.

http://www.postfix.org/PACKAGE_README.html

The only thing that requires root is actually making postdrop and
postqueue setgid as $setdig_group, this is a post-install step.

 However, the postfix-install script doesn't seem to have a 
 concept of this, which makes it somewhat annoying to use, as I have to 
 essentially patch around it.

You have not read PACKAGE_README.

 Of the numerous software applications we 
 build as the underlying components to our product, Postfix is the only one 
 that goes to such pains.  Is there a way that I'm missing to turn off this 
 behavior in postfix-install besides patching it to turn off its checks?

What checks are you objecting to? When I install for packaging, I run:

sh ./postfix-install -non-interactive install_root=$iroot \
config_directory=${INSTALL_EXEC_PREFIX}/etc \
command_directory=${INSTALL_EXEC_PREFIX}/sbin  \
data_directory=${BUILD}/data \
daemon_directory=${INSTALL_EXEC_PREFIX}/libexec  \
manpage_directory=${INSTALL_PREFIX}/man  \
queue_directory=${BUILD}/spool \
readme_directory=${INSTALL_PREFIX}/readme  \
sample_directory=${INSTALL_PREFIX}/sample  \
html_directory=${INSTALL_PREFIX}/html  \
mailq_path=${INSTALL_EXEC_PREFIX}/sbin/mailq  \
newaliases_path=${INSTALL_EXEC_PREFIX}/sbin/newaliases  \
sendmail_path=${INSTALL_EXEC_PREFIX}/sbin/sendmail

This delivers all the files to the (desired by me) locations with no fuss.

-- 
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:majord...@postfix.org?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.

Re: Building postfix for packaging

2009-02-09 Thread Quanah Gibson-Mount

--On Monday, February 09, 2009 12:57 PM -0500 Victor Duchovni 
victor.ducho...@morganstanley.com wrote:





Of the numerous software applications we
build as the underlying components to our product, Postfix is the only
one  that goes to such pains.  Is there a way that I'm missing to turn
off this  behavior in postfix-install besides patching it to turn off
its checks?





You have not read PACKAGE_README.



This is really the answer.  I missed this document, things should work fine 
with it.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Building postfix for packaging

2009-02-09 Thread Terry Carmen


Quanah Gibson-Mount wrote:
We currently use postfix as a part of our overall product, which means 
that it ends up being packaged inside our own RPM (or deb, etc) 
packages, and then redeployed when our product is installed. One thing 
I've noticed about the postfix build system in this is that it assumes 
you are building postfix specifically to be run on the box you're 
building it on, which in what we are doing is not really the case.


As a part of all this, we also allow people to check out and build the 
FOSS edition of our product. To make it easier on those who want to do 
this, I'm trying to make it so they can build postfix as whatever user 
they want, since our own install process takes care of setting up 
permission, etc, for postfix. However, the postfix-install script 
doesn't seem to have a concept of this, which makes it somewhat 
annoying to use, as I have to essentially patch around it. Of the 
numerous software applications we build as the underlying components 
to our product, Postfix is the only one that goes to such pains. Is 
there a way that I'm missing to turn off this behavior in 
postfix-install besides patching it to turn off its checks?

Have you considered allowing the use of an existing instance of Postfix?

Many people tend to not consider packages that require and ship with 
their own versions of externally maintained packages.


Terry

Re: Building postfix for packaging

On Mon, Feb 09, 2009 at 10:02:33AM -0800, Quanah Gibson-Mount wrote:

 You have not read PACKAGE_README.

 This is really the answer.  I missed this document, things should work fine 
 with it.

One minor nit in the document, it uses xargs to collect a file list for
tar, but the file list may be too long for one command invocation:

% cd INSTALL_ROOT
% rm -f SOMEWHERE/outputfile
% find . \! -type d -print | xargs tar cf SOMEWHERE/outputfile
% gzip SOMEWHERE/outputfile 

With tar c, only the last batch of files are in the tar archive. The
command should be tar rf not tar cf.

-- 
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:majord...@postfix.org?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.

Re: Building postfix for packaging

On Mon, Feb 09, 2009 at 01:17:08PM -0500, Victor Duchovni wrote:

 On Mon, Feb 09, 2009 at 10:02:33AM -0800, Quanah Gibson-Mount wrote:
 
  You have not read PACKAGE_README.
 
  This is really the answer.  I missed this document, things should work fine 
  with it.
 
 One minor nit in the document, it uses xargs to collect a file list for
 tar, but the file list may be too long for one command invocation:
 
 % cd INSTALL_ROOT
 % rm -f SOMEWHERE/outputfile
 % find . \! -type d -print | xargs tar cf SOMEWHERE/outputfile
 % gzip SOMEWHERE/outputfile 
 
 With tar c, only the last batch of files are in the tar archive. The
 command should be tar rf not tar cf.

Of course you can build packages more sophisticatd than tar, and in that
case you can use the postfix-files file to determine which files in
the install_root to include in the package, and what metadata to assign
to those files (including which files need to preserve user-modified
copies, ...). The tar variant is just an example, in practice, on
most platforms, you do something more sophisiticated.

-- 
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:majord...@postfix.org?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.

Re: Building postfix for packaging

2009-02-09 Thread Wietse Venema

Victor Duchovni:
 On Mon, Feb 09, 2009 at 10:02:33AM -0800, Quanah Gibson-Mount wrote:
 
  You have not read PACKAGE_README.
 
  This is really the answer.  I missed this document, things should work fine 
  with it.
 
 One minor nit in the document, it uses xargs to collect a file list for
 tar, but the file list may be too long for one command invocation:
 
 % cd INSTALL_ROOT
 % rm -f SOMEWHERE/outputfile
 % find . \! -type d -print | xargs tar cf SOMEWHERE/outputfile
 % gzip SOMEWHERE/outputfile 
 
 With tar c, only the last batch of files are in the tar archive. The
 command should be tar rf not tar cf.

On what systems does the list exceed the NCARGS command length limit?

Wietse

RE: Problems with Postfix / Round-Robin

2009-02-09 Thread Pablo Scheri


Hi! thanks for the help and sorry for the delay.
I don´t know if i am able to send attachments, I will try.

I am attaching you the maillog, master.cf and main.cf

Thanks again.

Pablo.-

 Subject: Re: Problems with Postfix / Round-Robin
 To: postfix-users@postfix.org
 Date: Fri, 6 Feb 2009 12:53:29 -0500
 From: wie...@porcupine.org
 
 Pablo Scheri:
  
  dig mx trendargentina.com.ar.
 
 Looks good...
 
  postconf | grep dns
  
  disable_dns_lookups = no
  lmtp_host_lookup = dns
  smtp_host_lookup = dns
 
 It's using DNS
 
  ---
  grep '10\.0\.0\.20..:25' /var/log/maillog | grep -v status=
  
  No result.
 
 OK so this was supposed to match
 
   [10.0.0.207]:25 without status=
   [10.0.0.208]:25 without status=
 
 (that's why there were two dots in the pattern).
 
 If there are no such records, then the Postfix SMTP client 
 does not connect to one box after having tried the other first.
 
 To find out why random DNS is not working, we need verbose logging
 
 # postconf -e debug_peer_list=10.0.0.207 debug_peer_level=1
 
   Wietse

_
El doble de diversión: con Windows Live Messenger compartí fotos mientras 
charlas.
http://www.microsoft.com/windows/windowslive/messenger.aspx

Re: Redirect all mail from one domain to the same u...@otherdomain?

2009-02-09 Thread jeff_homeip

--- In postfix-us...@yahoogroups.com, Victor Duchovni
victor.ducho...@... wrote:

 On Sun, Feb 08, 2009 at 09:50:16PM -0800, Jeff Weinberger wrote:

 
  I am trying to figure out the best way to map one domain to
another with
  the same users...precisely the behavior I am trying to achieve is:
when
  mail is sent (from outside, or from another user within my postfix
  installation) to u...@... I want it redirected to u...@...
  - in otherwords, the user is preserved, but the domain is
  translated/rewritten. To be more specific:
 
  us...@... gets re-routed to us...@...
  us...@... gets re-routed to us...@...

 - Are you looking to rewrite just the envelope recipient, or also
message
   From/To/Cc headers?

It's only important to rewrite the envelope sender. The result I want
is that the message is delivered to *...@domain2.tld - if it has the
original To/Cc header that's fine, and probably desireable.


 - Is all mail first passed through an SMTP content_filter?

Yes. All mail coming from outside my server is passed through
amavisd-new for spam/virus checking. Mail originating from my server
is passed through a specialized content filter. (via the submission
service)

It is important that this rewrite apply to messages coming from
outside as well as those originating on my server.


 - Are all the original and rewritten recipients delivered to another
host
   via SMTP, or is some of the mail delivered locally (local,
virtual, ...)?

I'm not completely sure this answers your question, but the message
may be only to u...@domain1.tld or to a number of addresses including
u...@domain1.tld. Only the copy of the message to u...@domain1.tld
should get rerouted to u...@domain2.tld.

both domain1.tld and domain2.tld are mine and my postfix instance is
the MX for them. domain1.tld is an alias domain and domain2.tld is a
virtual domain.



 
  My initial guess is to use recipient_canonical_maps and use a pcre
map:
 
  /^(.*)@domain1.tld/   {$1)@domain2.tld

 This guess is wrong for many reasons, but I think it best to first
 understand what problem you are really trying to solve, before we
 tear apart the wrong answer to potentially the wrong question.

Thank you...but I would also like to know if I can impose on your
time, what is wrong with this - it will help me better solve this and
future problems.


  I don't see a way to achieve this with alias_maps and
header_checks (with
  action REDIRECT) would miss messages sent to u...@... where that is
  not the To: or Cc: address (such as list mail).

 This is worse.

That I understood. Thanks.


  Really, I am just checking with experts more knowledgeable than I
whether I
  have chosen a good (or the best) way to achieve this, or if there
is a
  better way.

 Yes, there is a correct way of solving your problem, but first describe
 your problem in more detail.

Does that help? Please let me know if there is any more detail I can
provide.

Thank you for your help!




 --
   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:majord...@...?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.

Re: Building postfix for packaging

On Mon, Feb 09, 2009 at 02:13:55PM -0500, Wietse Venema wrote:

  
  One minor nit in the document, it uses xargs to collect a file list for
  tar, but the file list may be too long for one command invocation:
  
  % cd INSTALL_ROOT
  % rm -f SOMEWHERE/outputfile
  % find . \! -type d -print | xargs tar cf SOMEWHERE/outputfile
  % gzip SOMEWHERE/outputfile 
  
  With tar c, only the last batch of files are in the tar archive. The
  command should be tar rf not tar cf.
 
 On what systems does the list exceed the NCARGS command length limit?

xargs(1) does not use NCARGS, rather it uses various smaller limits:

(
exec 2/dev/null
for i in 1 10 100 1000
do
printf -- --- %d ---\n $i
yes $(printf %0${i}d 0) | head -n1 | wc
yes $(printf %0${i}d 0) | head -n1 | 
xargs echo 2/dev/null | head -1 | wc
done
)

RHEL 3.0: ~24k input buffer:

--- 1 ---
  1   1   2
  110242048
--- 10 ---
  1   1  11
  11024   11264
--- 100 ---
  1   1 101
  1 238   24038
--- 1000 ---
  1   11001
  1  24   24024

RHEL 4.0: ~24k input buffer

--- 1 ---
  1   1   2
  110242048
--- 10 ---
  1   1  11
  11024   11264
--- 100 ---
  1   1 101
  1 252   25452
--- 1000 ---
  1   11001
  1  25   25025

SunOS 5.8: ~2k input buffer

--- 1 ---
   1   1   2
   1 254 508
--- 10 ---
   1   1  11
   1 1852035
--- 100 ---
   1   1 101
   1  202020
--- 1000 ---
   1   11001
   1   22002

-- 
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:majord...@postfix.org?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.

Re: Building postfix for packaging

On Mon, Feb 09, 2009 at 02:59:02PM -0500, Victor Duchovni wrote:

 On Mon, Feb 09, 2009 at 02:13:55PM -0500, Wietse Venema wrote:
 
   
   One minor nit in the document, it uses xargs to collect a file list for
   tar, but the file list may be too long for one command invocation:
   
   % cd INSTALL_ROOT
   % rm -f SOMEWHERE/outputfile
   % find . \! -type d -print | xargs tar cf SOMEWHERE/outputfile
   % gzip SOMEWHERE/outputfile 
   
   With tar c, only the last batch of files are in the tar archive. The
   command should be tar rf not tar cf.
  
  On what systems does the list exceed the NCARGS command length limit?
 
 xargs(1) does not use NCARGS, rather it uses various smaller limits:
 

More specifically, on SunOS 5.8 and 5.10, the standard /usr/bin/xargs uses 6
invocations to process all the installed Postfix files in a tree of
the form:

$ find .exec common -type d -print
.exec/
.exec/x86_64.sunos64.5.10/
.exec/x86_64.sunos64.5.10/etc/
.exec/x86_64.sunos64.5.10/libexec/
.exec/x86_64.sunos64.5.10/sbin/
common/
common/html/
common/man/
common/man/man1/
common/man/man5/
common/man/man8/
common/readme/

With files in the various directories above.

-- 
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:majord...@postfix.org?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.

Re: Building postfix for packaging

On Mon, Feb 09, 2009 at 12:19:26PM -0800, Quanah Gibson-Mount wrote:

 --On Monday, February 09, 2009 12:57 PM -0500 Victor Duchovni 
 victor.ducho...@morganstanley.com wrote:

 http://www.postfix.org/PACKAGE_README.html

 And just to confirm, the steps here worked beautifully, thank you. :)

 I did have to use an install root of /../ since it won't take /.  I build 
 with a prefix of /opt/zimbra/postfix-version already, so it kept 
 installing into /opt/zimbra/postfix-version/opt/zimbra/postfix-version 
 and /opt/zimbra/postfix-version/opt/zimbra/data/spool/postfix.

 It would be nice if there was someway for it to recognize it was already 
 built with a prefix, so no need to go down multiple layers.  But I have an 
 easily working solution to it. :)

This is easily solved with symbolic links:

$ ln -s / /some/where/.root
postfix-install  install_root=/some/where/.root ...

Also, you can use custom installation parameters when installing,
and them postconf -e to updat them back to the correct paths.

postfix-install ... \
config_directory=/etc \
command_directory=/sbin \
html_directory=/html \
...

This will put everything directly under the install-root. The resulting
main.cf will record these installation parameters, so you update them with
postconf -c /some/where/ -e  after the install. Update both the
config_directory and daemon_directory copies to put back the compile-time
defaults for all the parameters.

In any case, main.cf installation is a tricky business, since you MUST
not clobber existing main.cf files from users, and potentially need to
support installation into user-selected $command_directory, ... taking
all the locations from the existing main.cf. The only thing the user
can't move is the default config_directory (/etc/postfix in may cases).

-- 
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:majord...@postfix.org?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.

Re: Building postfix for packaging

2009-02-09 Thread Wietse Venema

Quanah Gibson-Mount:
 --On Monday, February 09, 2009 12:57 PM -0500 Victor Duchovni 
 victor.ducho...@morganstanley.com wrote:
 
  http://www.postfix.org/PACKAGE_README.html
 
 And just to confirm, the steps here worked beautifully, thank you. :)
 
 I did have to use an install root of /../ since it won't take /.  I build 
 with a prefix of /opt/zimbra/postfix-version already, so it kept 
 installing into /opt/zimbra/postfix-version/opt/zimbra/postfix-version 
 and /opt/zimbra/postfix-version/opt/zimbra/data/spool/postfix.
 
 It would be nice if there was someway for it to recognize it was already 
 built with a prefix, so no need to go down multiple layers.  But I have an 
 easily working solution to it. :)

It's good to hear that the instructions are still (mostly) correct.
This was released in 2002 and there have plenty of opportunities
for bit-rot to creep in.

Wietse

Re: Building postfix for packaging

2009-02-09 Thread Quanah Gibson-Mount

--On Monday, February 09, 2009 12:57 PM -0500 Victor Duchovni 
victor.ducho...@morganstanley.com wrote:



http://www.postfix.org/PACKAGE_README.html


And just to confirm, the steps here worked beautifully, thank you. :)

I did have to use an install root of /../ since it won't take /.  I build 
with a prefix of /opt/zimbra/postfix-version already, so it kept 
installing into /opt/zimbra/postfix-version/opt/zimbra/postfix-version 
and /opt/zimbra/postfix-version/opt/zimbra/data/spool/postfix.


It would be nice if there was someway for it to recognize it was already 
built with a prefix, so no need to go down multiple layers.  But I have an 
easily working solution to it. :)


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Replacing Message-Id for SASL authenticated senders

Marc Patermann a écrit :
 Hi,
 
 Bastian Blank schrieb:
 On Sun, Feb 08, 2009 at 03:38:22AM -0500, Sahil Tandon wrote:
 This works as I'd expect, but will it break anything else?

 Yes. It will break the complete mail handling of the client. _Never_
 ever touch a message id.
 Not all users are dumb. ;)
 
 Sender:I'm missing your response, didn't you get my mail?
 Recipient: Can you tell me the message-id?
 Sender: Yes, *looks it up in Sent-folder* it is
 012...@domain.tld.
 Recipient: One Moment please, *searches his mailbox* no, it's not
 here ...
 
 Just one of the cases you might break what user would expect.
 

This case is a bit artificial. People would search for the recipient
and the subject. and even if they find the message in the Sent folder,
it doesn't help much. MTA logs are more helpful.

The real problem is breaking threads. so more testing is needed.

anyway, my opinion (at this time, as I didn't yet find a sufficient
counter argument) is that the message-id should be generated by the MSA:
- it is easier to guarantee unicity, because in general, MSAs know their
public hostname
- it is easier to guarantee well-formed Message-IDs. MUAs (and I am
including web applications and the like) have a habit of implementing
broken behaviour
- it simplifies the MUA task. admins would (some day:) spend less time
configure the many MUAs in their network (there are obviously fewer MSAs).

note that I am not using hide internal infos or ease backscatter
detection as arguments, even though these look interesting to customers.

Re: Building postfix for packaging

On Mon, Feb 09, 2009 at 03:41:34PM -0500, Wietse Venema wrote:

  It would be nice if there was someway for it to recognize it was already 
  built with a prefix, so no need to go down multiple layers.  But I have an 
  easily working solution to it. :)
 
 It's good to hear that the instructions are still (mostly) correct.
 This was released in 2002 and there have plenty of opportunities
 for bit-rot to creep in.

I do nearly 100 package builds a year (various snapshot releases and
occasional official patches) on multiple variants of SunOS and Linux.
The build process has not changed dramatically since ~2.0. The core
install_root + config parameters interface is still the same.

If the old package interface broke, I would have noticed.

Even with multi-instance support coming in 2.6, the basics won't change.
Just don't forget to run:

# postfix set-permissions upgrade-configuration

when upgrading a system with an existing configuration.

-- 
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:majord...@postfix.org?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.

Re: Delaying some email addresses

Victor Duchovni a écrit :
 On Mon, Feb 09, 2009 at 12:00:12PM -0500, Terry Carmen wrote:
 
 Don't delay, if your spamtrap addresses are well chosen, have
 never existed as valid email addresses, and are unlikely to be mistyped
 accidentally by a human sender, you can just REDIRECT all mail for
 a spamtrap address to that same spamtrap address, this drops all the
 other recipients.
   
 Does this mean that if a single message has multiple recipients, and one of 
 the recipients is spamt...@mydomain, that the message will only be 
 delivered to spamt...@mydomain?
 
 Yes. A lot of spam is sent to one recipient at a time, so this won't
 solve your spam problem, but there is no point in delivering spam trap
 messages to additional users when that does happen.
 

What I use is do a PREPEND in postfix and a rule in spamassassin. (if SA
is not used, one can use an MDA rule).

The advantage is that this works even when the traps are disabled (I
only enable them from time to time).

I tried 421 (when the traps are disabled) but abandoned it.

Re: Redirect all mail from one domain to the same u...@otherdomain?

jeff_homeip a écrit :
 --- In postfix-us...@yahoogroups.com, Victor Duchovni
 victor.ducho...@... wrote:
 On Sun, Feb 08, 2009 at 09:50:16PM -0800, Jeff Weinberger wrote:

 I am trying to figure out the best way to map one domain to
 another with 
 the same users...precisely the behavior I am trying to achieve is:
 when 
 mail is sent (from outside, or from another user within my postfix 
 installation) to u...@... I want it redirected to u...@... 
 - in otherwords, the user is preserved, but the domain is 
 translated/rewritten. To be more specific:

 us...@... gets re-routed to us...@...
 us...@... gets re-routed to us...@...
 - Are you looking to rewrite just the envelope recipient, or also
 message
   From/To/Cc headers?
 
 It's only important to rewrite the envelope sender. 

you mean the envelope recipient. if so, use virtual_alias_maps. however,
don't use wildcard virtual aliases. instead, generate one mapping for
each user:

us...@example.com   us...@example.org
...


The reason is that if you use
@example.com@example.org
then this breaks recipient validation: smtpd will accept
anything^example.com, then at delivery time, the user won't be found and
a bounce will be generated. in short, you become a source of backscatter
(you send bounces to innocents whose addresses were forged by spammers)

you can generate the individual mappings with a script. alternatively,
if you store users in sql, you can use sql statements to generate these
on the fly. examples have been posted multiple times to the list (a
long time ago, that said, but you may be lucky...).


 The result I want
 is that the message is delivered to *...@domain2.tld - if it has the
 original To/Cc header that's fine, and probably desireable.
 

so you want virtual_alias_maps (yes, these apply to _all_ domains. don't
confuse with virtual_alias_domains).

 - Is all mail first passed through an SMTP content_filter?
 
 Yes. All mail coming from outside my server is passed through
 amavisd-new for spam/virus checking. Mail originating from my server
 is passed through a specialized content filter. (via the submission
 service)
 

you must disable rewrite except in one smtpd in a chain. see the FILTER
README (look for no_address_mappings) or amavisd-new README.postfix.

if you don't, then virtual aliases will be expanded twice (before and
after the filter), which may result in duplicate mail (think of a foo
- foo, bar, which becomes foo - foo, foo, bar if expanded twice).

 It is important that this rewrite apply to messages coming from
 outside as well as those originating on my server.
 

virtual_alias_maps apply to all mail.

 - Are all the original and rewritten recipients delivered to another
 host
   via SMTP, or is some of the mail delivered locally (local,
 virtual, ...)?
 
 I'm not completely sure this answers your question, but the message
 may be only to u...@domain1.tld or to a number of addresses including
 u...@domain1.tld. Only the copy of the message to u...@domain1.tld
 should get rerouted to u...@domain2.tld.
 
 both domain1.tld and domain2.tld are mine and my postfix instance is
 the MX for them. domain1.tld is an alias domain and domain2.tld is a
 virtual domain.
 

 My initial guess is to use recipient_canonical_maps and use a pcre
 map:
 /^(.*)@domain1.tld/   {$1)@domain2.tld
 This guess is wrong for many reasons, but I think it best to first
 understand what problem you are really trying to solve, before we
 tear apart the wrong answer to potentially the wrong question.
 
 Thank you...but I would also like to know if I can impose on your
 time, what is wrong with this - it will help me better solve this and
 future problems.
 

see above. wildcard virtual aliases and canonical break recipient
validations.


[snip]

Re: reject_unverified_sender vs greylisting

João Miguel Neves a écrit :
 Charles Marcus escreveu:
 On 2/8/2009, João Miguel Neves (joao.ne...@intraneia.com) wrote:
   
 I recently enabled reject_unverified_sender in my postfix configuration,
 but it seems like it fails when the server against which the sender is
 verified uses greylisting. I've been getting log entries like (@ were
 replaced by _AT_):
 
 You're not trying to verify ALL senders are you? This ia a really bad
 idea, and will get you blacklisted by a lot of providers, especially if
 you have high traffic .
   
 Yes, I was. Thanks for the heads up. I don't have high traffic, but I'm
 limiting the effect of SAV.

and how do you limit it? 71.66.121.221 is listed on zen.spamhaus.org
(via cbl) and spamcop (as well as Barracuda BRBL, SORBS, ... etc). it is
also a residential IP as can be seen from the rDNS (.res.rr.com).


 You should only perform SAV against servers that YOU control, or at
 least have an agreement ahead of time with them.
   
 That would mean that the most useful use of SAV is negated. Or is there
 some prior arrangement that would allow me to do that to hotmail.com,
 gmail.com, yahoo.com*?
 
 I'm going to reduce the target domains, but is there a known agreement
 with MS, Google or Yahoo to use SAV against their servers?
 

No, and it won't help you anyway. spammers can easily use a valid
address. and these domains have too many users that most addresses
you'll test are valid! (did you never see the sorry, this account is
not available when trying to open an account?).

Re: whitelisting not working

2009-02-09 Thread David Cottle

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Noel Jones wrote:
 David Cottle wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 I have got RBL tests and I got a client on godaddy.  Naturally their
 outgoing server (secureserver.net) is listed.  I made changes to
 postfix
 but its still rejecting, here is the extract of the main.cf and the
 rules.

 I don't understand why its not working..  If I remove all the rbl
 checks
 the emails arrive..

 Any ideas?

 Here is the configs that apply:

 smtpd_client_restrictions = check_client_access
 hash:/etc/postfix/whitelist,

 OK.

 check_client_access
 hash:/etc/postfix/check_backscatterer, check_client_access
 hash:/etc/postfix/check_spamcannibal,

 The above two checks will never match anything.  You need to use
 check_sender_access, not check_client_access.

 Make sure you leave the default setting of
 smtpd_delay_reject = yes
 so postfix knows the sender when it does this check.

 reject_rbl_client bl.spamcop.net,

 OK.

 reject_rbl_client pbl.spamhaus.org, reject_rbl_client
 sbl-xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org,

 You should drop all the above and use zen.spamhaus.org.
 If you want to differentiate rejections, you can break them out by
 the reject code.

 reject_rbl_client dnsbl-1.uceprotect.net, reject_rbl_client
 dnsbl-2.uceprotect.net, reject_rbl_client dnsbl-3.uceprotect.net,

 UCEPROTECT will give you tons of false positives when used this
 way.  Better to use it in a scoring type system, such as
 SpamAssassin or a scoring policy server.  Or just don't use it at
 all.  Here, it gave so many false positives that it wasn't even
 particularly useful for scoring.

 reject_rbl_client 2.0.0.127.b.barracudacentral.org

 This will never match anything.  Must be
   reject_rbl_client b.barracudacentral.org

 if you're trying to limit rejects to a specific response code, the
 syntax is
   reject_rbl_client b.barracudacentral.org=127.0.0.2

 the /etc/postfix/whitelist file (yes its been mapped to .cf)

 k2smtpout01-01.prod.mesa1.secureserver.net OK
 k2smtpout02-01.prod.mesa1.secureserver.net OK
 k2smtpout03-01.prod.mesa1.secureserver.net OK
 k2smtpout04-01.prod.mesa1.secureserver.net OK
 k2smtpout05-01.prod.mesa1.secureserver.net OK
 k2smtpout06-01.prod.mesa1.secureserver.net OK

 you need only one entry.

 prod.mesa1.secureserver.net  OK

 If you've changed the default setting of
 parent_domain_matches_subdomains then use

 .prod.mesa1.secureserver.net  OK

 http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains
 http://www.postfix.org/access.5.html

 But whitelisting by name only works if postfix knows the client name.

 Feb  9 09:36:55 server postfix/smtpd[26671]: connect from
 unknown[64.202.189.90]
 Feb  8 22:36:57 server postfix/smtpd[26671]: NOQUEUE: reject: RCPT
 from unknown[64.202.189.90]: 554 5.7.1 Service unavailable; Client
 host [64.202.189.90] blocked using dnsbl-1.uceprotect.net; IP
 64.202.189.90 is UCEPROTECT-Level 1 listed. See
 http://www.uceprotect.net/rblcheck.php?ipr=64.202.189.90;
 from=psa...@server.aussiefrogs.com to=dcot...@idb.com.au
 proto=SMTP helo=k2smtpout02-01.prod.mesa1.secureserver.net
 Feb  8 22:36:57 server postfix/smtpd[26671]: disconnect from
 unknown[64.202.189.90]

 Ah, postfix does not know the client name.  You'll need to whitelist
 them by IP address.

 Hmmm.
 % host 64.202.189.90
 90.189.202.64.in-addr.arpa domain name pointer
 k2smtpout02-01.prod.mesa1.secureserver.net.
 % host k2smtpout02-01.prod.mesa1.secureserver.net.
 k2smtpout02-01.prod.mesa1.secureserver.net has address 64.202.189.90

 Looks as if your DNS is broken.  If you DNS had been working, I
 don't believe this would have been labeled unknown.

 Does postfix label every client as unknown?

 the check_backscatterer (also mapped)

  reject_rbl_client ips.backscatterer.org
 postmaster reject_rbl_client ips.backscatterer.org
 MAILER-DAEMON reject_rbl_client ips.backscatterer.org

 The postmaster and MAILER-DAEMON entries are unlikely to match
 anything; remember you're checking the envelope sender, not a
 header.  I suppose some broken mailers could use the sender
 postmas...@example.com or mailer-dae...@example.com; you would need
 a regexp map to match those, and you won't see many of them.  Ditto
 for your spamcannibal map.


Hi Noel,

Many thanks for your tips!

I have not set smtpd_delay_reject anywhere, so the default value of
yes applies.

As for the check scripts, I changed them as you said,
check_sender_access, not check_client_access:

smtpd_client_restrictions = check_client_access
hash:/etc/postfix/whitelist, check_sender_access
hash:/etc/postfix/check_backscatterer, check_sender_access
hash:/etc/postfix/check_spamcannibal, reject_rbl_client
bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client
cbl.abuseat.org, reject_rbl_client b.barracudacentral.org

I would have used this but in the postfix documentation it never
showed the use of check_sender_access in smtpd_client_restrictions

RE: reject_unverified_sender vs greylisting

2009-02-09 Thread MacShane, Tracy

 -Original Message-
 From: owner-postfix-us...@postfix.org 
 [mailto:owner-postfix-us...@postfix.org] On Behalf Of mouss
 Sent: Tuesday, 10 February 2009 8:39 AM
 To: postfix-users@postfix.org
 Subject: Re: reject_unverified_sender vs greylisting

 João Miguel Neves a écrit :

  Yes, I was. Thanks for the heads up. I don't have high traffic, but 
  I'm limiting the effect of SAV.

 and how do you limit it? 71.66.121.221 is listed on 
 zen.spamhaus.org (via cbl) and spamcop (as well as Barracuda 
 BRBL, SORBS, ... etc). it is also a residential IP as can be 
 seen from the rDNS (.res.rr.com).

My simple solution to this is have a line in a client_access map of res.rr.com 
REJECT Please relay mail via your ISP. I've more recently added biz.rr.com as 
well (and plenty of others). There is just a set of (mainly consumer) domains 
I'm not going to accept mail from. Also, Spamhaus Zen catches these.

Re: whitelisting not working


David Cottle wrote:

smtpd_client_restrictions = check_client_access
hash:/etc/postfix/whitelist, check_sender_access
hash:/etc/postfix/check_backscatterer, check_sender_access
hash:/etc/postfix/check_spamcannibal, reject_rbl_client
bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client
cbl.abuseat.org, reject_rbl_client b.barracudacentral.org

I would have used this but in the postfix documentation it never
showed the use of check_sender_access in smtpd_client_restrictions

So I assume this is correct now?


You were also supposed to remove cbl.abuseat.org; it's 
included in the zen lookup.


One further suggestion - you may want to move your backscatter 
and spamcannibal checks to smtpd_data_restrictions to be 
compatible with the few services that do sender verification 
callbacks.


Other than that, yes, this looks reasonable.



As for the unknown, could selinux be stopping postfix from using the
DNS?  The DNS works as it serves out the DNS for the hosted domains.

Feb  9 22:31:55 server postfix/smtpd[25015]: connect from
unknown[189.6.3.109]

Yet I do a prompt from the server and reverse lookup the IP I get the
name..


SELinux is the usual suspect.  Turn it off and see what 
happens.  If that's not it, the second guess is an incomplete 
chroot jail.


If this doesn't help you get it fixed, start a new message 
thread for the new problem.  Include your postconf -n output 
and logging demonstrating the problem.



--
Noel Jones

virtual_mailbox_domains as a hash file

2009-02-09 Thread Roderick A. Anderson

Everything I'm reading in The Book of Postfix and from the web site 
seem to indicate that virtual_mailbox_domains has to be a list of values 
in main.cf.  Is this correct?  Anyway to put them in a file instead?



TIA,
Rod
--

Re: virtual_mailbox_domains as a hash file


Roderick A. Anderson wrote:
Everything I'm reading in The Book of Postfix and from the web site 
seem to indicate that virtual_mailbox_domains has to be a list of values 
in main.cf.  Is this correct?  Anyway to put them in a file instead?



TIA,
Rod


The documentation is the correct place to check if you have a 
question.


http://www.postfix.org/postconf.5.html#virtual_mailbox_domains
says the syntax is the same as for mydestination.

http://www.postfix.org/postconf.5.html#mydestination
says in part:
Specify a list of host or domain names, /file/name or 
type:table patterns, separated by commas and/or whitespace. 
A /file/name pattern is replaced by its contents; a 
type:table lookup table is matched when a name matches a 
lookup key (the lookup result is ignored). Continue long lines 
by starting the next line with whitespace.


So it looks as if you can use a file just fine.

--
Noel Jones

Re: whitelisting not working

2009-02-09 Thread David Cottle




Sent from my iPhone

On 10/02/2009, at 11:02, Noel Jones njo...@megan.vbhcs.org wrote:


David Cottle wrote:

smtpd_client_restrictions = check_client_access
hash:/etc/postfix/whitelist, check_sender_access
hash:/etc/postfix/check_backscatterer, check_sender_access
hash:/etc/postfix/check_spamcannibal, reject_rbl_client
bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client
cbl.abuseat.org, reject_rbl_client b.barracudacentral.org
I would have used this but in the postfix documentation it never
showed the use of check_sender_access in smtpd_client_restrictions
So I assume this is correct now?


You were also supposed to remove cbl.abuseat.org; it's included in  
the zen lookup.


One further suggestion - you may want to move your backscatter and  
spamcannibal checks to smtpd_data_restrictions to be compatible with  
the few services that do sender verification callbacks.


Other than that, yes, this looks reasonable.


As for the unknown, could selinux be stopping postfix from using the
DNS?  The DNS works as it serves out the DNS for the hosted domains.
Feb  9 22:31:55 server postfix/smtpd[25015]: connect from
unknown[189.6.3.109]
Yet I do a prompt from the server and reverse lookup the IP I get the
name..


SELinux is the usual suspect.  Turn it off and see what happens.  If  
that's not it, the second guess is an incomplete chroot jail.


If this doesn't help you get it fixed, start a new message thread  
for the new problem.  Include your postconf -n output and logging  
demonstrating the problem.



--
Noel Jones


Hi Noel,

Many thanks for your help!

I will pull the cbl.abuseat.org did not know it's in zen - that is a  
comprehensive rbl!


If I move my check_xxx routines to the smtpd_data_restrictions, is  
this still called up as a check_sender_access?


So I also assume that smtpd_data_ restrictions does what it does now  
in smtpd_client_restrictions with the additional sender verification  
callbacks?


Also no need running a whitelist in smptd_data_restrictions as my  
routines only look for , postmaster and MAILER_DAEMON


Thanks again!
David

Re: whitelisting not working


David Cottle wrote:
If I move my check_xxx routines to the smtpd_data_restrictions, is this 
still called up as a check_sender_access?


Yes, it's still using the sender address for the lookup, so it 
still needs to be check_sender_access.




So I also assume that smtpd_data_ restrictions does what it does now in 
smtpd_client_restrictions with the additional sender verification 
callbacks?


No, it just delays that check until the connecting client 
sends the DATA command.  Clients that do sender verification 
will disconnect before they send the DATA command, so they 
will still be able to verify your senders.




Also no need running a whitelist in smptd_data_restrictions as my 
routines only look for , postmaster and MAILER_DAEMON


You may still need a whitelist; just reuse the same one.

--
Noel Jones

Getting localhost put in my From field

2009-02-09 Thread Xn Nooby

I have been trying to figure out how to get Postfix to not append
localhost in to the From: field. I am sending email mostly between
two local users, using RHEL5/Squirrelmail/Postfix/Dovecot.

When I send an email from

  user_...@schoolretail.local

to

  user_...@schoolretail.local

it arrives from

  user_...@localhost.schoolretail.local

I am also relaying mail to another box that expects the mail to not
have localhost appended to the domain name. Users of the other
(Windows) box need to see the address without localhost prepended.

I had a very similar system working with Ubuntu, and I solved this
problem by setting myorigin to a file that contained my domain name
(schoolretail.local), but that doesn't seem to work on the RHEL5
system.

Sorry if this is not a Postfix question!  I just thought myorigin
should set the From address. I must be missing something!


[r...@schoolmail ~]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $mydomain, $myhostname, localhost.$mydomain
mydomain = schoolretail.local
myhostname = schoolmail.schoolretail.local
mynetworks = 127.0.0.0/8
myorigin = schoolretail.local
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
relayhost = 192.168.1.16
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
unknown_local_recipient_reject_code = 550

Re: Getting localhost put in my From field

On Mon, Feb 09, 2009 at 09:43:49PM -0500, Xn Nooby wrote:

 I have been trying to figure out how to get Postfix to not append
 localhost in to the From: field. I am sending email mostly between
 two local users, using RHEL5/Squirrelmail/Postfix/Dovecot.
 
 When I send an email from
 
   user_...@schoolretail.local
 
 to
 
   user_...@schoolretail.local
 
 it arrives from
 
   user_...@localhost.schoolretail.local

What version of Postfix is this? Does the mail ever leave the Postfix
system, or is just delivered to a local mailbox?

Where are the logs for the delivery and the Received headers?

 mydestination = $mydomain, $myhostname, localhost.$mydomain
 mydomain = schoolretail.local
 myhostname = schoolmail.schoolretail.local
 mynetworks = 127.0.0.0/8
 myorigin = schoolretail.local
 relayhost = 192.168.1.16

This should result in a local delivery with no rewriting.

-- 
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:majord...@postfix.org?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.

Re: Redirect all mail from one domain to the same u...@otherdomain?

2009-02-09 Thread jeff_homeip

--- In post...@yahoogroups.com, mouss mo...@... wrote:

 jeff_homeip a écrit :
  --- In postfix-us...@yahoogroups.com, Victor Duchovni
  Victor.Duchovni@ wrote:
  On Sun, Feb 08, 2009 at 09:50:16PM -0800, Jeff Weinberger wrote:
 
  I am trying to figure out the best way to map one domain to
  another with
  the same users...precisely the behavior I am trying to achieve is:
  when
  mail is sent (from outside, or from another user within my postfix
  installation) to user@ I want it redirected to user@
  - in otherwords, the user is preserved, but the domain is
  translated/rewritten. To be more specific:
 
  user1@ gets re-routed to user1@
  user2@ gets re-routed to user2@
  - Are you looking to rewrite just the envelope recipient, or also
  message
From/To/Cc headers?
 
  It's only important to rewrite the envelope sender.

 you mean the envelope recipient.

yes, sorry, my typo.

 if so, use virtual_alias_maps. however,
 don't use wildcard virtual aliases. instead, generate one mapping for
 each user:

 us...@... us...@...
 ...


that creates some complications...and might be too difficult

but why not use wildcard virtual aliases? You noted below that they break 
recipient
validations. Do you mean that smtp_recipient_restrictions won't work? at all or 
parts?

Wildcard virtual aliases seems like the best waybut I want to understand 
the implications
on everything esle before I proceed.

Thanks!


 The reason is that if you use
 @example.com  @example.org
 then this breaks recipient validation: smtpd will accept
 anything^example.com, then at delivery time, the user won't be found and
 a bounce will be generated. in short, you become a source of backscatter
 (you send bounces to innocents whose addresses were forged by spammers)

Unless I don't bounce unknown addresses


 you can generate the individual mappings with a script. alternatively,
 if you store users in sql, you can use sql statements to generate these
 on the fly. examples have been posted multiple times to the list (a
 long time ago, that said, but you may be lucky...).



it would be something like:

if (%d='domain1.com') then select %...@domain2..com from virtual_alias else 
select alias
from virtual_alias where address=%s

(that's not quite right in the syntax, but you get the idea). This wont' work, 
as I'd have to
write a special select clause for each domain I want to work this way.


  The result I want
  is that the message is delivered to *...@domain2.tld - if it has the
  original To/Cc header that's fine, and probably desireable.
 

 so you want virtual_alias_maps (yes, these apply to _all_ domains. don't
 confuse with virtual_alias_domains).

  - Is all mail first passed through an SMTP content_filter?
 
  Yes. All mail coming from outside my server is passed through
  amavisd-new for spam/virus checking. Mail originating from my server
  is passed through a specialized content filter. (via the submission
  service)
 

 you must disable rewrite except in one smtpd in a chain. see the FILTER
 README (look for no_address_mappings) or amavisd-new README.postfix.

 if you don't, then virtual aliases will be expanded twice (before and
 after the filter), which may result in duplicate mail (think of a foo
 - foo, bar, which becomes foo - foo, foo, bar if expanded twice).


I already do that..thanks

  It is important that this rewrite apply to messages coming from
  outside as well as those originating on my server.
 

 virtual_alias_maps apply to all mail.

  - Are all the original and rewritten recipients delivered to another
  host
via SMTP, or is some of the mail delivered locally (local,
  virtual, ...)?
 
  I'm not completely sure this answers your question, but the message
  may be only to u...@... or to a number of addresses including
  u...@... Only the copy of the message to u...@...
  should get rerouted to u...@...
 
  both domain1.tld and domain2.tld are mine and my postfix instance is
  the MX for them. domain1.tld is an alias domain and domain2.tld is a
  virtual domain.
 
 
  My initial guess is to use recipient_canonical_maps and use a pcre
  map:
  /^(.*)@domain1.tld/   {$1)@domain2.tld
  This guess is wrong for many reasons, but I think it best to first
  understand what problem you are really trying to solve, before we
  tear apart the wrong answer to potentially the wrong question.
 
  Thank you...but I would also like to know if I can impose on your
  time, what is wrong with this - it will help me better solve this and
  future problems.
 

 see above. wildcard virtual aliases and canonical break recipient
 validations.


 [snip]

Re: reject_unverified_sender vs greylisting

2009-02-09 Thread Juergen P. Meier

On Mon, Feb 09, 2009 at 02:36:25PM +, João Miguel Neves wrote:
 That would mean that the most useful use of SAV is negated. Or is there
 some prior arrangement that would allow me to do that to hotmail.com,
 gmail.com, yahoo.com*?

Some Mailproviders explicitly forbid the use of SAV against their Mailsystems.
Some others provide false information depending on the SPAM-Filtersettings
of their users, others are just plain broken.

And the Information that some.fake.acco...@hotmail.com is deliverable
has virtually no meaning regarding the SPAM-likelyhood of the incoming
e-Mail. SAV does not verify the authenticity of the sender address.

SAV is a nice idea if run against a limited set of trusted domains (who's
postmasters expclitly allow you to perform these Lookups), but it's not
such a good idea in general.
If everyone would use SAV, the ammount of SMTP traffic in the Internet
would *double*. I bet most heavy duty mailssystems don't scale double.
 
 I'm going to reduce the target domains, but is there a known agreement
 with MS, Google or Yahoo to use SAV against their servers?

Ask their Postmasters/Admins. If they say it's ok, do it.

Re: reject_unverified_sender vs greylisting