On Mon, 28 Dec 2009 22:35:31 you wrote:
> Hi!!
>
> That only works for mailbox kind of mail mailbox. If you're running
> maildir++ (courier... for example) or cyrus support you could try :
>
> http://postfixquotareject.ramattack.net.
>
> Bye!!!
I am running mailbox and the hard coded "virtual_mail
Michael a écrit :
> Is the following configuration directives supported out of the box or do
> these
> require a 3rd party patch? I obtained these from another site, however it
> made reference to an RPM file, whereas I am using source so it wasn't clear.
>
> virtual_mailbox_limit = 104857600
>
Am 28.12.2009 08:08, schrieb Michael:
> Is the following configuration directives supported out of the box or do
> these
> require a 3rd party patch? I obtained these from another site, however it
> made reference to an RPM file, whereas I am using source so it wasn't clear.
>
> virtual_mailbox
> Your problem description is useful, but actual logging that corresponds
> to your situation and the output of 'postconf -n' are required. Please
> see DEBUG_README (a document to which you were linked upon joining this
> mailing list) for tips on seeking help here.
Thanks for the response.
Frank Cusack:
> I can't get the relay_recipient_maps lookup to ignore the address
> extension part of a recipient email address. It's very difficult to
> use address extensions together with relay_recipient_maps this way.
> Am I missing some configuration setting? I've been searching for it
> for
When the recipient domain matches mydestination (or any IP address
literal that matches inet_interfaces or proxy_interfaces).
1) local(8) will accept the recipient ONLY if the username is
found. It does not look for usern...@domain.
2) However, smtpd(8) will accept the recipient if either the
FreeBSD-7.2 with Postfix (2.7-20091115) from the FreeBSD ports system.
This is my first attempt to get SPF working. I installed
"postfix-policyd-spf-perl" via the ports system and followed the
directions (I think). I added this to the 'master.cf' file:
spf-policy unix - n n -
On Mon, 28 Dec 2009 09:15:05 -0500, Jerry wrote:
>
> That section now looks like this:
>
> smtpd_recipient_restrictions =
> permit_sasl_authenticated
> permit_mynetworks
> reject_unauth_destination
> check_policy_service unix:private/spf-policy
> reject
>
You're sure that the REJECT at the
> So, be sure that you don't have u...@domain forms in $alias_maps.
Thanks. Every line in the alias files defined in $alias_maps is of the
following form:
USER: u...@subx.domain.com
We are not using the form "u...@domain" for alias entries (instead just
USER). I would like to inform again th
On Mon, Dec 28, 2009 at 12:00:34AM +0100, Christoph Anton Mitterer wrote:
> Hi.
>
> I'm still trying to understand some things, so perhaps some of you could
> help me.
>
> 1) As far as I understood the address rewriting manual, rewriting
> (including the app...@origin and append.domain) happens
On Mon, Dec 28, 2009 at 12:32:51PM -0500, Terry Carmen wrote:
> On 12/27/2009 11:28 PM, Satish Kumar P wrote:
>> 1. "unknown user" (this is really strange, if the user were unknown,
>> postfix/smtpd would have rejected the recipient at SMTP connection
>> itself)
>> 2. "mail forwarding loop" for x.
On 12/27/2009 11:28 PM, Satish Kumar P wrote:
1. "unknown user" (this is really strange, if the user were unknown,
postfix/smtpd would have rejected the recipient at SMTP connection
itself)
2. "mail forwarding loop" for x...@domain.com (though we are pretty
sure that the mail came to this server
Dne 9.12.2009 v 09:45 Michal Kurka napsal(a):
> Dne 6.12.2009 v 10:41 Michal Kurka napsal(a):
>
> > I need resolve whether incoming mail for the recipient accept or defer
> > or reject according to some rule of local username(s) (of course, if the
> > recipient corresponds to local username
Hi,
The only officially supported quota enforcing method is for mailbox mailboxes .
There are too other quota limit software like vda or postfixquotareject wich
can achieve you're goal. Vda was that you seem to have installed... another
method is postfixquotareject wich just works fine too but
I don't know what the correct terminology is for my question - please
adjust my wording as needed.
When a user mistypes a remote e-mail address (not that THAT ever
happens!), the result is typically either a "user unknown", "invalid
recipient", or "host or domain not found" message. At least
Michal Kurka:
> Dne 9.12.2009 v 09:45 Michal Kurka napsal(a):
>
> > Dne 6.12.2009 v 10:41 Michal Kurka napsal(a):
> >
> > > I need resolve whether incoming mail for the recipient accept or
> > > defer
> > > or reject according to some rule of local username(s) (of course, if the
> > > reci
satishkumarp2k1:
>
>
> > So, be sure that you don't have u...@domain forms in $alias_maps.
>
> Thanks. Every line in the alias files defined in $alias_maps is of the
> following form:
>
> USER: u...@subx.domain.com
>
> We are not using the form "u...@domain" for alias entries (instead just
>
Daniel L. Miller:
[ Charset ISO-8859-1 unsupported, converting... ]
> I don't know what the correct terminology is for my question - please
> adjust my wording as needed.
>
> When a user mistypes a remote e-mail address (not that THAT ever
> happens!), the result is typically either a "user unkn
On Mon, 28 Dec 2009, Daniel L. Miller wrote:
> I don't know what the correct terminology is for my question -
> please adjust my wording as needed.
>
> When a user mistypes a remote e-mail address (not that THAT ever
> happens!), the result is typically either a "user unknown", "invalid
> recipie
On Mon, Dec 28, 2009 at 05:56:48PM -0500, Wietse Venema wrote:
> satishkumarp2k1:
...
> According to the main.cf information in the problem report,
> local_recipient_maps=$alias_maps and all those maps are local
> files, so that would exclude the usual nsswitch foul-ups.
>
> There are no confirmed
On Mon, 2009-12-28 at 14:27 -0500, Victor Duchovni wrote:
> The trivial-rewrite service does the rewriting, and the cleanup service
> updates the queue-file updating addresses in headers, ...
> No, but smtpd(8) uses normalized (via trivial-rewrite) recipient
> and sender addresses to make access d
What if anything is the difference between virtual_maps and
virtual_alias_maps ?
I have just discovered on a production mail server that it doesn't like
running both of these together (pointing to different SQL tables)
Is there any difference in the operation of these two or can I just amalgama
Michael:
> What if anything is the difference between virtual_maps and
> virtual_alias_maps ?
virtual_maps is the obsolete name. It is still supported because
I am always concerned with backwards compatibility.
Wietse
On Tue, Dec 29, 2009 at 01:33:15PM +1300, Michael wrote:
> What if anything is the difference between virtual_maps and
> virtual_alias_maps ?
1. alias_ ;)
2. Deprecation of $virtual_maps since Postfix 2.0
http://www.postfix.org/VIRTUAL_README.html#virtual_alias
http://www.postfix.org/postconf.5.
> Is the alias table generated dynamically? It is possible that it's not
> readable (still being written) at the time the lookup happens?
Yes, correct. All the alias files are generated using perl scripts, which
run periodically. The scripts actually generate temporary alias files (while
gener
satishkumarp2k1 put forth on 12/28/2009 9:29 PM:
> Yes, correct. All the alias files are generated using perl scripts, which
> run periodically. The scripts actually generate temporary alias files (while
> generating the aliases) and then just use "mv" command to the actual alias
> file. Do you st
On Tue, Dec 29, 2009 at 12:59:13AM +0100, Christoph Anton Mitterer wrote:
> On Mon, 2009-12-28 at 14:27 -0500, Victor Duchovni wrote:
> > The trivial-rewrite service does the rewriting, and the cleanup service
> > updates the queue-file updating addresses in headers, ...
>
> > No, but smtpd(8) us
On Mon, Dec 28, 2009 at 10:51:47PM -0600, Stan Hoeppner wrote:
> satishkumarp2k1 put forth on 12/28/2009 9:29 PM:
>
> > Yes, correct. All the alias files are generated using perl scripts, which
> > run periodically. The scripts actually generate temporary alias files (while
> > generating the ali
28 matches
Mail list logo
