Re: Action during SMTPD* checks

[mouss]

KLaM Postmaster a écrit :
> I have just finished reading a bunch of stuff on UCE and the "effects"
> of the various parameters associated with the smtpd_*_restrictions, and
> I am now somewhat confused as two of the authors I have been reading
> state that if a message receives an "OK" from any check then all further
> checks are abandoned. This does not make any sense and I am fairly sure
> that they got it backward but both of them are adamant!
> 
> This is/was my understanding, from reading the documentation and
> elsewhere.If a restriction check was successful (i.e., OK/DUNNO) then
> postfix moves on to the next check, if on the other hand the check was
> unsuccessful then the message is dropped and no further checks are done.
> 

if a check returns OK, then postfix will skip all other checks in the
same smtpd_*_restrictions. if you want to continue to the following
checks, return DUNNO, not OK.

> e.g., if the following is the sequence in main.cf :
> 
> smtpd_xxx_restrictions = reject_non_fdqn_hostname,
> reject_unknown_recipient_domain, reject_non_fdqn_recipient, (permit)
> 
> then if the hostname is a fdqn, then postfix continues on to
> unknown_recipient, and if that is OK moves on to the non-fdqn_recipient
> ... until it runs out of check at which point he default (usually
> permit) is exercised.

reject_* never returns OK. so let's chose a better example:

smtpd_client_restrictions =
check_sender_access hash:/etc/postfix/access_sender
reject_non_fqdn_helo_hostname

if the check_sender_access returns OK, then postfix will move to
smtpd_helo_restrictions. it will skip the reject_non_fqdn_helo_hostname
check.

if the check_sender_access returns REJECT, postfix rejects the
connection and n more checks are performed.

if the check returns DUNNO, postfix continues to
"reject_non_fqnd_helo_hostname".

> if on the other hand the hostname is _not_ a fdqn the message is dropped
> and no further checks are performed under the xxx restrictions.
> Furthermore, if a message is dropped at say the client phase then checks
> in helo and subsequent phases are not performed.
> 

yes.

Re: flush daemon

[punit jain]

  > Don't look under the hood unless you know what you are looking at.

I agree with you Viktor but i am just trying to get a clear picture of
postfix as a novice.

What my concern is what will happen after setting fast_flush_domains to
relay domains  and  flushing the queue say at the time when the remote
domain mentioned in  fast_flush_domain is slow ?

Will preemption of messages take place or will it effect the delivery
process ?




On Mon, Dec 29, 2008 at 11:51 AM, Victor Duchovni <
victor.ducho...@morganstanley.com> wrote:

> On Mon, Dec 29, 2008 at 11:12:57AM +0530, punit jain wrote:
>
> > I  have a question regarding Flush daemon. I have set fast_flush_domains
> to
> > one of my local virtual domain i have hosted.
>
> This is almost never needed. The only domains for which you are likely
> to have a large deferred queue are remotely delivered "relay_domains".
>
> > If i look into flush directory
> > i find domain file with listing of queue files. The problem is i don't
> have
> > any mails in queue directory but still domain file in flush directory
>  shows
> > queue files listing. How to remove these stale entries? Would it mean if
> i
> > run sendmail -qRdomain it will try delivering those queue files which
> would
> > waste CPU cycles ?
>
> - Don't list domains unnecessarily in fast_flush_domains.
>
> - Don't look under the hood unless you know what you are looking at.
>
> The "stale" entries are removed in due course. Keeping the list "fuzzy"
> is more efficient than keeping it accurate at all times.
>
> --
>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:
> 
>
> 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: flush daemon

[Wietse Venema]

punit jain:
>   > Don't look under the hood unless you know what you are looking at.
> 
> I agree with you Viktor but i am just trying to get a clear picture of
> postfix as a novice.
> 
> What my concern is what will happen after setting fast_flush_domains to
> relay domains  and  flushing the queue say at the time when the remote
> domain mentioned in  fast_flush_domain is slow ?

It will not make any difference at all. 

Files in the flush directory are used for "postqueue -s domain" or
"sendmail -qR domain".

> Will preemption of messages take place or will it effect the delivery
> process ?

None of the above.

Do not list local destinations in fast_flush_domains. In fact, it
is a good idea not to change parameters until you have been using
Postfix for a considerable time.

Wietse

Enforcing sending domain from the inside network

[D. Karapiperis]

Hi All


I have a question regarding postfix restrictions.

Is there a way for Postfix to enforce some kind of policy so that all
the outgoing (allowed) mails be " @business.com" and all the others be
rejected.
Of course this policy should be enforced only to the outgoing emails
not in the incoming.




- if mail comes from mynetworks, require that the sender address is
*...@example.com. you can do this with a restriction class based on
check_client_access.


Thanks for the reply

I did this

mynetworks = cidr:/etc/postfix/inside_network

