Byung-Hee HWANG a écrit :
> mouss wrote:
>> Byung-Hee HWANG a écrit :
> [...]
>> - Use the submission port (587) with TLS+SASL.
>
> What is different between using 25 and using 587?
>
587 has been reserved for mail submission. It is a good practice to
separate the flows. some advantages:
- you
I was thinking about using something like this
receive_override_options=${content_filter:no_address_mappings}
in main.cf, to avoid risking to have a misconfiguration if the
content_filter setting is changed in master.cf or in main.cf.
an alternative would be
receive_override_options=${no_addres
mouss:
> I was thinking about using something like this
>
> receive_override_options=${content_filter:no_address_mappings}
>
> in main.cf, to avoid risking to have a misconfiguration if the
> content_filter setting is changed in master.cf or in main.cf.
>
> an alternative would be
>
> receive_o
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-postfix-
> [EMAIL PROTECTED] On Behalf Of Mark Martinec
> Sent: Thursday, October 23, 2008 6:24 PM
> To: postfix-users@postfix.org
> Subject: Re: Postfix - altermime - amavis - Too many hops
>
> Peter,
>
> > > >>> disclaimer
Hello all,
Does anyone out there have some megabytes of real life production
postfix logs (mail accepted, received, sent, refused, etc, etc)...
and wouln't minf sharing them with me :)
I'dd like to see how postfix logs this type of information.
thx
Joao
Hello list,
I'm pretty new to Postfix still, but I've been reading through the
documentation on postfix.org and have come to the conclusion that the
setup guide I followed (http://articles.slicehost.com/email) offers a
pretty good starting point. However, I'd like to use procmail in some
Jevos, Peter a écrit :
>
> I know about this opttion but the problem is that I'm using maia
> mailguread and it uses amavisd-new 2.3 and your features come from 2.5.x
> version
> Therefore I decided to do it on the postfix side through the filters.
> But I cannot understand how cannot distinguishe
Dan Phiffer a écrit :
> Hello list,
>
> I'm pretty new to Postfix still, but I've been reading through the
> documentation on postfix.org and have come to the conclusion that the
> setup guide I followed (http://articles.slicehost.com/email) offers a
> pretty good starting point. However, I'd like
Joao Ferreira wrote:
Hello all,
Does anyone out there have some megabytes of real life production
postfix logs (mail accepted, received, sent, refused, etc, etc)...
and wouln't minf sharing them with me :)
I'dd like to see how postfix logs this type of information.
That would be unlikely
Joao Ferreira a écrit :
> Hello all,
>
> Does anyone out there have some megabytes of real life production
> postfix logs (mail accepted, received, sent, refused, etc, etc)...
>
> and wouln't minf sharing them with me :)
>
>
> I'dd like to see how postfix logs this type of information.
>
if y
On Fri, Oct 24, 2008 at 01:16:21PM -0400, Terry Carmen wrote:
> Joao Ferreira wrote:
> >Hello all,
> >
> >Does anyone out there have some megabytes of real life production
> >postfix logs (mail accepted, received, sent, refused, etc, etc)...
> >
> >and wouln't minf sharing them with me :)
> >
> >
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> Incoming mail is logged by smtpd(8)/pickup(8) and cleanup(8). Mail
> (re)entering the active queue is logged by the queue manager, which
> logs the sender address. Deliveries to recipients are logged by delivery
... one thing I've sometimes wished for i
On Fri, Oct 24, 2008 at 01:55:05PM -0400, Ofer Inbar wrote:
> Victor Duchovni <[EMAIL PROTECTED]> wrote:
> > Incoming mail is logged by smtpd(8)/pickup(8) and cleanup(8). Mail
> > (re)entering the active queue is logged by the queue manager, which
> > logs the sender address. Deliveries to recipie
There is no guarantee that mail goes from incoming->qmgr only once.
Whenever the qmgr is restarted, mail goes back from active queue
to incoming queue, so that it doesn't drown in a sea of deferred
mail.
If your problem is a large incoming queue, then I suggest that you
take the necessary step to
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> This is not difficult to solve. Write a progressive parser that saves
> state just for messages that are not yet done (still in the queue). For
[...]
That's sort of what I described in my second paragraph. It's a
workaround, but it's far from perfect,
On Fri, Oct 24, 2008 at 02:31:32PM -0400, Ofer Inbar wrote:
> Wietse Venema <[EMAIL PROTECTED]> wrote:
> > There is no guarantee that mail goes from incoming->qmgr only once.
> > Whenever the qmgr is restarted, mail goes back from active queue
> > to incoming queue, so that it doesn't drown in a s
Good evening,
Short version of the question:
If I am rewriting sender addresses using:
/^(.+)@pt\.lu$/ $1+pt.lu:[EMAIL PROTECTED]
/^(.+)+pt.lu:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
How important is the risk to be used as open relay?
Long version of the problem:
The Luxembourgish Internet Provider
Postfix relay permission is decided before (recipient) address
rewriting.
For example, we don't want "relay access denied" when a virtual
alias changes an address in a local domain into a remote address.
Wietse
Paul Cocker wrote:
Under the existing setup the postfix (secondary MX) doesn't deliver mail
internally, it passes it on to the Barracuda. The idea being that should
the Barracuda fail we can allow temporary internal delivery from this
server but for 99% of the time manage all mail via a single in
???
My rewriting idea works for my purpose. I am just trying to
investigate the risk...
Best Regards,
Yves
On 24.10.2008, at 22:28, Wietse Venema wrote:
Postfix relay permission is decided before (recipient) address
rewriting.
For example, we don't want "relay access denied" when a virtu
On Oct 24, 2008, at 1:13 PM, mouss wrote:
Dan Phiffer a écrit :
Hello list,
I'm pretty new to Postfix still, but I've been reading through the
documentation on postfix.org and have come to the conclusion that the
setup guide I followed (http://articles.slicehost.com/email) offers a
pretty good
Wietse:
> Postfix relay permission is decided before (recipient) address
> rewriting.
>
> For example, we don't want "relay access denied" when a virtual
> alias changes an address in a local domain into a remote address.
Yves Kreis:
> My rewriting idea works for my purpose. I am just trying to
Re,
I don't use it for relay permission but for the destination server to
accept the mail.
Best Regards,
Yves
On 24.10.2008, at 23:12, Wietse Venema wrote:
Wietse:
Postfix relay permission is decided before (recipient) address
rewriting.
For example, we don't want "relay access denied" w
Wietse:
> Postfix relay permission is decided before (recipient) address
> rewriting.
>
> For example, we don't want "relay access denied" when a virtual
> alias changes an address in a local domain into a remote address.
Yves Kreis:
> My rewriting idea works for my purpose. I am just trying to
>
Wietse:
Postfix relay permission is decided before (recipient) address
rewriting.
For example, we don't want "relay access denied" when a virtual
alias changes an address in a local domain into a remote address.
Yves Kreis:
My rewriting idea works for my purpose. I am just trying to
investiga
Yves Kreis a écrit :
> Yes it is about postfix address rewriting (which can be done as well
> though sender_canonical_maps afaik).
>
> And yes it is about Postfix becoming an open relay. The rule
> /^(.+)+pt.lu:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
> forwards all mails sent to xxx+pt.lu:[EMAIL PROT
> >
> > I know about this opttion but the problem is that I'm using maia
> > mailguread and it uses amavisd-new 2.3 and your features come from
> 2.5.x
> > version
> > Therefore I decided to do it on the postfix side through the
filters.
> > But I cannot understand how cannot distinguished the inco
Yves Kreis:
> > Wietse:
> >> Postfix relay permission is decided before (recipient) address
> >> rewriting.
> >>
> >> For example, we don't want "relay access denied" when a virtual
> >> alias changes an address in a local domain into a remote address.
> >
> > Yves Kreis:
> >> My rewriting idea wor
This thread is long dead, but I'm surprised no one suggested mimedefang.
--
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
On 12/6/06, Kelly Jones <
29 matches
Mail list logo
