postfix rocks!! :-)
working perfectly...
thanks mouss
regards,
Israel.
On Sun, Apr 18, 2010 at 12:42 AM, mouss wrote:
> Israel Garcia a écrit :
>> Hi
>> I have some apps on a debian server which use to send mail using
>> localhost on the same server and I want allow only email sent to this
>>
On 17-Apr-2010, at 22:09, Jim Carter wrote:
>
> I have recipient_delimiter = + in main.cf, but postconf -d reports that
> the variable is empty.
postconf -d will *always* report that as empty.
Have you looked at the man page for postconf -d to see what it does? (H
INT: It's not what you think)
Hi,
I am new to postfix, so sorry for any inconvenience by questions, which
may have been discussed ealready. I did google for my problem first, though.
I recently migrated an internet server including mail services for a
small group of users from linux to Mac OSX server (not my idea). On
li
On 2010-04-18 8:10 AM, Marcus Frischherz wrote:
> The spam gets filtered alright by spamassassin, and then it bounces, but
> it doesn't bounce to the actual real originator, but to the local user.
> So in this way the spammer manages to deliver the spam to the addrassee,
> although it is filtered m
Am 18.04.10 14:37, schrieb Charles Marcus:
On 2010-04-18 8:10 AM, Marcus Frischherz wrote:
The spam gets filtered alright by spamassassin, and then it bounces, but
it doesn't bounce to the actual real originator, but to the local user.
So in this way the spammer manages to deliver the spam t
Marcus Frischherz a écrit :
>[snip]
> Thanks for the link. I read it, and I realize that it is related to my
> problem. However, this link describes how to block incoming bckscatter,
> while my problem seems to be, that postfix with these settings creates
> backscatter (maybe relaying it to outside
On 2010-04-18 9:47 AM, Marcus Frischherz wrote:
>> What you are enagging in is called backscatter, and can eventually get
>> you blacklisted if your server is high enough volume:
>>
>> http://www.postfix.org/BACKSCATTER_README.html
> Thanks for the link. I read it, and I realize that it is related
Am 18.04.10 16:07, schrieb Charles Marcus:
Please show entire master.cf file...
I don't use spamassassin, so can't tell you off the top of my head how
to tell it to stop rejecting mail it detects as spam, but I'm pretty
sure it depends on how you have integrated it. Are you using amavisd-new?
El 16/04/10 23:33, John Fawcett escribió:
I've been using cbpolicyd to do rate limiting on submission port not
because I want to rate limit legitimate users, but to protect against
stolen credentials.
The approach of scanning the logfile that you outline, though not real
time like cbpolicyd wou
On Thu, Apr 15, 2010 at 1:02 AM, Gary Smith wrote:
> We use a filter to break out and run our spamassassin and other checks. In
> bash shell that process, we have a need to insert a custom unique header per
> email for compliance. Is there a simple way of doing this without having to
> go into
Following the firewall/smtp relay page
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
Process
- internal servers *send* through *my-relay*
- *my-relay* forwards to *master-relay*
- valid email is passing through for all the clients as expected.
- *master-relay* kicks back any
Hi,
I'm wondering about some messages with Received headers such as this:
Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
spam site), which resolves back to 65.182.186.12. Is this where the
problem is?
I'm
Alex:
> Hi,
>
> I'm wondering about some messages with Received headers such as this:
>
> Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
>
> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
> spam site), which resolves back to 65.182.186.12. Is this where
Following the firewall/smtp relay page
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
Process
- internal servers *send* through *my-relay*
- *my-relay* forwards to *master-relay*
- valid email is passing through for all the clients as expected.
- *master-relay* kicks back any
Hi,
>> Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
>>
>> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
>> spam site), which resolves back to 65.182.186.12. Is this where the
>> problem is?
>
> The definition of an "unknown" client hostname is given in
Alex:
> Hi,
>
> >> ? ? Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
> >>
> >> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
> >> spam site), which resolves back to 65.182.186.12. Is this where the
> >> problem is?
> >
> > The definition of an "unknown" cli
Right I am tyring to get postfix with amavisd-ng to probe and stop virus and
spam mail.
However it seems that localhost is going through without scrutiny and
some incoming e-mail is not being stopped.
postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
body_checks = reg
On Sun, Apr 18, 2010 at 01:26:49PM -0600, The Doctor wrote:
> Right I am tyring to get postfix with amavisd-ng to probe and stop
> virus and spam mail.
>
> However it seems that localhost is going through without scrutiny and
> some incoming e-mail is not being stopped.
>
> Am I missing somethin
The Doctor a écrit :
> Right I am tyring to get postfix with amavisd-ng to probe and stop virus and
> spam mail.
use amavisd-new instead of amavis-ng.
>
> However it seems that localhost is going through without scrutiny and
> some incoming e-mail is not being stopped.
>
what do you mean by "
Alex a écrit :
> Hi,
>
>>> Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
>>>
>>> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
>>> spam site), which resolves back to 65.182.186.12. Is this where the
>>> problem is?
>> The definition of an "unknown" clie
On 4/18/2010 11:21 AM, CT wrote:
Following the firewall/smtp relay page
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
Process
- internal servers *send* through *my-relay*
- *my-relay* forwards to *master-relay*
- valid email is passing through for all the clients as expected
Following the firewall/smtp relay page
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
Process
- internal servers *send* through *my-relay*
- *my-relay* forwards to *master-relay*
- valid email is passing through for all the clients as expected.
- *master-relay* kicks back an
On 4/18/2010 3:38 PM, Charles wrote:
Following the firewall/smtp relay page
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
Process
- internal servers *send* through *my-relay*
- *my-relay* forwards to *master-relay*
- valid email is passing through for all the clients as exp
Following the firewall/smtp relay page
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
Process
- internal servers *send* through *my-relay*
- *my-relay* forwards to *master-relay*
- valid email is passing through for all the clients as expected.
- *master-relay* kicks back
On 4/18/2010 4:16 PM, groups wrote:
Postfix logs help you know what happened to a particular message. Look
in your logs for bounces (sender=<>) arriving from your relayhost, and
see what postfix does with it. No need to wonder where they went.
-- Noel Jones
A lot of the send only hosts have
Noel Jones wrote, On 04/18/2010 04:20 PM:
On 4/18/2010 4:16 PM, groups wrote:
Postfix logs help you know what happened to a particular message. Look
in your logs for bounces (sender=<>) arriving from your relayhost, and
see what postfix does with it. No need to wonder where they went.
-- Noel
Hi,
>> Is it common practice to have that restriction in a production environment?
>>
>> It appears to be the third case here, that the name->address mapping
>> does not match the client IP address. Could this be from a legitimate
>> cause, or typically intentionally to be evasive?
>>
>
> since th
Alex put forth on 4/18/2010 4:45 PM:
> Is it possible to use maps_rbl_domains instead of reject_rbl_client
> here? It appears this machine has a version of postfix that doesn't
> understand reject_rbl_client.
maps_rbl_domains (default: empty)
Obsolete feature: use the reject_rbl_client featur
Hi,
> maps_rbl_domains (default: empty)
>
> Obsolete feature: use the reject_rbl_client feature instead.
Yes, that was why I was asking. It's a really old version of postfix
I'm still using on this host for now, until I can migrate to an
entirely new server and at the same time keep this one r
Thanks to Sahil Tandon and LuKreme for pointing out my mistake on the
debugging tool. I saw this done in an old archived post, and having
searched for but not found the "what to include in a problem report"
FAQ item, I winged it, incorrectly. I also forgot to specify the
version of Postfix: 2.6.
Alex:
> Hi,
>
> > maps_rbl_domains (default: empty)
> >
> > ? ?Obsolete feature: use the reject_rbl_client feature instead.
>
> Yes, that was why I was asking. It's a really old version of postfix
> I'm still using on this host for now, until I can migrate to an
> entirely new server and at the s
Note: just before sending this I went back to read the rest of
the thread, wherein I see that you're using a pre-2.0 Postfix. Some
of my advice below is thereby not relevant to this host, namely, the
suggestion to use newer syntax and the newer restriction,
reject_unknown_reverse_client_hostnam
On 4/18/2010 4:40 PM, groups wrote:
Noel Jones wrote, On 04/18/2010 04:20 PM:
On 4/18/2010 4:16 PM, groups wrote:
Postfix logs help you know what happened to a particular message. Look
in your logs for bounces (sender=<>) arriving from your relayhost, and
see what postfix does with it. No need
Hi,
> reject_unknown_client_hostname :
>> Is it common practice to have that restriction in a production
>> environment?
[...]
> Note, from the documentation suggested for you, that there are
> different conditions which trigger reject_unknown_client_hostname.
> Mine was lack of PTR, which also
On Apr 14, 2010, at 7:52 AM, Jim Wright wrote:
> On Apr 12, 2010, at 11:32 PM, Jim Wright wrote:
>
>> I'm setting up a new server completely from scratch on Snow Leopard, Mac OS
>> X 10.6.3, trying to compile Postfix 2.7. During make, I get this:
>>
>> In file included from dns_lookup.c:152:
>
On 4/18/2010 9:56 PM, /dev/rob0 wrote:
reject_unauth_pipelining,
Might catch some zombies.
Note that with older postfix (postfix < 2.6 IIRC)
reject_unauth_pipelining must be used in
smtpd_data_restrictions to be effective. It won't break
anything in smtpd_recipient_restrictions
On 4/18/2010 10:24 PM, Alex wrote:
Note, from the documentation suggested for you, that there are
different conditions which trigger reject_unknown_client_hostname.
Mine was lack of PTR, which also triggers the less aggressive
reject_unknown_reverse_client_hostname restriction. This is fairly
co
Hi,
> Note that with older postfix (postfix < 2.6 IIRC) reject_unauth_pipelining
> must be used in smtpd_data_restrictions to be effective. It won't break
> anything in smtpd_recipient_restrictions, but it won't block anything
> either.
Ah, great. I've moved it and it appears to be working (at l
Hi,
>> http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html
>>
>> It was only from a few users, but wonder what their experience is
>> almost a year later.
>
> Yes, reject_unknown_client_hostname is still too strict for us. And we're
> very strict!
Good to know. I also don't think
Alex(mysqlstud...@gmail.com)@Mon, Apr 19, 2010 at 01:11:01AM -0400:
> Hi,
>
> >> http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html
> >>
> >> It was only from a few users, but wonder what their experience is
> >> almost a year later.
> >
> > Yes, reject_unknown_client_hostname is
Alex a écrit :
> Hi,
>
>>> Is it common practice to have that restriction in a production environment?
>>>
>>> It appears to be the third case here, that the name->address mapping
>>> does not match the client IP address. Could this be from a legitimate
>>> cause, or typically intentionally to be
Alex a écrit :
> Hi,
>
>>> http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html
>>>
>>> It was only from a few users, but wonder what their experience is
>>> almost a year later.
>> Yes, reject_unknown_client_hostname is still too strict for us. And we're
>> very strict!
>
> Good
Hi,
>> I'm trying to do:
>>
>> warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net
>>
>
> wrong syntax. it's
> warn_if_reject reject_rbl_client $yourlist
> There's no 'equal' sign.
$ postfix check
postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after
attrib
Noel Jones put forth on 4/18/2010 10:55 PM:
> Yes, reject_unknown_client_hostname is still too strict for us. And
> we're very strict!
I ran with this for a short while. Had problems with it rejecting Hotmail
connections. And these weren't Hotmail user mails beings delivered, but
responses to
In our group we are using suse and
Postfix SMTP server. Every thing was fine until last month when we
restart our mail server and also firewall.
The first problem is that when we use
Thunderbird with security and Authentication it is impossible to send
a email. we receive this error “Unable to
On 04/19/2010 12:53 AM, mohamad rahimi wrote:
> a email. we receive this error Unable to authentication to SMTP
> server however , it is possible to send email without
[...]
> The error is Mail server responded
> 5.7.1 ...
It seems like you are replacing the most important part of the error
46 matches
Mail list logo