smtpd_restriction_classes=
   from_inside_network

 from_inside_network =
  check_client_access cidr:/etc/postfix/inside_network


smtpd_recipient_restrictions =
check_sender_access hash:/etc/postfix/sending-domains,
reject_unauth_destination



/etc/postfix/inside_network
192.168.2.0/24 OK
127.0.0.0/8   OK


/etc/postfix/sending-domains
business.gr  from_inside_network

So I did a logical AND -> all clients form my network have the relay 
privilege and moreover they can send e-mails only from business.gr 
(hopefully)

I need to test it on a production server.

Re: Reject/Discard mails to a Receipient

[Linux Addict]

Wietse Venema wrote:

Linux Addict:
  

Sahil Tandon wrote:


Linux Addict wrote:

  
  
Hello, I have clients sending mails to an non-existent email  
address/domain, emailerm...@exchange.example.net. I want to discard any  
mail sent to this address. I looked at smtpd_recipient_restrictions, but  
cant figure out how to get this done. Please help me!!



Why not simply reject such messages?  What is the reason you want to
accept but silently discard messages to that non-existent user?  It is
your choice to do so, but please offer some rationale for the archives.

  
  
Sorry.. I wasn't checking my mails for sometime. I am open to Rejecting 
those mails as well..


Well. The mails are sent by one of the legacy app which has the hard 
coded the email address. The email domain has been decommed recently. 
The engineering will update this email address in their next release. 
But till that time, I don't want postfix to spend energy on these mails.


So How will I reject mails to the email in question. Transport will do?



Transport rules such as:

u...@example.com  error:5.1.1 user unknown
example.com   error:5.1.2 domain unknown

will do the job.

Wietse

  

thank you!

Re: Action during SMTPD* checks

[Sahil Tandon]

On Dec 29, 2008, at 12:55 AM, KLaM Postmaster   
wrote:



I have just finished reading a bunch of stuff on UCE and the "effects"
of the various parameters associated with the smtpd_*_restrictions,  
and

I am now somewhat confused as two of the authors I have been reading
state that if a message receives an "OK" from any check then all  
further
checks are abandoned. This does not make any sense and I am fairly  
sure

that they got it backward but both of them are adamant!

This is/was my understanding, from reading the documentation and
elsewhere.If a restriction check was successful (i.e., OK/DUNNO) then
postfix moves on to the next check, if on the other hand the check was
unsuccessful then the message is dropped and no further checks are  
done.


A REJECT will reject the message with no further checking anywhere. An  
OK stops checking within that particular smtpd_mumble_restrictions and  
moves onto the next one, where the message may still be rejected by  
another check.  AFAIK, DUNNO stops processing of a particular access  
table but continues checks within the same mumble restrictions.


--
Sahil Tandon

Re: Enforcing sending domain from the inside network

[Victor Duchovni]

On Mon, Dec 29, 2008 at 03:45:05PM +0200, D. Karapiperis wrote:

> 
> 
> Hi All
> >
> >I have a question regarding postfix restrictions.
> >
> >Is there a way for Postfix to enforce some kind of policy so that all
> >the outgoing (allowed) mails be " @business.com" and all the others be
> >rejected.
> >Of course this policy should be enforced only to the outgoing emails
> >not in the incoming.
> >
> 
> 
> - if mail comes from mynetworks, require that the sender address is
> *...@example.com. you can do this with a restriction class based on
> check_client_access.
> 
> 
> Thanks for the reply
> 
> I did this
> 
> mynetworks = cidr:/etc/postfix/inside_network
> 
> smtpd_restriction_classes=
>from_inside_network
> 
>  from_inside_network =
>   check_client_access cidr:/etc/postfix/inside_network
> 
> 
> smtpd_recipient_restrictions =
> check_sender_access hash:/etc/postfix/sending-domains,
> reject_unauth_destination
> 
> 
> 
> /etc/postfix/inside_network
> 192.168.2.0/24 OK
> 127.0.0.0/8   OK
> 
> 
> /etc/postfix/sending-domains
> business.gr  from_inside_network
> 
> So I did a logical AND -> all clients form my network have the relay 
> privilege and moreover they can send e-mails only from business.gr 
> (hopefully)
> I need to test it on a production server.

THis is really broken, don't do this.

-- 
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:


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: Enforcing sending domain from the inside network

[mouss]

