Hello Peter and others,
On Sat, Nov 23, 2013 at 1:38 AM, Peter pe...@pajamian.dhs.org wrote:
On 11/23/2013 12:38 AM, Alexander Farber wrote:
/etc/postfix/header_checks:
/^To: \S+\.\S+\.\S+\.\s...@gmail.com mailto:s...@gmail.com$/i DISCARD
/etc/postfix/main.cf http://main.cf:
Alexander Farber skrev den 2013-11-23 11:08:
postmap seems not to like the whitespace after To:,
should I replace that space by s+ as workaround?
nope you dont postmap a pcre, regexp, cidr file
Please read the below article carefully. It will save you a lot of trouble.
http://www.postfix.org/SMTPD_ACCESS_README.html
On Nov 23, 2013 3:39 PM, Alexander Farber alexander.far...@gmail.com
wrote:
Hello Peter and others,
On Sat, Nov 23, 2013 at 1:38 AM, Peter pe...@pajamian.dhs.org wrote:
Does this doc really apply to my situation?
(I'd like to discard some of the mails sent out by my CMS)
On Sat, Nov 23, 2013 at 11:42 AM, tejas sarade tejas.a.sar...@gmail.comwrote:
http://www.postfix.org/SMTPD_ACCESS_README.html
Regards
Alex
Alexander Farber:
thank you! So I have moved the line
/^To: \S+\.\S+\.\S+\.\s...@gmail.com$/i DISCARD
to the file /etc/postfix/access, but when I run
That is the wrong format. As documented in access(5) this requires
an email address or domain name, not an email header.
# postmap
I would like to know current recipient restrictions. What is the output of
following command.
grep smtpd_recipient_restrictions /etc/postfix/main.cf
On Sat, Nov 23, 2013 at 4:43 PM, Alexander Farber
alexander.far...@gmail.com wrote:
Does this doc really apply to my situation?
(I'd like to
$ grep smtpd_recipient_restrictions /etc/postfix/main.cf
# through Postfix. See the smtpd_recipient_restrictions parameter
# relay mail to. See the smtpd_recipient_restrictions description in
$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory =
On Sat, Nov 23, 2013 at 9:39 PM, Alexander Farber
alexander.far...@gmail.com wrote:
$ grep smtpd_recipient_restrictions /etc/postfix/main.cf
# through Postfix. See the smtpd_recipient_restrictions parameter
# relay mail to. See the smtpd_recipient_restrictions description in
It will not
postconf |grep smtpd_recipient_restrictions
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
OK, got it.
Add the following line in main.cf file to add new recipient restriction
which will use pcre table.
smtpd_recipient_restrictions = check_recipient_access
pcre:/etc/postfix/pcre_recipients, permit_mynetworks,
reject_unauth_destination
Then create a file /etc/postfix/pcre_recipients
Am 23.11.2013 20:18, schrieb tejas sarade:
OK, got it.
Add the following line in main.cf http://main.cf file to add new recipient
restriction which will use pcre table.
smtpd_recipient_restrictions = check_recipient_access
pcre:/etc/postfix/pcre_recipients, permit_mynetworks,
On Sun, Nov 24, 2013 at 12:55 AM, li...@rhsoft.net li...@rhsoft.net wrote:
Am 23.11.2013 20:18, schrieb tejas sarade:
OK, got it.
Add the following line in main.cf http://main.cf file to add new
recipient restriction which will use pcre table.
smtpd_recipient_restrictions =
I see, thanks to you both!
The #danger doc not probably doesn't apply here, but still good to know.
On 11/23/2013 11:08 PM, Alexander Farber wrote:
thank you! So I have moved the line
/^To: \S+\.\S+\.\S+\.\s...@gmail.com mailto:s...@gmail.com$/i DISCARD
to the file /etc/postfix/access, but when I run
# postmap /etc/postfix/access
I get the warning:
postmap: warning:
On 11/24/2013 08:18 AM, tejas sarade wrote:
You can use the DISCARD instead of REJECT.
I wouldn't recommend that, unless there is a very specific reason for it
as a rule of thumb it's rarely a good idea to DISCARD mail. In this
particular case REJECT will work just fine, REJECT followed by a
On 11/24/2013 08:25 AM, li...@rhsoft.net wrote:
have fun with reject_unauth_destination too late and
check_recipient_access says PERMIT instead DUNNO
a major mistake and becuase it is made too often smtpd_relay_restrictions
was included in the lastest releases
Am 23.11.2013 22:48, schrieb Peter:
On 11/24/2013 08:25 AM, li...@rhsoft.net wrote:
have fun with reject_unauth_destination too late and
check_recipient_access says PERMIT instead DUNNO
a major mistake and becuase it is made too often smtpd_relay_restrictions
was included in the lastest
Hello,
I run a Drupal 7 website on a CentOS 6.4 server
with postfix-2.6.6-2.2.el6_1.x86_64.
In the last few months the amount of fake users trying to register at my
website has increased dramatically - I get 2 or 3 of such registrations per
minute.
Mostly they have fake mail adresses with many
Should I use smtp_header_checks here?
I have also asked the question at
http://serverfault.com/questions/556723/silently-drop-outgoing-mails-to-us-er-n-a-megmail-com-more-than-3-dots-in-user
(And I apologize for my mail being not in plain text -
I use Gmail and they have changed their interface
Am 22.11.2013 10:12, schrieb Alexander Farber:
I run a Drupal 7 website on a CentOS 6.4 server with
postfix-2.6.6-2.2.el6_1.x86_64.
In the last few months the amount of fake users trying to register at my
website has increased dramatically - I get
2 or 3 of such registrations per
On Fri, Nov 22, 2013 at 10:45 AM, li...@rhsoft.net li...@rhsoft.net wrote:
problems needs to be solved on the root cause not worked around somewhere
else
No, at the moment I am looking for the Postfix workaround.
I'd like my postfix to drop OUTGOING mail silently if addressed to
I think I'd like to use
smtp_header_checks with DISCARD action
- but http://postfix.org/header_checks.5.html says such a combination is
not supported?
Am 22.11.2013 10:48, schrieb Alexander Farber:
On Fri, Nov 22, 2013 at 10:45 AM, li...@rhsoft.net
mailto:li...@rhsoft.net li...@rhsoft.net
mailto:li...@rhsoft.net wrote:
problems needs to be solved on the root cause not worked around
somewhere else
No, at the moment I am
Hello, I know regexes well - but can't figure out, where to applly them in
Postfix, since smtp_header_checks with DISCARD action seems not to be
supported with OUTGOING mail?
On Fri, Nov 22, 2013 at 11:22 AM, Robert Schetterer r...@sys4.de wrote:
Am 22.11.2013 10:48, schrieb Alexander
Alexander Farber:
Hello, I know regexes well - but can't figure out, where to applly them in
Postfix, since smtp_header_checks with DISCARD action seems not to be
supported with OUTGOING mail?
Attack the problem at the point where mail ENTERS Postfix.
Wietse
Am 22.11.2013 12:11, schrieb Alexander Farber:
Hello, I know regexes well - but can't figure out, where to applly them
in Postfix, since smtp_header_checks with DISCARD action seems not to be
supported with OUTGOING mail?
perhaps try
restriction classes in combination with regex sender
Thanks, I agree with all general advices...
But for now I just want to stop the flood
(and also Drupal is difficult to modify for me +
I don't want to add CAPTCHA to my
already overloaded reg. form, etc., etc.).
So the following seems to work for me for now -
/etc/postfix/header_checks:
/^To:
Am 22.11.2013 12:38, schrieb Alexander Farber:
Thanks, I agree with all general advices...
But for now I just want to stop the flood
(and also Drupal is difficult to modify for me +
I don't want to add CAPTCHA to my
already overloaded reg. form, etc., etc.)
zero understanding to refuse use
I admin this website for 3 years already and
despite it being just a small obscure card game -
there haven't been a month without a challenge,
where I had to go and change something manually.
This postfix workaround is pretty perfect for now,
I enjoy looking at maillog right now and see the
Nov
my last post in this thread because we are going off-topic
discard messages on a MTA is the *last resort* if nothing
else happens but not the solution for a broken web-app
because it is the wrong layer
hence even if you insist in more than 3 dots in username part
this belong to the *web
Yes, Reindl, thanks again for all these _obvious_ advices,
while I was just asking a specific Postfix-related one.
On Fri, Nov 22, 2013 at 1:03 PM, li...@rhsoft.net li...@rhsoft.net wrote:
my last post in this thread because we are going off-topic
discard messages on a MTA is the *last
A CAPTCHA isn't going to solve your problem either, my forums have
always had a rather hard-to-solve CAPTCHA enabled, and I too get
hundreds of these registrations per day with many dots @gmail.com
That said, I agree it'd be better to stop registrations from this format
in the first place, but
On 11/22/2013 04:12 AM, Alexander Farber wrote:
Hello,
I run a Drupal 7 website on a CentOS 6.4 server
with postfix-2.6.6-2.2.el6_1.x86_64.
In the last few months the amount of fake users trying to register at my
website has increased dramatically - I get 2 or 3 of such registrations
per
I've spent last 2 hours with Drupal CAPTCHA module -
the default image and math captchas didn't stop
any spam user at all - I could see fake users
still registering - every few seconds (scary!).
I have uploaded a russian font then and configured
the CAPTCHA to use russian letters only
(since my
Am 22.11.2013 15:31, schrieb Alexander Farber:
I've spent last 2 hours with Drupal CAPTCHA module -
the default image and math captchas didn't stop
any spam user at all - I could see fake users
still registering - every few seconds (scary!).
I have uploaded a russian font then and
Yes, ok - it's my fault.
Next time I will ask a Postfix question here,
I shouldn't forget to add a disclaimer
and please no CMS or web admin advice needed ;-)
On 22 Nov 2013, at 07:42 , li...@rhsoft.net wrote:
that's why i did not name captcha only besdies that your
3 dots in username part should happen on the webserver
With gmail at least, periods in the username field are non-significant. All of
these email addresses are identical to google:
On 11/23/2013 12:38 AM, Alexander Farber wrote:
So the following seems to work for me for now -
/etc/postfix/header_checks:
/^To: \S+\.\S+\.\S+\.\s...@gmail.com mailto:s...@gmail.com$/i DISCARD
/etc/postfix/main.cf http://main.cf:
header_checks = pcre:/etc/postfix/header_checks
38 matches
Mail list logo
