Re: Prevent vacation autoreply for recipient_delimiter?

[mouss]

post...@corwyn.net a écrit :
> At 01:57 PM 2/21/2009, mouss wrote:
>> post...@corwyn.net a écrit :
>> Alternatively, change your delivery config so that mail to
>> *+s...@yourdomain.example uses a different delivery mechanism, one that
>> doesn't call your vacation script.
> 
> See, I knew there'd be a way in postfix. Can you provide a quick pointer
> to how to do that; I'm not quite sure where to start. I changed the
> delivery agent to dovecot previously, but I know that postfix feeds
> things back through vacation somehow, and if I could just change that
> I'd be all set!
> 



to select the delivery agent, you can use transport_maps

transport_maps =
...
pcre:/etc/postfix/transport.pcre

transport.pcre:

/\+s...@example\.com$/  somelda:

where somelda is a delivery agent that does not call your vacation.pl.

Forward a copy of each mail to another smtp-server

[Kai Szymanski]

Hi!

Because i have to move from one server to another one (new hardware and
new provider) with all domains, i also have to move all emailaccounts to
the new server. Because i wan't to move "step by step" i have to think
about synchronisation of the email-accounts. My prefered way would be to
forward a copy of each incoming mail (old server) to the new server by smtp.

Is there a way to do so with postfix ?

Thanks a lot!

Best regards,
  Kai.

Re: Prevent vacation autoreply for recipient_delimiter?

[Charles Marcus]

On 2/21/2009, post...@corwyn.net (post...@corwyn.net) wrote:
> I think our thought process is different. I have a technical thing I
> want to do (and understand in postfix).  So it depends on how you
> define things as a problem.

Fair enough, but the email subject and problem description were, why is
the vacation mail getting sent twice.

Hmmm... I have a question for you... I had assumed it was being sent
twice everytime... but is it only being sent twice for messages TO a
recipient that contained the delimiter?

-- 

Best regards,

Charles

mail from restriction

[Meshbah Uddin Ahmed]

hi,

i am using postfix. i want to restrict my users that they cannot send mail
using other domain. Like my domain is- abc.com, nobody of my users can send
mail using yahoo.com/gmail com. but have to receive mail from other domains.

is it possible, if so how, pls help.

Regards-
Meshbah

Re: Forward a copy of each mail to another smtp-server

[mouss]

Kai Szymanski a écrit :
> Hi!
> 
> Because i have to move from one server to another one (new hardware and
> new provider) with all domains, i also have to move all emailaccounts to
> the new server. Because i wan't to move "step by step" i have to think
> about synchronisation of the email-accounts.

why not "share" the same "backend"?

> My prefered way would be to
> forward a copy of each incoming mail (old server) to the new server by smtp.
> 
> Is there a way to do so with postfix ?
> 


http://www.postfix.org/postconf.5.html#recipient_bcc_maps

use a pcre map. search the archives for more details.

Re: mail from restriction

[mouss]

Meshbah Uddin Ahmed a écrit :
> hi,
> 
> i am using postfix. i want to restrict my users that they cannot send
> mail using other domain. Like my domain is- abc.com ,
> nobody of my users can send mail using yahoo.com/gmail
>  com. but have to receive mail from other domains.
> 
> is it possible, if so how, pls help.

define "my users"? are they sending mail from mynetworks? do they
authenticated? ...

anyway, the following will prevent them from using a sender in "another"
domain unless mail is "local" (delivered to one of your domains):

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/mydomains
reject_unauth_destination

== mydomains
mydomain1.example   OK
mydomain2.example   OK

dovecot_destination_recipient_limit not appearing in postconf -n ?

[postfix]

I'm using dovecot as:
virtual_transport = dovecot
and have:
dovecot_destination_recipient_limit =1
in main.cf

However, when I run postconf -n the
dovecot_destination_recipient_limit =1
value doesn't appear (and neither does my 
vacation_destination_recipient_limit =1 for that matter, hmm).


(This appears to be what's causing my problem with my vacation.pl 
code from the "Prevent vacation autoreply for recipient_delimiter?"  thread)


I've tested to make sure i'm using the correct main.cf (it's the only 
one on the system, and changes to it are reflecting in the config 
when I reload). I've tried moving 
dovecot_destination_recipient_limit  to the last line of the config. 
All to no avail.


Any insights?

postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
bounce_queue_lifetime = 3d
bounce_size_limit = 5
bounce_template_file = /etc/postfix/bounce.cf
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisd-new:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
default_rbl_reply = $rbl_code Service unavailable; $rbl_class 
[$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}