D. Karapiperis a écrit :
> 
> 
> Hi All
>>
>> I have a question regarding postfix restrictions.
>>
>> Is there a way for Postfix to enforce some kind of policy so that all
>> the outgoing (allowed) mails be " @business.com" and all the others be
>> rejected.
>> Of course this policy should be enforced only to the outgoing emails
>> not in the incoming.
>>
> 
> 
> - if mail comes from mynetworks, require that the sender address is
> *...@example.com. you can do this with a restriction class based on
> check_client_access.
> 
> 
> Thanks for the reply
> 
> I did this
> 
> mynetworks = cidr:/etc/postfix/inside_network
> 
> smtpd_restriction_classes=
>from_inside_network
> 
>  from_inside_network =
>   check_client_access cidr:/etc/postfix/inside_network
> 
> 
> smtpd_recipient_restrictions =
> check_sender_access hash:/etc/postfix/sending-domains,
> reject_unauth_destination
> 
> 
> 
> /etc/postfix/inside_network
> 192.168.2.0/24 OK
> 127.0.0.0/8   OK
> 
> 
> /etc/postfix/sending-domains
> business.gr  from_inside_network
> 
> So I did a logical AND -> all clients form my network have the relay
> privilege and moreover they can send e-mails only from business.gr
> (hopefully)

This configuration is:

- ugly because you mix unrelated tasks. blocking relay and enforcing
outbound sender domain are two different tasks. The keywords here are:
clarity, self-documenation, maintenance, etc. some day, you may want to
allow your boss to post with his jackinthebox address, and you will edit
the "sending-domains" table. some day, you may want to allow some other
sender domains. That day, you will lose your hair trying to put ORs
inside your ANDs. De Morgan laws are hard to put in simple key-value maps.

- unsafe because if you or someone else edits sending-domains, you could
become an open relay. oh yes, bad things do happen.

- pointless. it brings nothing compared to what I suggested.


Unless you really know what you are doing and why (and even then, you
should think 3.1415... times [yeah, you'll have to do it until the last
digit of PI ;-p]),
- avoid using check_*_access before reject_unauth_destination
- use smtpd_recipient_restrictions for relay control and spam fighting
- use other restrictions to implement local policy (enforce outbound
sender domain as you want to do, make some addresses "local only", ...
etc).


PS. There is no point to reinvent built-in functionality (your
from_inside_network is exactly permit_mynetworks).


> I need to test it on a production server.
> 
> 
> 

Trying to use uppercase names in Postfix.

[Xn Nooby]

I am using Postfix to replace an existing  email system, and I am
inheriting usernames that are in uppercase. Apparently Postfix
converts all email addresses to lowercase, so I cannot receive mail to
the accounts that are in uppercase. This surprised me, because the
linux user accounts are in uppercase.


After googling around, it looks like I need to use a canonical map,
which I have not been able to get working properly.



I added this to my /etc/postfix/main.cf:

   canonical_maps = dbm:/etc/postfix/canonical


Then I created the /etc/postfix/canonical file:

   sudo vi /etc/postfix/canonical

 jim123 JIM123


Then I generated the map:

   sudo postmap /etc/postfix/canonical


Then restarted postfix:

   sudo /etc/init.d/postfix restart



When I email JIM123, or replay to an email sent by JIM123, it does not
get back to JIM123. Different things happen as I try different
solutions, usually the emails bounce back to the sender. Othertimes
they disappear.

I am mostly curious if my above approach is the correct one. My users
are use to using to the uppercase names, so I would like them to be
able to log in to squirrelmail using uppercase names, and send/receive
emails with uppercase names. I am assuming making the underlying linux
account uppercase is the right thing to do.

