I got it now, thank you. I will use the one-liner and see what will happen.And
indeed you are right, it will cost a DNS lookup, but it willSave you processing
on the server. Thanks again -Oorspronkelijk bericht-
Van: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
I have a setup with postfix MXes handing mail off to postfix backend
mailbox servers via smtp. I currently have transport_maps returning
"relay:[fqdn]" where fqdn is the backend server hostname to which mail
is delivered. I want to change this to individual transports (one per
backend) so I c
Considering scenario of 70 domains with ard 1000 users per domain, my only
conern was ,maintaining transport maps would be more of a manual task. I
agree to fact of generating a backstacker but this process of migration will
last for period of max 2 days or so which should be fine.
Having said that
M.A. GEERTSMA wrote, at 04/10/2009 03:13 PM:
> I will replace the 3 lines by the 1, but would that be double because of
> MailScanner.
> btw, MailScanner uses a local file: phishing.bad.sites.conf which is
> updated regulary.
You're missing the point, and comparing two unrelated features.
reject
ghe wrote, at 04/10/2009 02:54 PM:
> Oh, dear! I'm not sure what, if anything, I can do about this, but
> thanks to you all for the response(s). Maybe a non-caching name server
> might help.
You've only indicated that an authenticated client's IP address does not
reliably provide a reverse lookup
Gordon Baldwin wrote:
We have a setup where we have a bunch of mail we need to send to a
domain that tends to back up our mail server. I put a transport rule
in to send all mail to that domain to a relay to get it out of our
main mail queue and let it deal with it and not disrupt the rest of
the
Thanks and sorry for my double post. webmail client gave errors, but it seems
the messages were sent anyway.I will replace the 3 lines by the 1, but would
that be double because of MailScanner.
btw, MailScanner uses a local file: phishing.bad.sites.conf which is updated
regulary.Thanks,
JohanOn
ghe wrote:
Oh, dear! I'm not sure what, if anything, I can do about this, but
thanks to you all for the response(s). Maybe a non-caching name server
might help.
I don't think there's anything you can do about it. The settings for how
long a cached record stays alive and when an update is atte
On Fri, Apr 10, 2009 at 08:49:26PM +0200, M.A. GEERTSMA wrote:
> I installed my server with Postfix, mailscanner and SpamAssassin.
> In main.cf I added these lines:
>
> reject_rbl_client cbl.abuseat.org,
> reject_rbl_client sbl.spamhaus.org,
> reject_rbl_client pbl.spamhau
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J.P. Trosclair wrote:
> SBC Global's ns1.swbell.net does answer with the appropriate IP address,
> but neither our companies name servers or my local dns on my home
> network can resolve adsl-99-29-103-142.dsl.hstntx.sbcglobal.net. I
> restarted named
I installed my server with Postfix, mailscanner and SpamAssassin.
In main.cf I added these lines:
reject_rbl_client cbl.abuseat.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client pbl.spamhaus.org
But MailScanner/Spamassassin also does something with hostnames; acco
I installed my server with Postfix, mailscanner and SpamAssassin.
In main.cf I added these lines:
reject_rbl_client cbl.abuseat.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client pbl.spamhaus.org
But MailScanner/Spamassassin also does something with hostnames; acco
Yes it does:
# host adsl-99-29-103-142.dsl.hstntx.sbcglobal.net
adsl-99-29-103-142.dsl.hstntx.sbcglobal.net has address 99.29.103.142
SBC Global's ns1.swbell.net does answer with the appropriate IP address,
but neither our companies name servers or my local dns on my home
network can resolve
ghe:
> Wietse Venema wrote:
>
> >>> # host 99.29.103.142
> >>> 142.103.29.99.in-addr.arpa domain name pointer
> >>> adsl-99-29-103-142.dsl.hstntx.sbcglobal.net.
> >> As far as I know, this is the only Blackberry using this mail server.
> >> Other hosts/domains/devices don't have this problem. Can
On Fri, Apr 10, 2009 at 11:41:51AM -0600, ghe wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Wietse Venema wrote:
>
> >>> # host 99.29.103.142
> >>> 142.103.29.99.in-addr.arpa domain name pointer
> >>> adsl-99-29-103-142.dsl.hstntx.sbcglobal.net.
> >> As far as I know, this is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wietse Venema wrote:
>>> # host 99.29.103.142
>>> 142.103.29.99.in-addr.arpa domain name pointer
>>> adsl-99-29-103-142.dsl.hstntx.sbcglobal.net.
>> As far as I know, this is the only Blackberry using this mail server.
>> Other hosts/domains/devices
ghe:
> I'm getting log entries like this:
>
> > Apr 2 12:55:53 ralph postfix/smtpd[15788]: 779DFC6D76:
> > client=unknown[99.29.103.142], sasl_method=LOGIN, sasl_username=joelqw
>
> This is one of my users' Blackberry. Notice that Postfix (or maybe it's
> Dovecot, in the sasl verification) is s
post...@corwyn.net wrote, at 04/10/2009 12:08 PM:
> Currently I block email with
> smtpd_sender_restrictions =
>reject_unknown_sender_domain
>check_sender_access hash:/etc/postfix/access
> smtpd_data_restrictions =
>reject_multi_recipient_bounce
> smtpd_recipient_restrictions =
>r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm getting log entries like this:
> Apr 2 12:55:53 ralph postfix/smtpd[15788]: 779DFC6D76:
> client=unknown[99.29.103.142], sasl_method=LOGIN, sasl_username=joelqw
This is one of my users' Blackberry. Notice that Postfix (or maybe it's
Dovecot, in
Currently I block email with
smtpd_sender_restrictions =
reject_unknown_sender_domain
check_sender_access hash:/etc/postfix/access
smtpd_data_restrictions =
reject_multi_recipient_bounce
smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unk
We have a setup where we have a bunch of mail we need to send to a
domain that tends to back up our mail server. I put a transport rule
in to send all mail to that domain to a relay to get it out of our
main mail queue and let it deal with it and not disrupt the rest of
the outgoing mail.
So far
On Fri, 10 Apr 2009, punit jain wrote:
> My organisation is primarily a domino setup but we are now moving to
> postfix. Postfix is the edge server with a valid MX now. I accept mail for
> my domain xxx.com. I am presently in process of moving all the users to
> postfix slowly with time. Do we hav
punit jain:
> Hi ,
>
> My organisation is primarily a domino setup but we are now moving to
> postfix. Postfix is the edge server with a valid MX now. I accept mail for
> my domain xxx.com. I am presently in process of moving all the users to
> postfix slowly with time. Do we have any setting in p
Hi ,
My organisation is primarily a domino setup but we are now moving to
postfix. Postfix is the edge server with a valid MX now. I accept mail for
my domain xxx.com. I am presently in process of moving all the users to
postfix slowly with time. Do we have any setting in postfix wherein i accept
Halassy Zolt??n:
> > 15 seconds? Postfix out-of-the-box waits no more than 9 seconds
> > for the very probe to succeed. Perhaps you have been changing
> > Postfix parameters. Please follow instructions as requested in
> > the mailing list welcome message.
>
> Sorry, my bad, I had the address_veri
15 seconds? Postfix out-of-the-box waits no more than 9 seconds
for the very probe to succeed. Perhaps you have been changing
Postfix parameters. Please follow instructions as requested in
the mailing list welcome message.
Sorry, my bad, I had the address_verify_poll_delay set to 15 seconds,
w
Halassy Zolt??n:
> > Postfix logs delays in fine detail including the delays of address
> > probe messages: time in incoming/deferred queue, time in active
> > queue, time to complete DNS lookup and TCP/SMTP/LMTP handshake,
> > time to transmit message.
>
> Apr 10 13:02:15 mail postfix/smtpd[24851
Postfix logs delays in fine detail including the delays of address
probe messages: time in incoming/deferred queue, time in active
queue, time to complete DNS lookup and TCP/SMTP/LMTP handshake,
time to transmit message.
Apr 10 13:02:15 mail postfix/smtpd[24851]: connect from
mycomp.mydomain.co
Halassy Zolt??n:
> So my conclusion is: The slow point could be the
> reject_unverified_recipient check, which causes a verify lookup, which
> makes an LMTP lookup, so it's either Cyrus problem, or might be
> something before that.
Postfix logs delays in fine detail including the delays of address
Hello!
I see a minor glich, doesn't hurt, just would like to know what causes it.
I am using Postfix + Cyrus, using unixsocket-LMTP transport.
I am using address verification for local destinations too (Postfix
doesn't know about the cyrus users, so it uses the LMTP to discover a
user, and reac
30 matches
Mail list logo