delay_warning_time = 4h
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = /var/www/html/postfix
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 3d
message_size_limit = 3072
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = localhost $myhostname
mydomain = example.com
myhostname = email.example.com
myorigin = domain2.example.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
recipient_delimiter = +
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
show_user_unknown_table_name = no
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_loglevel = 2
smtp_use_tls = yes
smtpd_client_connection_rate_limit = 30
smtpd_client_restrictions =
smtpd_data_restrictions = reject_multi_recipient_bounce
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient 
reject_non_fqdn_sender reject_unknown_sender_domain permit_mynetworks 
permit_sasl_authenticated check_client_access 
hash:/etc/postfix/agencies reject_unauth_destination 
check_client_access hash:/etc/postfix/access check_helo_access 
pcre:/etc/postfix/helo_checks reject_rbl_client zen.spamhaus.org 
reject_rbl_client dnsbl.sorbs.net reject_rbl_client bl.spamcop.net 
reject_rbl_client cbl.abuseat.org

smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = reject_unknown_sender_domain 
check_sender_access hash:/etc/postfix/access

smtpd_tls_cert_file = /etc/httpd/certs/email_example_com.crt
smtpd_tls_key_file = /etc/httpd/certs/email.example.com.key.no.password
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_domains =
virtual_alias_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf
virtual_gid_maps = static:105
virtual_mailbox_base = /var/spool/mail
virtual_mailbox_domains = 
proxy:mysql:/etc/postfix/sql/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = 
proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf

virtual_transport = dovecot
virtual_uid_maps = static:1015


And, since those recipient_limit files relate to master.cf
smtp  inet  n   -   n   -   -   smtpd
pickupfifo  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
tlsmgrunix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verifyunix  -   -   n   -   1   verify
flush unix  n   -   n   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp  unix  -   -   n   -   -   smtp
relay unix  -   -   n   -   -   smtp
-o smtp_fallback_relay=
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
retry unix  -   -   n   -   -   error
discard   unix  -   -   n   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   - 

Re: dovecot_destination_recipient_limit not appearing in postconf -n ?

[Wietse Venema]

The postconf command does not read master.cf, therefore parameters
such as "transport"_destination_recipient_limit parameters usually
don't appear in postconf output.

Wietse

Re: postfix, cannot receive email.

[/dev/rob0]

On Fri February 20 2009 23:25:31 Sahil Tandon wrote:
> On Sat, 21 Feb 2009, post...@yeah.net wrote:
> > Feb 21 11:33:21 server2 postfix/smtpd[18192]: connect from
> > rv-out-0708.google.com[209.85.198.244] Feb 21 11:35:03 server2
> > postfix/smtpd[18192]: lost connection after CONNECT from
> > rv-out-0708.google.com[209.85.198.244] Feb 21 11:35:03 server2
> > postfix/smtpd[18192]: disconnect from
> > rv-out-0708.google.com[209.85.198.244]
>
> That's it?  See "related" between "show" and "logs".

If that's ALL the logging, it suggests a lower-level networking issue, 
like possibly a misconfigured upstream router. Check the router 
documentation and troubleshoot the networking.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Question regarding this mailing list & privacy.

[KLaM Postmaster]

Is this mailing list closed (or fairly closed), I only ask because if it
is then there does not seem to any good reason to munge addresses,
domain names etc.
If it open (that is publicly readable) then there is.

TIA

JLA

Re: Question regarding this mailing list & privacy.

[Mark Goodge]

KLaM Postmaster wrote:

Is this mailing list closed (or fairly closed), I only ask because if it
is then there does not seem to any good reason to munge addresses,
domain names etc.
If it open (that is publicly readable) then there is.


It's publicly archived in a number of places, and posts here will show 
up in a Google search. These are some of the archives, I'm sure there 
are others:


http://archives.neohapsis.com/archives/postfix
http://www.mail-archive.com/postfix-users@postfix.org
http://www.pubbs.net/postfix
http://tech.groups.yahoo.com/group/postfix-users

Mark
--
http://mark.goodge.co.uk

Re: Question regarding this mailing list & privacy.

[KLaM Postmaster]

Mark Goodge wrote:
> KLaM Postmaster wrote:
>> Is this mailing list closed (or fairly closed), I only ask because if it
>> is then there does not seem to any good reason to munge addresses,
>> domain names etc.
>> If it open (that is publicly readable) then there is.
>
> It's publicly archived in a number of places, and posts here will show
> up in a Google search. These are some of the archives, I'm sure there
> are others:
>
> http://archives.neohapsis.com/archives/postfix
> http://www.mail-archive.com/postfix-users@postfix.org
> http://www.pubbs.net/postfix
> http://tech.groups.yahoo.com/group/postfix-users
>
> Mark
Thanks, looks like I have to keep munging. Now I need to either develop
or find a good munging script.

JLA

Re: Question regarding this mailing list & privacy.

[/dev/rob0]

On Sun February 22 2009 16:05:09 KLaM Postmaster wrote:
> Is this mailing list closed (or fairly closed), I only ask because if
> it is then there does not seem to any good reason to munge addresses,
> domain names etc.
> If it open (that is publicly readable) then there is.

http://www.google.com/search?q=klam+postmaster+%22postfix-users%22
should have your answer.

Note: munging individual email addresses is often a good idea because  
of spam harvesters. Munging domain names is generally a BAD idea, 
especially if the problem concerns mail routing or other features which 
depend on domain names.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Question regarding this mailing list & privacy.