Any suggestions? (I'm new to Postfix)

Re: Trying to use uppercase names in Postfix.

[Wietse Venema]

Xn Nooby:
> I am using Postfix to replace an existing  email system, and I am
> inheriting usernames that are in uppercase. Apparently Postfix
> converts all email addresses to lowercase, so I cannot receive mail to
> the accounts that are in uppercase. This surprised me, because the
> linux user accounts are in uppercase.

The local(8) delivery agent always case-folds names to lowercase.
This is currently not configurable. Ditto for the virtual(8) daemon.

It's easy enough to delete the lowercase() call from local(8),
but that would not be a general solution.

The pipe(8) delivery agent has configurable case folding, and that
code would have to be moved into a Postfix library module, so that
it can be used by other Postfix delivery agents.

Wietse

Re: Trying to use uppercase names in Postfix.

[Xn Nooby]

On Mon, Dec 29, 2008 at 3:02 PM, Wietse Venema  wrote:
> Xn Nooby:
>> I am using Postfix to replace an existing  email system, and I am
>> inheriting usernames that are in uppercase. Apparently Postfix
>> converts all email addresses to lowercase, so I cannot receive mail to
>> the accounts that are in uppercase. This surprised me, because the
>> linux user accounts are in uppercase.
>
> The local(8) delivery agent always case-folds names to lowercase.
> This is currently not configurable. Ditto for the virtual(8) daemon.
>
> It's easy enough to delete the lowercase() call from local(8),
> but that would not be a general solution.
>
> The pipe(8) delivery agent has configurable case folding, and that
> code would have to be moved into a Postfix library module, so that
> it can be used by other Postfix delivery agents.
>
>Wietse
>

Hi Wietse, thank you for responding. I've seen many of your posts, and
know you are a postfix expert. I am still very new, and was not able
to understand your suggestions.

It sounded like you were suggesting that what I am attempting may no
be possible, which would be unfortunate for me.  I lobbied to be able
to use Postfix instead of Qmail, so hopefully I will find a way to get
uppercase names to work.


In the hopes of forcing Postfix to use the uppercase local account
names, I tried adding this line to my /etc/postfix/main.cf, though it
is still not working:

   local_recipients_maps = unix:passwd.byname


I thought there at least two ways to use uppercase names, from what I
have found on Google. The first way is t use the "canonical_maps" to
switch the lowercase name back to uppercase.  The second way is to use
"local_recipient_maps" to force Postfix to use the local accounts,
without ever converting to lowercase. Clearly I am wrong about one or
both of these options.

Re: Trying to use uppercase names in Postfix.

[Bryan Irvine]

On Mon, Dec 29, 2008 at 11:12 AM, Xn Nooby  wrote:
> I am using Postfix to replace an existing  email system, and I am
> inheriting usernames that are in uppercase. Apparently Postfix
> converts all email addresses to lowercase, so I cannot receive mail to
> the accounts that are in uppercase. This surprised me, because the
> linux user accounts are in uppercase.

Probably the easiest solution would be to write a script to create
aliases in lower case.

-Bryan

Re: Trying to use uppercase names in Postfix.

[Noel Jones]

Bryan Irvine wrote:

On Mon, Dec 29, 2008 at 11:12 AM, Xn Nooby  wrote:

I am using Postfix to replace an existing  email system, and I am
inheriting usernames that are in uppercase. Apparently Postfix
converts all email addresses to lowercase, so I cannot receive mail to
the accounts that are in uppercase. This surprised me, because the
linux user accounts are in uppercase.


Probably the easiest solution would be to write a script to create
aliases in lower case.

-Bryan



No, that won't fix the problem.

The best solution is to not use upper-case usernames.

If that's not possible, the other solutions are:
a) patch postfix local delivery agent to not force lowercase 
during delivery.
b) use something other than the postfix local delivery agent. 
 Maybe maildrop or procmail...


--
Noel Jones

VERP uses the recipient name after virtual_regexp rewriting

[Jesper Dybdal]

I have just installed a mailing list manager (Mailman) for use with my
Postfix installation (which has just been upgraded to 2.5.5).  I have
patched Mailman to use the XVERP option on MAIL FROM.

This works, but I was surprised to see that when the recipient address
provided by Mailman is rewritten by Postfix' virtual_regexp, then the
recipient address that Postfix encodes in the envelope return path is
the rewritten address, rather than the original subscriber address that
Mailman knows.

Since mailing list software using XVERP needs to recognize the address
from the envelope return path as being equal to the subscribed address,
would it not be better to always use the raw address from RCPT TO,
rather than the rewritten one, when creating the VERP'ed return path?

I have not tested this with the 2.6 experimental release, but the
release notes say nothing about VERP, so I assume the behaviour is the
same in 2.6.

(This is not a serious problem for me: the addresses that are rewritten
in my installation are in practice local addresses and it is extremely
unlikely that they will bounce.  But it surprised me.)
-- 
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

Re: Trying to use uppercase names in Postfix.

[Xn Nooby]

On Mon, Dec 29, 2008 at 3:51 PM, Noel Jones  wrote:
> Bryan Irvine wrote:
>>
>> On Mon, Dec 29, 2008 at 11:12 AM, Xn Nooby  wrote:
>>>
>>> I am using Postfix to replace an existing  email system, and I am
>>> inheriting usernames that are in uppercase. Apparently Postfix
>>> converts all email addresses to lowercase, so I cannot receive mail to
>>> the accounts that are in uppercase. This surprised me, because the
>>> linux user accounts are in uppercase.
>>
>> Probably the easiest solution would be to write a script to create
>> aliases in lower case.
>>
>> -Bryan
>
>
> No, that won't fix the problem.
>
> The best solution is to not use upper-case usernames.
>
> If that's not possible, the other solutions are:
> a) patch postfix local delivery agent to not force lowercase during
> delivery.
> b) use something other than the postfix local delivery agent.  Maybe
> maildrop or procmail...
>
> --
> Noel Jones
>

I created an /etc/postfix/aliases file containing:
   jim123: JIM123

Then I ran "newaliases", but it did not seem to work.

I can try procmail, but I am also new to procmail. Yesterday I used
procmail for the first time, and was able to divert  mailing list
emails in to subfolders.  This required me to create a .procmailrc in
my user account.  Are you suggesting a "global" procmail script that
would put the emails in to their appropriate user directories?  I
assume I could not use local procmail scripts, since my problem is I
cannot resolve the lowercase username.

One good thing is, this is for a closed internal system that will
rarely change. The users are going to access their email using
Squirrelmail w/Dovecot on Ubuntu. Since the existing users are use to
seeing there names in uppercase, I want to preserver that throughout
the system.

