On 01 Feb 2015, at 03:13 , li...@rhsoft.net wrote:
> if you build software from source build native packages for your OS, that
> cleans up things and avoids the system pulling the OS vendors version which
> conflicts with something below /usr/local
I normally do that, but in this case I was upgr
LuKreme:
> >> $ postfix reload
> >> postfix/postlog: fatal: bad string length 2 > 1: recipient_delimiter = +_
> >> postsuper: fatal: bad string length 2 > 1: recipient_delimiter = +_
> >> mail /etc/postfix] $ postconf recipient_delimiter mail_version
> >> recipient_delimiter = +_
> >> mail_version
Am 01.02.2015 um 10:01 schrieb LuKreme:
On Jan 31, 2015, at 9:29 PM, Bill Cole
wrote:
Which doesn't mean you don't have some other Postfix binaries lurking...
Good point.
There are files in /usr/sbin/ and in /usr/local/sbin/ and it appears that the
command directory is set to the latter,
On Jan 31, 2015, at 9:29 PM, Bill Cole
wrote:
> Which doesn't mean you don't have some other Postfix binaries lurking...
Good point.
There are files in /usr/sbin/ and in /usr/local/sbin/ and it appears that the
command directory is set to the latter, which appears to be 2.10.5
Seeing what bre
On 31 Jan 2015, at 21:10, LuKreme wrote:
On Jan 31, 2015, at 5:21 PM, Wietse Venema
wrote:
LuKreme:
On Jan 31, 2015, at 4:55 PM, LuKreme wrote:
On Jan 31, 2015, at 4:23 PM, Wietse Venema
wrote:
LuKreme:
Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1:
to=, orig_to=,
relay=do
> On Jan 31, 2015, at 5:21 PM, Wietse Venema wrote:
>
> LuKreme:
>>
>>> On Jan 31, 2015, at 4:55 PM, LuKreme wrote:
>>>
>>>
On Jan 31, 2015, at 4:23 PM, Wietse Venema wrote:
LuKreme:
> Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1:
> to=, orig_to=,
> re
LuKreme:
>
> > On Jan 31, 2015, at 4:55 PM, LuKreme wrote:
> >
> >
> >> On Jan 31, 2015, at 4:23 PM, Wietse Venema wrote:
> >>
> >> LuKreme:
> >>> Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1:
> >>> to=, orig_to=,
> >>> relay=dovecot, delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1,
> On Jan 31, 2015, at 4:55 PM, LuKreme wrote:
>
>
>> On Jan 31, 2015, at 4:23 PM, Wietse Venema wrote:
>>
>> LuKreme:
>>> Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1:
>>> to=, orig_to=, relay=dovecot,
>>> delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1, status=bounced (user unknown)
> On Jan 31, 2015, at 4:23 PM, Wietse Venema wrote:
>
> LuKreme:
>> Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1:
>> to=, orig_to=, relay=dovecot,
>> delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1, status=bounced (user unknown)
>
> That will produce backscatter. Why did you accept an
LuKreme:
> Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1:
> to=, orig_to=, relay=dovecot,
> delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1, status=bounced (user unknown)
That will produce backscatter. Why did you accept an unknown recipient?
Wietse
Am 07.05.2013 09:00, schrieb Josef Karliak:
> Ohh. So there is only one solution - on mail server generate an alias
> list that contains aliases and result. Like :
>
> chose OK
> user OK
> ...
> ...
>
>
> And in main.cf use directive
> smtpd_recipient_restrictions = ,check_recipient_access
Ohh. So there is only one solution - on mail server generate an
alias list that contains aliases and result. Like :
chose OK
user OK
...
...
And in main.cf use directive
smtpd_recipient_restrictions = ,check_recipient_access
hash:/etc/postfix/alias_list,
So we'll generate aliases
Josef Karliak:
>Hi,
>thanks for tip. I may be something missed:
>In main.cf I've added:
> address_verify_relayhost = 19.13.13.11 #ip of my mail server that
> knows all users
> address_verify_sender = mas...@mojedomena.cz
This overrides the "relayhost" setting, which is used ONLY for
Am 06.05.2013 15:08, schrieb Josef Karliak:
> communication between this incoming server and final imap server
at my knwoledge this dont work verify is done over smtp, you may ask for
relay permit ,over imap via saslauthd
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (
Hi,
thanks for tip. I may be something missed:
In main.cf I've added:
address_verify_relayhost = 19.13.13.11 #ip of my mail server that
knows all users
address_verify_sender = mas...@mojedomena.cz
communication between this incoming server and final imap server
(between them is anti
On 4/19/2013 1:28 AM, Tom Hendrikx wrote:
> Last time I read ADDRESS_VERIFICATION_README, I noticed that this isn't
> true: you can route your probes to the final delivery machine while
> leaving the current delivery mechanism intact:
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe
On 04/19/2013 12:07 AM, Stan Hoeppner wrote:
> On 4/18/2013 4:26 AM, Mikael Bak wrote:
>> Hi Josef,
>>
>> On 04/18/2013 11:06 AM, Josef Karliak wrote:
>>> Good morning,
>>> our outgoing smtp server gets into a backscatter blacklist. When I
>>> checked my logs, there were only one mailer daemon
On 4/18/2013 4:26 AM, Mikael Bak wrote:
> Hi Josef,
>
> On 04/18/2013 11:06 AM, Josef Karliak wrote:
>> Good morning,
>> our outgoing smtp server gets into a backscatter blacklist. When I
>> checked my logs, there were only one mailer daemon email to some server
>> in the time that is mentione
On 04/18/2013 12:20 PM, Josef Karliak wrote:
> Hi,
> thanks for reply. We thought that we have to copy existing "aliases"
> file from imap server to incoming MX. If we reject an emailduring smtp
> communication, we won't "relay" spam to victim. Am I right ?
> Best regards
> J.K.
>
Hi,
Ple
Hi,
thanks for reply. We thought that we have to copy existing
"aliases" file from imap server to incoming MX. If we reject an
emailduring smtp communication, we won't "relay" spam to victim. Am I
right ?
Best regards
J.K.
Cituji Mikael Bak :
Hi Josef,
On 04/18/2013 11:06 AM, Jo
Hi Josef,
On 04/18/2013 11:06 AM, Josef Karliak wrote:
> Good morning,
> our outgoing smtp server gets into a backscatter blacklist. When I
> checked my logs, there were only one mailer daemon email to some server
> in the time that is mentioned on the backscatter web.
> In all servers in th
Good morning,
our outgoing smtp server gets into a backscatter blacklist. When I
checked my logs, there were only one mailer daemon email to some
server in the time that is mentioned on the backscatter web.
In all servers in the way of the email (incoming MX->antispam
server-> our imap
Aaron Wolfe wrote:
we use a home grown policy filter for various things, I have been
thinking about adding smtp to=from checks since it's almost zero
additional resources to do. is it practical to attempt a sort of
whitelist to allow the valid cases and then block the rest? is this a
stupid id
> Message du 13/01/09 21:33
> De : "Noel Jones"
> A : "Bruno GRANDJEAN" , "postfix users list"
> Copie à :
> Objet : Re: backscattering
>
>
> Bruno GRANDJEAN wrote:
> >
> > thks for replying to me so quickly, I will ad
On Tue, Jan 13, 2009 at 3:32 PM, Noel Jones wrote:
> Bruno GRANDJEAN wrote:
>>
>> thks for replying to me so quickly, I will add a:
>> reject_rbl_client zen.spamhaus.org
>> in my /etc/postfix/main.cf
>> I already added :
>> reject_rbl_client ips.backscatterer.org
>>
>> how can I reject mail from o
Bruno GRANDJEAN a écrit :
> Relax Dr Wietse I am using another domain to post to your mailing list
This doesn't matter. it is a general principle. it was easy to guess
that orange.fr isn't your domain.
> Shame on me if I give the domain I have trouble with ;-)
well, there's nothing bad in showin
Relax Dr Wietse I am using another domain to post to your mailing list
Shame on me if I give the domain I have trouble with ;-)
bruno
> Message du 13/01/09 21:34
> De : "Wietse Venema"
> A : "Postfix users"
> Copie à :
> Objet : Re: backscattering
>
Noel Jones a écrit :
> mouss wrote:
>> Noel Jones a écrit :
>>> smtpd_data_restrictions =
>>> permit_mynetworks
>>> check_sender_access hash:/etc/postfix/no_backscatter
>>>
>>> # no_backscatter
>>> <> reject_rbl_client ips.backscatterer.org
>>>
>>> Which will reject only bounces from them (inc
mouss wrote:
Noel Jones a écrit :
smtpd_data_restrictions =
permit_mynetworks
check_sender_access hash:/etc/postfix/no_backscatter
# no_backscatter
<> reject_rbl_client ips.backscatterer.org
Which will reject only bounces from them (including legit bounces).
as well as SAV probes such
Noel Jones a écrit :
> Bruno GRANDJEAN wrote:
>>
>> thks for replying to me so quickly, I will add a:
>> reject_rbl_client zen.spamhaus.org
>> in my /etc/postfix/main.cf
>> I already added :
>> reject_rbl_client ips.backscatterer.org
>>
>> how can I reject mail from outside claiming to be from my d
Bruno GRANDJEAN:
> how can I reject mail from outside claiming to be from my domain?
>
> with a 'from:' header only in the header_checks internal users
> cannot send emails, outgoing traffic was completely blocked.
If you reject mail from outside with your address in the From: header,
then you wo
Bruno GRANDJEAN wrote:
thks for replying to me so quickly, I will add a:
reject_rbl_client zen.spamhaus.org
in my /etc/postfix/main.cf
I already added :
reject_rbl_client ips.backscatterer.org
how can I reject mail from outside claiming to be from my domain?
[plain-text only please]
[please d
s internal users cannot send
emails, outgoing traffic was completely blocked.
all the best
bruno
> Message du 13/01/09 20:47
> De : "Noel Jones"
> A : "Bruno GRANDJEAN"
> Copie à : postfix-users@postfix.org
> Objet : Re: backscattering
>
>
> Br
Bruno GRANDJEAN wrote:
Hi,
I am using a 2.3 postfix with spamassassin under freeBSD.
Actually I am trying to stop a massive backscatting attack to my smtp
server.
I followed the backscatting procedure on postfix website but it doesn't
work.
probably because this isn't backscatter...
Mess
Hi,
I am using a 2.3 postfix with spamassassin under freeBSD.
Actually I am trying to stop a massive backscatting attack to my smtp server.
I followed the backscatting procedure on postfix website but it doesn't work.
Message-ID or EHLO fields for instance are too similar to my 'normal' emails.
35 matches
Mail list logo