[mouss]

KLaM Postmaster a écrit :
> Mark Goodge wrote:
>> KLaM Postmaster wrote:
>>> Is this mailing list closed (or fairly closed), I only ask because if it
>>> is then there does not seem to any good reason to munge addresses,
>>> domain names etc.
>>> If it open (that is publicly readable) then there is.
>> It's publicly archived in a number of places, and posts here will show
>> up in a Google search. These are some of the archives, I'm sure there
>> are others:
>>
>> http://archives.neohapsis.com/archives/postfix
>> http://www.mail-archive.com/postfix-users@postfix.org
>> http://www.pubbs.net/postfix
>> http://tech.groups.yahoo.com/group/postfix-users
>>
>> Mark
> Thanks, looks like I have to keep munging. Now I need to either develop
> or find a good munging script.
> 

note that you can't munge infos that are added after you post. for example:

Received: from mail.klam.ca (mail.klam.ca [206.53.59.9])
...

when you munge, use "standard" example conventions:

- for domains, use *.example.com, *.example.org, *.example.net or *.example.
- for routable IPs, use 192.0.2.*
- for private IPs, use one of the private IP classes (10.* should be
enough...)

And do that consistently. for example, don't replace "netoyen.net" with
"example.net" but at the same time replace "mo...@netoyen.net" with
"j...@bar.example", because this hides the fact that this user is from
that domain... etc.

Re: Question regarding this mailing list & privacy.

[KLaM Postmaster]

mouss wrote:
> KLaM Postmaster a écrit :
>   
>> Mark Goodge wrote:
>> 
>>> KLaM Postmaster wrote:
>>>   
 Is this mailing list closed (or fairly closed), I only ask because if it
 is then there does not seem to any good reason to munge addresses,
 domain names etc.
 If it open (that is publicly readable) then there is.
 
>>> It's publicly archived in a number of places, and posts here will show
>>> up in a Google search. These are some of the archives, I'm sure there
>>> are others:
>>>
>>> http://archives.neohapsis.com/archives/postfix
>>> http://www.mail-archive.com/postfix-users@postfix.org
>>> http://www.pubbs.net/postfix
>>> http://tech.groups.yahoo.com/group/postfix-users
>>>
>>> Mark
>>>   
>> Thanks, looks like I have to keep munging. Now I need to either develop
>> or find a good munging script.
>>
>> 
>
> note that you can't munge infos that are added after you post. for example:
>
> Received: from mail.klam.ca (mail.klam.ca [206.53.59.9])
>   
Mmmm, you noticed. That one slipped by me!
> ...
>
> when you munge, use "standard" example conventions:
>
> - for domains, use *.example.com, *.example.org, *.example.net or *.example.
> - for routable IPs, use 192.0.2.*
> - for private IPs, use one of the private IP classes (10.* should be
> enough...)
>
> And do that consistently. for example, don't replace "netoyen.net" with
> "example.net" but at the same time replace "mo...@netoyen.net" with
> "j...@bar.example", because this hides the fact that this user is from
> that domain... etc.
>   
Thanks for the tips, as you have probably worked out by now I need all
the help I can get.

Once again
Thanks
JLA

Mail forwarding based on from address

[Islam, Towhid]

Perhaps this question has been asked before, if so, my apology.  Is it possible 
for postfix to forward mail based on a from address, as in received from a 
certain address or domain?  Thanks.

T Islam
Detroit Media Partnership

Re: Mail forwarding based on from address

[Sahil Tandon]

On Sun, 22 Feb 2009, Islam, Towhid wrote:

> Perhaps this question has been asked before, if so, my apology.  Is it
> possible for postfix to forward mail based on a from address, as in
> received from a certain address or domain?  Thanks.

http://www.postfix.org/postconf.5.html#check_sender_access
http://www.postfix.org/access.5.html (look specifically for the "REDIRECT"
action).

-- 
Sahil Tandon 

Re: Question regarding this mailing list & privacy.

[KLaM Postmaster]

/dev/rob0 wrote:
> On Sun February 22 2009 16:05:09 KLaM Postmaster wrote:
>   
>> Is this mailing list closed (or fairly closed), I only ask because if
>> it is then there does not seem to any good reason to munge addresses,
>> domain names etc.
>> If it open (that is publicly readable) then there is.
>> 
>
> http://www.google.com/search?q=klam+postmaster+%22postfix-users%22
> should have your answer.
>
> Note: munging individual email addresses is often a good idea because  
> of spam harvesters. Munging domain names is generally a BAD idea, 
> especially if the problem concerns mail routing or other features which 
> depend on domain names.
>   
Its amazing just how large a footprint one leaves.
What you say makes sense. After all, if I am posting from the domain
that I am asking questions about it does not take a genius to work out
the "whatever.com" is probably the same domain as my email address. It
also makes it a little easier to thwart the address harvester as
provided I am consistent (provided?) then addresses used in posts can be
added to a block list.
Which makes munging, both easier and harder at the same time, less needs
doing but I need to be more accurate/thorough.

Thanks
JLA