Re: VERP uses the recipient name after virtual_regexp rewriting

[Wietse Venema]

Jesper Dybdal:
> I have just installed a mailing list manager (Mailman) for use with my
> Postfix installation (which has just been upgraded to 2.5.5).  I have
> patched Mailman to use the XVERP option on MAIL FROM.
> 
> This works, but I was surprised to see that when the recipient address
> provided by Mailman is rewritten by Postfix' virtual_regexp, then the
> recipient address that Postfix encodes in the envelope return path is
> the rewritten address, rather than the original subscriber address that
> Mailman knows.

With VERP, Postfix embeds the envelope recipient address into the
envelope sender address. If the sender is sen...@example.com, then
the result of embedding is sender+rcptlocal=rcptdom...@example.com
(depending on the delimiter settings; default is +=).

If you change the envelope recipient address, then Postfix embeds
the changed recipient. If you change the envelope sender, then
Postfix embeds the recipient into the changed sender address.  

I do not understand why you would send mail to a recipient address
other than the recipient subscribed to the Mailman list.

> Since mailing list software using XVERP needs to recognize the address
> from the envelope return path as being equal to the subscribed address,
> would it not be better to always use the raw address from RCPT TO,
> rather than the rewritten one, when creating the VERP'ed return path?

If I understand this correctly,

1) When you rewrite the envelope RECIPIENT address, then you expect
Postfix VERP to use the original recipient address instead of the
rewritten one.

2) What if you rewrite the envelope SENDER address? Should Postfix
VERP use the original envelope sender address or the rewritten one?

If 1) and 2) work in opposite ways then my little mind will be
really confused.

> I have not tested this with the 2.6 experimental release, but the
> release notes say nothing about VERP, so I assume the behaviour is the
> same in 2.6.

Yes, this project takes pride in accurate documentatiom :-)

Wietse

> (This is not a serious problem for me: the addresses that are rewritten
> in my installation are in practice local addresses and it is extremely
> unlikely that they will bounce.  But it surprised me.)
> -- 
> Jesper Dybdal, Denmark.
> http://www.dybdal.dk (in Danish).
> 
> 

Re: Trying to use uppercase names in Postfix.

[Wietse Venema]

Xn Nooby:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Mon, Dec 29, 2008 at 3:02 PM, Wietse Venema  wrote:
> > Xn Nooby:
> >> I am using Postfix to replace an existing  email system, and I am
> >> inheriting usernames that are in uppercase. Apparently Postfix
> >> converts all email addresses to lowercase, so I cannot receive mail to
> >> the accounts that are in uppercase. This surprised me, because the
> >> linux user accounts are in uppercase.
> >
> > The local(8) delivery agent always case-folds names to lowercase.
> > This is currently not configurable. Ditto for the virtual(8) daemon.
> >
> > It's easy enough to delete the lowercase() call from local(8),
> > but that would not be a general solution.
> >
> > The pipe(8) delivery agent has configurable case folding, and that
> > code would have to be moved into a Postfix library module, so that
> > it can be used by other Postfix delivery agents.
> >
> >Wietse
> >
> 
> Hi Wietse, thank you for responding. I've seen many of your posts, and
> know you are a postfix expert. I am still very new, and was not able
> to understand your suggestions.

Your options are:

1) Create lower-case UNIX password file entries with the same
numerical UID and GID fields as the upper-case names, and with a
"*" password.

2) Do not use Postfix local(8).

3) Modify Postfix local(8) as described in my previous posting.

Wietse

> It sounded like you were suggesting that what I am attempting may no
> be possible, which would be unfortunate for me.  I lobbied to be able
> to use Postfix instead of Qmail, so hopefully I will find a way to get
> uppercase names to work.
> 
> 
> In the hopes of forcing Postfix to use the uppercase local account
> names, I tried adding this line to my /etc/postfix/main.cf, though it
> is still not working:
> 
>local_recipients_maps = unix:passwd.byname
> 
> 
> I thought there at least two ways to use uppercase names, from what I
> have found on Google. The first way is t use the "canonical_maps" to
> switch the lowercase name back to uppercase.  The second way is to use
> "local_recipient_maps" to force Postfix to use the local accounts,
> without ever converting to lowercase. Clearly I am wrong about one or
> both of these options.
> 
> 

Re: Trying to use uppercase names in Postfix.

[Noel Jones]

Xn Nooby wrote:

On Mon, Dec 29, 2008 at 3:51 PM, Noel Jones  wrote:

Bryan Irvine wrote:

On Mon, Dec 29, 2008 at 11:12 AM, Xn Nooby  wrote:

I am using Postfix to replace an existing  email system, and I am
inheriting usernames that are in uppercase. Apparently Postfix
converts all email addresses to lowercase, so I cannot receive mail to
the accounts that are in uppercase. This surprised me, because the
linux user accounts are in uppercase.

Probably the easiest solution would be to write a script to create
aliases in lower case.

-Bryan


No, that won't fix the problem.

The best solution is to not use upper-case usernames.

If that's not possible, the other solutions are:
a) patch postfix local delivery agent to not force lowercase during
delivery.
b) use something other than the postfix local delivery agent.  Maybe
maildrop or procmail...

--
Noel Jones



I created an /etc/postfix/aliases file containing:
   jim123: JIM123

Then I ran "newaliases", but it did not seem to work.


Right.



I can try procmail, but I am also new to procmail. Yesterday I used
procmail for the first time, and was able to divert  mailing list
emails in to subfolders.  This required me to create a .procmailrc in
my user account.  Are you suggesting a "global" procmail script that
would put the emails in to their appropriate user directories?  I
assume I could not use local procmail scripts, since my problem is I
cannot resolve the lowercase username.


Sorry, I don't use procmail, so I can't guide you there.
Since you're using dovecot, you also might be able to use the 
dovecot "deliver" delivery agent.


Here's some documentation intended for maildrop, but the same 
general setup should work with other delivery agents.

http://www.postfix.org/MAILDROP_README.html#direct



One good thing is, this is for a closed internal system that will
rarely change. The users are going to access their email using
Squirrelmail w/Dovecot on Ubuntu. Since the existing users are use to
seeing there names in uppercase, I want to preserver that throughout
the system.


Upper case user names are evil.  You will be forever haunted 
by them.  Switch now.


I see that Wietse has suggested:

1) Create lower-case UNIX password file entries with the same
numerical UID and GID fields as the upper-case names, and with a
"*" password.

This may be a workable option for you.



--
Noel Jones

Re: VERP uses the recipient name after virtual_regexp rewriting

[mouss]

Jesper Dybdal a écrit :
> I have just installed a mailing list manager (Mailman) for use with my
> Postfix installation (which has just been upgraded to 2.5.5).  I have
> patched Mailman to use the XVERP option on MAIL FROM.
> 
> This works, but I was surprised to see that when the recipient address
> provided by Mailman is rewritten by Postfix' virtual_regexp, then the
> recipient address that Postfix encodes in the envelope return path is
> the rewritten address, rather than the original subscriber address that
> Mailman knows.
> 
> Since mailing list software using XVERP needs to recognize the address
> from the envelope return path as being equal to the subscribed address,

Really? AFAIK, most list managers use the From: header.

> would it not be better to always use the raw address from RCPT TO,
> rather than the rewritten one, when creating the VERP'ed return path?
> 
> I have not tested this with the 2.6 experimental release, but the
> release notes say nothing about VERP, so I assume the behaviour is the
> same in 2.6.
> 
> (This is not a serious problem for me: the addresses that are rewritten
> in my installation are in practice local addresses and it is extremely
> unlikely that they will bounce.  But it surprised me.)

Re: Trying to use uppercase names in Postfix.

[Sahil Tandon]

Xn Nooby wrote:

> >> Probably the easiest solution would be to write a script to create
> >> aliases in lower case.
> >>
> >> -Bryan
> >
> > No, that won't fix the problem.
> >
> > The best solution is to not use upper-case usernames.
> >
> > If that's not possible, the other solutions are:
> > a) patch postfix local delivery agent to not force lowercase during
> > delivery.
> > b) use something other than the postfix local delivery agent.  Maybe
> > maildrop or procmail...
> 
> I created an /etc/postfix/aliases file containing:
>jim123: JIM123
> 
> Then I ran "newaliases", but it did not seem to work.

Is /etc/postfix/aliases appropriately defined in your main.cf?  Please
show the output of 'postconf -n' and read:
http://www.postfix.org/DEBUG_README.html#mail

-- 
Sahil Tandon 

Re: Trying to use uppercase names in Postfix.

[Xn Nooby]

Hi Sahil,

I am looking in to how to create the duplicate passwd file entries, I
am assuming I cannot just edit the file without corrupting it. Below
is my main.cf and aliases file.  Also, should I post my replies to
emails at the top or the bottom? (a few years ago some people got
really mad at me, but now I can't remember which was correct)

I noticed the main.cf referred to /etc/aliases while I had edited
/etc/postfix/aliases, so I also put my JIM123 entry in to /etc/aliases
and ran "sudo newaliases", but still isn't working. Should I be using
/etc/aliases instead of /etc/postfix/aliases? A few hours ago I got
"The Book of Postfix" from No Starch Press, and they said
/etc/postfix/aliases (but I suspect that is wrong).


theu...@vcorpmail:~$ cat /etc/postfix/main.cf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 4096
message_size_limit = 1024
mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp
mydestination = corpremote.local, localhost
myhostname = vcorpmail.corpremote.local
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = 192.168.1.16
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_recipient_restrictions = check_sender_access
regexp:/etc/postfix/check_sender_access.regexp, check_recipient_access
regexp:/etc/postfix/check_recipient_access.regexp,
check_relay_domains, reject_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes



theu...@vcorpmail:~$ cat /etc/postfix/aliases
jim123: JIM123
theu...@vcorpmail:~$





On Mon, Dec 29, 2008 at 4:32 PM, Sahil Tandon  wrote:
> Xn Nooby wrote:
>
>> >> Probably the easiest solution would be to write a script to create
>> >> aliases in lower case.
>> >>
>> >> -Bryan
>> >
>> > No, that won't fix the problem.
>> >
>> > The best solution is to not use upper-case usernames.
>> >
>> > If that's not possible, the other solutions are:
>> > a) patch postfix local delivery agent to not force lowercase during
>> > delivery.
>> > b) use something other than the postfix local delivery agent.  Maybe
>> > maildrop or procmail...
>>
>> I created an /etc/postfix/aliases file containing:
>>jim123: JIM123
>>
>> Then I ran "newaliases", but it did not seem to work.
>
> Is /etc/postfix/aliases appropriately defined in your main.cf?  Please
> show the output of 'postconf -n' and read:
> http://www.postfix.org/DEBUG_README.html#mail
>
> --
> Sahil Tandon 
>

Re: Trying to use uppercase names in Postfix.

[Xn Nooby]

> Your options are:
>
> 1) Create lower-case UNIX password file entries with the same
> numerical UID and GID fields as the upper-case names, and with a
> "*" password.

I was able to resolve my problem by creating the duplicate entry in
the /etc/passwd file, I will  use this method.

I might uses aliases if I can get them to work, but at least I know
the passwd file is guaranteed to solve my problem.

thanks!

Re: Trying to use uppercase names in Postfix.

[mouss]

Xn Nooby a écrit :
> Hi Sahil,
> 
> I am looking in to how to create the duplicate passwd file entries, I
> am assuming I cannot just edit the file without corrupting it.



you forgot to tell us which OS you run. let's assume your "sudo ..." as
a hint ;-p

- save the following as doit.sh

#!/bin/sh
IFS=:
cat /etc/passwd | while read user _x uid gid gecos home shell; do
user=`echo $user | tr [A-Z] [a-z]`
grep -q "^${user}:" /etc/passwd
if [ $? -ne 0 ]; then
echo "adduser --disabled-password --uid $uid --gid $gid --gecos $gecos
--home $home --shell $shell $user";
fi
done

- run it: sh doit.sh > lowerpass.sh

- edit lowerpass.sh and remove all lines but the ones that create the
users you want to create.




> Below
> is my main.cf and aliases file.  Also, should I post my replies to
> emails at the top or the bottom? (a few years ago some people got
> really mad at me, but now I can't remember which was correct)
> 

put your replies at the bottom. if you don't know why, search for "top
posting".

> I noticed the main.cf referred to /etc/aliases while I had edited
> /etc/postfix/aliases, so I also put my JIM123 entry in to /etc/aliases
> and ran "sudo newaliases", but still isn't working. 

what is not working? As you have already been told, postfix "local" will
lowercase the address, so alias_maps don't help.

> Should I be using
> /etc/aliases instead of /etc/postfix/aliases? A few hours ago I got
> "The Book of Postfix" from No Starch Press, and they said
> /etc/postfix/aliases (but I suspect that is wrong).


This is system dependent. for postfix, the only thing that really
matters is that the path be the one specified in alias_maps and
alias_database.

Re: VERP uses the recipient name after virtual_regexp rewriting

[Jesper Dybdal]

On Mon, 29 Dec 2008 16:21:41 -0500 (EST), wie...@porcupine.org (Wietse
Venema) wrote:

>I do not understand why you would send mail to a recipient address
>other than the recipient subscribed to the Mailman list.

Example:

My server (for Mailman and Postfix and some local mailboxes) is named
nuser.dybdal.dk.  The Mailman virtual host is lists.dybdal.dk, the list
I am experimenting with is named jdtest.

The subscribed address that Mailman knows is jd-test2 at dybdal.dk.

In virtual_regexp, this address is translated to jd+dybdal.dk+jd-test2
at nuser.dybdal.dk.  I do this in order to have it delivered to the "jd"
mailbox at nuser.dybdal, with an extension that allows my mail client to
recognize the precise virtual domain and address that was used (the same
mailbox receives mail to several addresses in several domains).

When Mailman sends mail to jd-test2 at dybdal.dk, the address in RCPT TO
is "jd-test2 at dybdal.dk", but the envelope sender becomes
jdtest-bounces+jd+dybdal.dk+jd-test2=nuser.dybdal.dk at lists.dybdal.dk.
If this should bounce (which it won't in this example, but it might
possible be rewritten to an address at another machine instead), Mailman
will try to find a subscriber with the address
jd+dybdal.dk+jd-te...@nuser.dybdal.dk, and fail to do so.

>1) When you rewrite the envelope RECIPIENT address, then you expect
>Postfix VERP to use the original recipient address instead of the
>rewritten one.

I think that would make sense, because the VERP'ed recipient address is
used (only) for comparison with the subscribed address when the mail
bounces.

>2) What if you rewrite the envelope SENDER address? Should Postfix
>VERP use the original envelope sender address or the rewritten one?

I had not considered that, since I have no desire to rewrite the sender
address.  But I think my answer to that question is "no".

>If 1) and 2) work in opposite ways then my little mind will be
>really confused.

I may well have misunderstood something, but it seems to me that:

1) The purpose of the VERP encoded recipient address is (only!) to allow
mailing list software to recognize a subscriber, and it therefore makes
sense to have the VERP encoded recipient address equal to the subscriber
address as the mailing list software knows it; i.e., the RCPT TO
address.  This VERP use of the recipient address is quite different from
the primary purpose of the recipient address, which is to get the mail
to wherever the owner of the address wants it, which of course may
require rewriting.

2) The purpose of the sender address (whether or not is has a VERP part
appended) is to ensure that a bounce is delivered correctly; if any
rewriting is specified for the sender address, surely whoever made the
rewriting rule has ensured that the rewritten address will be delivered
correctly.  The mailing list software does not compare the sender
address with anything; it just notes that it received a message at its
bounce address.

Since my first mail, I have tried an experiment where the rewriting of
the sender address is done by a .forward file instead of by
virtual_regexp; in that case, VERP actually uses the recipient address
before it has been changed by .forward, as I would like it to do.

Perhaps part of my problem is that I don't really see why it should make
a difference to the VERP address whether the recipient address is
changed by virtual_regexp or by .forward.

>> I have not tested this with the 2.6 experimental release, but the
>> release notes say nothing about VERP, so I assume the behaviour is the
>> same in 2.6.
>
>Yes, this project takes pride in accurate documentatiom :-)

You don't really need the smiley - the pride is very appropriate.
Accurate documentation, including complete release notes, is something
that I, and undoubtedly many others, very much appreciate about Postfix
- and miss in many many other software products.
-- 
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

Re: VERP uses the recipient name after virtual_regexp rewriting

[Jesper Dybdal]

On Mon, 29 Dec 2008 22:30:53 +0100, mouss  wrote:

>Jesper Dybdal a écrit :
>> Since mailing list software using XVERP needs to recognize the address
>> from the envelope return path as being equal to the subscribed address,
>
>Really? AFAIK, most list managers use the From: header.

The point in VERP is that the list subscriber that bounces can be
recognized by the address that the bounce is sent to.  This is a much
safer way to identify the subscriber than any attempt to parse the
bounce message to determine which address actually bounced.
-- 
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

Re: Trying to use uppercase names in Postfix.

[Wietse Venema]

Xn Nooby:
> > Your options are:
> >
> > 1) Create lower-case UNIX password file entries with the same
> > numerical UID and GID fields as the upper-case names, and with a
> > "*" password.
> 
> I was able to resolve my problem by creating the duplicate entry in
> the /etc/passwd file, I will  use this method.

Good. Now, consider that this question was asked here for 10 years,
before I came up with this answer.

I may have posted this solution before but then everyone
including me gas forgotten it.

> I might uses aliases if I can get them to work, but at least I know
> the passwd file is guaranteed to solve my problem.

The aliases solution cannot work, because Postfix local(8) case-folds
all recipient addresses.

Wietse

Re: VERP uses the recipient name after virtual_regexp rewriting

[mouss]

Jesper Dybdal a écrit :
> On Mon, 29 Dec 2008 22:30:53 +0100, mouss  wrote:
> 
>> Jesper Dybdal a écrit :
>>> Since mailing list software using XVERP needs to recognize the address
>>> from the envelope return path as being equal to the subscribed address,
>> Really? AFAIK, most list managers use the From: header.
> 
> The point in VERP is that the list subscriber that bounces can be
> recognized by the address that the bounce is sent to.  This is a much
> safer way to identify the subscriber than any attempt to parse the
> bounce message to determine which address actually bounced.

I misunderstood. I thought you were talking about checking that a post
is from a member (before resending).

postfix: set up pop3 / imap with postfix..

[vivek.agrawal]

hello everyone,

I want to use postfix to send and receive mail for my web application.
Currently i am able to send email using gmail as relay host. now i am trying
to get email comming to same gmail account which i am using for relay host.
on some sites i have read that i need to configure pop3 or imap to get email
from gmail account. 
 
can any one tell do i need to configure pop3. if yes please tell me how to
configure and use pop3/imap , appreciate if you can tell me the debugging
steps also.

-- 
View this message in context: 
http://www.nabble.com/postfix%3A-set-up-pop3---imap-with-postfix..-tp21214122p21214122.html
Sent from the Postfix mailing list archive at Nabble.com.