Open Relay??

[Goutam Baul]

Dear List,

I am finding a large numbers of mails in the output of postqueue -p where
neither the sender nor the recipient of the mail is my user. Apparently
these mails are reaching postfix from the loop back address. I am giving the
entries for one such message from the maillog:

Feb 14 04:08:32 mail postfix/smtpd[18165]: 2F97218A856:
client=localhost[127.0.0.1]
Feb 14 04:08:32 mail postfix/cleanup[18072]: 2F97218A856:
message-id=<46929.81.199.40.34.1234564712.squir...@mail.rpg.in>
Feb 14 04:08:32 mail postfix/smtp[18164]: 1996118A851:
to=, relay=localhost[127.0.0.1], delay=0, status=sent
(250 Ok: queued as 2F97218A856)
Feb 14 04:08:32 mail postfix/qmgr[4249]: 2F97218A856:
from=, size=1203, nrcpt=1 (queue active)
Feb 14 04:08:41 mail postfix/smtp[19212]: 2F97218A856:
to=, relay=none, delay=9, status=deferred (connect to
f.mx.mail.yahoo.com[68.142.202.247]: server refused to talk to me: 421 4.7.0
[TS01] Messages from 210.212.1.111 temporarily deferred due to user
complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
Feb 14 04:30:11 mail postfix/qmgr[4249]: 2F97218A856:
from=, size=1203, nrcpt=1 (queue active)
Feb 14 04:46:06 mail postfix/qmgr[4249]: 2F97218A856:
to=, relay=none, delay=2254, status=deferred
(delivery temporarily suspended: connect to
f.mx.mail.yahoo.com[68.142.202.247]: server refused to talk to me: 421 4.7.0
[TS01] Messages from 210.212.1.111 temporarily deferred due to user
complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
Feb 14 05:36:50 mail postfix/qmgr[4249]: 2F97218A856:
from=, size=1203, nrcpt=1 (queue active)
Feb 14 05:42:07 mail postfix/qmgr[4249]: 2F97218A856:
to=, relay=none, delay=5615, status=deferred
(delivery temporarily suspended: connect to
d.mx.mail.yahoo.com[66.196.82.7]: server refused to talk to me: 421 4.7.0
[TS01] Messages from 210.212.1.111 temporarily deferred due to user
complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
Feb 14 07:00:15 mail postfix/qmgr[4249]: 2F97218A856:
from=, size=1203, nrcpt=1 (queue active)
Feb 14 07:10:43 mail postfix/qmgr[4249]: 2F97218A856:
to=, relay=none, delay=10931, status=deferred
(delivery temporarily suspended: connect to
e.mx.mail.yahoo.com[216.39.53.1]: server refused to talk to me: 421 4.7.0
[TS01] Messages from 210.212.1.111 temporarily deferred due to user
complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
Feb 14 08:23:36 mail postfix/qmgr[4249]: 2F97218A856:
from=, size=1203, nrcpt=1 (queue active)

The server is also running apache and squirrel mail for providing web access
to the users. The output of postconf -n is as follows:

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = imss:localhost:10025
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
default_destination_recipient_limit = 200
default_process_limit = 105
disable_vrfy_command = yes
fallback_transport = virtual
home_mailbox = Maildir/
inet_interfaces = all
ipc_timeout = 5000s
local_transport = maildrop
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 25728640
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
rpgnet.com
mydomain = rpg.in
myhostname = mail.rpg.in
mynetworks = 127.0.0.0/8, 10.50.0.0/16
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
rbl_reply_maps = hash:/etc/postfix/imss_rbl_reply
relay_recipient_maps = ldap:/etc/postfix/virtual-mailbox.ldap
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_client_restrictions = check_sender_access
hash:/etc/postfix/rbl_sender_exception,reject_rbl_client
ASNQWAVAPX7S683TZDZFBFUVXP56QLC.r.mail-abuse.com,reject_rbl_client
ASNQWAVAPX7S683TZDZFBFUVXP56QLC.q.mail-abuse.com
smtpd_helo_required = yes
smtpd_recipient_limit = 250
smtpd_recipient_restrictions = permit_mynetworks,
permit_auth_destination, permit_sasl_authenticated, reject
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_mynetworks,
reject_unknown_sender_domain,permit_sasl_authenticated
smtpd_tls_auth_only = no
soft_bounce = no
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = ldap:forward
virtual_gid_maps = ldap:/etc/postfix/virtual-gid.ldap
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = ldap:/etc/postfix/virtual-mailbox.ldap
virtual_minimum_uid = 5000
virtual_uid_maps = ldap:/etc/postfix/virtual-uid.ldap

We are using Trend Micro products for controlling spam and virus. At the
moment I am trying to stop these mails from entering the queue by adding the
sender address in the check_sender_access map. But as because the sen

Open Relay (???)

[Márcio Luciano Donada]

Hi People
Very strange what is happening today, so I see my server seems to be
accepting connections from outside to send e-mail, the message as shown
below (pfqueue)

5x  message_arrival_time: Tue Jul  7 05:40:57 2009


 9x  create_time: Tue Jul  7 05:40:57 2009


 9x  named_attribute: rewrite_context=local


 9x  sender: a...@mx.domain.com.br

 9x  named_attribute: log_client_name=localhost.localdomain


 8x  named_attribute: log_client_address=127.0.0.1


 8x  named_attribute:
log_message_origin=localhost.localdomain[127.0.0.1]

 8x  named_attribute: log_helo_name=localhost


 1x  named_attribute: log_protocol_name=ESMTP


 1x  named_attribute: client_name=localhost.localdomain


 1x  named_attribute: reverse_client_name=localhost.localdomain


 Dx  named_attribute: client_address=127.0.0.1


 Dx  named_attribute: helo_name=localhost


 Cx  named_attribute: client_address_type=2


 Cx  warning_message_time: Wed Dec 31 21:00:00 1969


 Cx  named_attribute:
dsn_orig_rcpt=rfc822;christiaan.s...@tickertapeparade.com

 Cx  original_recipient: christiaan.s...@tickertapeparade.com


 Bx  recipient: christiaan.s...@tickertapeparade.com


 Bx  *** MESSAGE CONTENTS deferred/9/934C4FD40B5 ***

Bx  Received: from localhost (localhost.localdomain
[127.0.0.1])

 Axby mx.domain.com.br (Postfix) with ESMTP id 934C4FD40B5

 Axfor ; Tue,  7 Jul 2009
05:40:57 -0300 (BRReceived: from mx.domain.com.br ([127.0.0.1])
 7x  Received: from mx.domain.com.br ([127.0.0.1])

 7xby localhost (mx.domain.com.br [127.0.0.1]) (amavisd-new,
port 10024)

 7xwith ESMTP id j2LDT684Xjlf for
;

 7xTue,  7 Jul 2009 05:40:57 -0300 (BRT)


6x  Received: from tlll.net (unknown [69.162.76.135])


 6xby mx.domain.com.br (Postfix) with ESMTP id C8F0DFD40A1

 4xfor ; Tue,  7 Jul 2009
05:40:56 -0300 (BRFrom: Nandinha  Cachorra  -
 x
 3x  From: Nandinha  Cachorra  - 


  x  To: "Christiaan.shep" 


  x  Subject: RE: RE: RE: RE: Video  Caseiro {Amador} SHOW!!


  x  Date: Tue, 07 Jul 09 00:22:42 Hora oficial do Brasil


  x  MIME-Version: 1.0


  x  Content-Type: multipart/mixed;boundary=
"=_NextPart_000_005F_77B064F0.D4E0EFX-Priority: 3

  x  X-Priority: 3


  x  X-MSMail-Priority: Normal


  x  X-Mailer: Microsoft Outlook Express 6.00.2462.


  x  X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.


  x  Message-Id: <20090707084056.c8f0dfd4...@mx.domain.com.br>



However, this link [1] of my test the relay server and is not open,
someone can give me a hand?

[1]. http://www.antispam-ufrj.pads.ufrj.br/

OBS: If needed I can send to my server's conf then only notify me

-- 
Márcio Luciano Donada

open relay

[Jim McIver]

Our webhosting company(which is offsite) has told me that the 
postfix-2.5 on our Freebsd 7.2 server is being used as an open relay for 
email so they have closed port 25.
We want to be able to send email from the server, but not have it relay 
for others. I've read what documentation I can find and believe I have 
it setup correctly.
Can anyone verify that the below settings should close the open 
relay...webhosting company wants verification before they will re-open 
port 25.


#postconf -n
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = loopback-only
local_transport = error:local delivery is disabled
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = lmtribune.com
mynetworks_style = host
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains =
relayhost =
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
unknown_local_recipient_reject_code = 550

thx in advance,

--
jm

Open relay

[Paul van der Vlis]

Hello,

I have a big problem, someone is using my mailserver for sending spam. I
see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when I
do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not help.
All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):

Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

As would my server sent it to my server...

Does somebody have a clou here?

With regards,
Paul van der Vlis.


Some settings and logs:

smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_sender_access hash:/etc/postfix/whitelist,
  reject_invalid_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  check_policy_service unix:private/shadelist,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  permit

smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_use_tls = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes

Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Open relay question

[Alejandro Facultad]

Dear, I'm in Internet and testing if my mail server is an Open Relay. So I 
execute:

telnet mail.mycompany.com 25

After that I do:

mail from: us...@mycompany.com
OK
rcpt to: us...@mycompany.com
OK
data
This is a test !!!
.
QUEUED

The mail from user1 to user2 (both from my company) was sent OK !!!

Is this behavior normal or is it an open relay ??? Can I sent a message from 
one 
local user to another local user, being that I come from Internet and not from 
LAN ???

Thanks a lot

A.F.


  

Re: Open Relay??

[Matt Hayes]

Goutam Baul wrote:
> Dear List,
> 
> I am finding a large numbers of mails in the output of postqueue -p where
> neither the sender nor the recipient of the mail is my user. Apparently
> these mails are reaching postfix from the loop back address. I am giving the
> entries for one such message from the maillog:
> 
> Feb 14 04:08:32 mail postfix/smtpd[18165]: 2F97218A856:
> client=localhost[127.0.0.1]
> Feb 14 04:08:32 mail postfix/cleanup[18072]: 2F97218A856:
> message-id=<46929.81.199.40.34.1234564712.squir...@mail.rpg.in>
> Feb 14 04:08:32 mail postfix/smtp[18164]: 1996118A851:
> to=, relay=localhost[127.0.0.1], delay=0, status=sent
> (250 Ok: queued as 2F97218A856)
> Feb 14 04:08:32 mail postfix/qmgr[4249]: 2F97218A856:
> from=, size=1203, nrcpt=1 (queue active)
> Feb 14 04:08:41 mail postfix/smtp[19212]: 2F97218A856:
> to=, relay=none, delay=9, status=deferred (connect to
> f.mx.mail.yahoo.com[68.142.202.247]: server refused to talk to me: 421 4.7.0
> [TS01] Messages from 210.212.1.111 temporarily deferred due to user
> complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
> Feb 14 04:30:11 mail postfix/qmgr[4249]: 2F97218A856:
> from=, size=1203, nrcpt=1 (queue active)
> Feb 14 04:46:06 mail postfix/qmgr[4249]: 2F97218A856:
> to=, relay=none, delay=2254, status=deferred
> (delivery temporarily suspended: connect to
> f.mx.mail.yahoo.com[68.142.202.247]: server refused to talk to me: 421 4.7.0
> [TS01] Messages from 210.212.1.111 temporarily deferred due to user
> complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
> Feb 14 05:36:50 mail postfix/qmgr[4249]: 2F97218A856:
> from=, size=1203, nrcpt=1 (queue active)
> Feb 14 05:42:07 mail postfix/qmgr[4249]: 2F97218A856:
> to=, relay=none, delay=5615, status=deferred
> (delivery temporarily suspended: connect to
> d.mx.mail.yahoo.com[66.196.82.7]: server refused to talk to me: 421 4.7.0
> [TS01] Messages from 210.212.1.111 temporarily deferred due to user
> complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
> Feb 14 07:00:15 mail postfix/qmgr[4249]: 2F97218A856:
> from=, size=1203, nrcpt=1 (queue active)
> Feb 14 07:10:43 mail postfix/qmgr[4249]: 2F97218A856:
> to=, relay=none, delay=10931, status=deferred
> (delivery temporarily suspended: connect to
> e.mx.mail.yahoo.com[216.39.53.1]: server refused to talk to me: 421 4.7.0
> [TS01] Messages from 210.212.1.111 temporarily deferred due to user
> complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html  )
> Feb 14 08:23:36 mail postfix/qmgr[4249]: 2F97218A856:
> from=, size=1203, nrcpt=1 (queue active)
> 
> The server is also running apache and squirrel mail for providing web access
> to the users. The output of postconf -n is as follows:
> 
> alias_database = hash:/etc/postfix/aliases
> alias_maps = hash:/etc/postfix/aliases
> broken_sasl_auth_clients = yes
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = imss:localhost:10025
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> default_destination_recipient_limit = 200
> default_process_limit = 105
> disable_vrfy_command = yes
> fallback_transport = virtual
> home_mailbox = Maildir/
> inet_interfaces = all
> ipc_timeout = 5000s
> local_transport = maildrop
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> message_size_limit = 25728640
> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
> rpgnet.com
> mydomain = rpg.in
> myhostname = mail.rpg.in
> mynetworks = 127.0.0.0/8, 10.50.0.0/16
> mynetworks_style = subnet
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> queue_directory = /var/spool/postfix
> rbl_reply_maps = hash:/etc/postfix/imss_rbl_reply
> relay_recipient_maps = ldap:/etc/postfix/virtual-mailbox.ldap
> sample_directory = /etc/postfix
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtpd_client_restrictions = check_sender_access
> hash:/etc/postfix/rbl_sender_exception,reject_rbl_client
> ASNQWAVAPX7S683TZDZFBFUVXP56QLC.r.mail-abuse.com,reject_rbl_client
> ASNQWAVAPX7S683TZDZFBFUVXP56QLC.q.mail-abuse.com
> smtpd_helo_required = yes
> smtpd_recipient_limit = 250
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_auth_destination, permit_sasl_authenticated, reject
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_local_domain = $myhostname
> smtpd_sasl_security_options = noanonymous
> smtpd_sender_restrictions = permit_mynetworks,
> reject_unknown_sender_domain,permit_sasl_authenticated
> smtpd_tls_auth_only = no
> soft_bounce = no
> transport_maps = hash:/etc/postfix/transport
> unknown_local_recipient_reject_code = 550
> virtual_alias_maps = ldap:forward
> virtual_gid_maps = ldap:/etc/postfix/virtual-gid.ldap
> virtual_mailbox_base = /home/vmail
> virtual_mailbox_maps = ldap:/etc/postfix/virtual-mailbox.ldap
> virtual_minimum_uid = 5000
> virtual_uid_maps = ldap:/etc/postfix/vi

Re: Open Relay??

[Sahil Tandon]

On Sat, 14 Feb 2009, Goutam Baul wrote:

> I am finding a large numbers of mails in the output of postqueue -p where
> neither the sender nor the recipient of the mail is my user. Apparently
> these mails are reaching postfix from the loop back address. I am giving the
> entries for one such message from the maillog:
> 
> Feb 14 04:08:32 mail postfix/smtpd[18165]: 2F97218A856:
> client=localhost[127.0.0.1]
> Feb 14 04:08:32 mail postfix/cleanup[18072]: 2F97218A856:
> message-id=<46929.81.199.40.34.1234564712.squir...@mail.rpg.in>

Do you control http://mail.rpg.in?  Check the logs there.

-- 
Sahil Tandon 

Re: Open Relay (???)

[Terry Carmen]

> Hi People
> Very strange what is happening today, so I see my server seems to be
> accepting connections from outside to send e-mail, the message as shown
> below (pfqueue)
>
> 5x  message_arrival_time: Tue Jul  7 05:40:57 2009
>
>
>  9x  create_time: Tue Jul  7 05:40:57 2009
>

Please post the output from postconf -n, as well as a section of
/var/log/maillog showing the messages being relayed.

Terry

Re: Open Relay (???)

[Márcio Luciano Donada]

Terry Carmen escreveu:
>> Hi People
>> Very strange what is happening today, so I see my server seems to be
>> accepting connections from outside to send e-mail, the message as shown
>> below (pfqueue)
>>
>> 5x  message_arrival_time: Tue Jul  7 05:40:57 2009
>>
>>
>>  9x  create_time: Tue Jul  7 05:40:57 2009
>>
> 
> Please post the output from postconf -n, as well as a section of
> /var/log/maillog showing the messages being relayed.
> 
> Terry
> 
> 
> 

Terry,
Thank for replay, main.cf:

alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap/ldap-aliases.cf,
hash:/var/lib/mailman/data/aliases
anvil_rate_time_unit = 60s
biff = no
body_checks = regexp:/etc/postfix/malware/mbl-body-deny
bounce_queue_lifetime = 1d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
command_time_limit = 1h
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
default_destination_concurrency_limit = 25
default_destination_recipient_limit = 25
default_process_limit = 200
delay_warning_time = 4h
disable_vrfy_command = yes
empty_address_recipient = MAILER-DAEMON
header_checks = regexp:/etc/postfix/maps/header_checks.cf
home_mailbox = Maildir/
inet_protocols = all
local_destination_concurrency_limit = 5
local_recipient_maps = unix:passwd.byname,
ldap:/etc/postfix/ldap/ldap.cf, $alias_maps
mailbox_command = /usr/bin/procmail -p -t -m /etc/procmailrc
mailq_path = /usr/bin/mailq
masquerade_domains =
maximal_backoff_time = 480s
maximal_queue_lifetime = 1d
message_size_limit = 1524
minimal_backoff_time = 240s
mydestination = $myhostname, localhost.$mydomain, $mydomain
mydomain = domain.com.br
myhostname = mx.domain.com.br
mynetworks = 127.0.0.0/8
newaliases_path = /usr/bin/newaliases
owner_request_special = no
qmgr_message_active_limit = 4
qmgr_message_recipient_limit = 4
queue_run_delay = 480s
rbl_reply_maps = hash:/etc/postfix/rbl/rbl_reply_maps
recipient_bcc_maps =
hash:/etc/postfix/monitoramento/recebimento_bcc_email.cf
recipient_delimiter = +
relay_domains = $mydestination
sender_bcc_maps = hash:/etc/postfix/monitoramento/envio_bcc_email.cf
sender_canonical_maps = hash:/etc/postfix/sender_canonical.cf
sendmail_path = /usr/sbin/sendmail
show_user_unknown_table_name = no
smtp_connect_timeout = 60s
smtp_connection_cache_on_demand = yes
smtp_connection_cache_time_limit = 60s
smtp_destination_concurrency_limit = 25
smtp_mx_session_limit = 100
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 20
smtpd_client_event_limit_exceptions = 127.0.0.1
smtpd_client_restrictions = check_client_access
hash:/etc/postfix/maps/access
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_etrn_restrictions = reject
smtpd_hard_error_limit = 100
smtpd_helo_required = yes
smtpd_junk_command_limit = 3
smtpd_recipient_limit = 12
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/maps/user-qa.cf,
reject_non_fqdn_recipient
,  reject_unknown_recipient_domain,
   permit_sasl_authenticated,  p
ermit_mynetworks,
reject_unauth_destination,
reject_unlisted_recipient,
  check_recipient_access
pcre:/etc/postfix/postgrey/greylist_sender_exceptions,
  check_client_access cidr:/etc/pos
tfix/postgrey/greylist_network_exceptions,
check_client_access pcre:/etc/postfix/postgrey/check_client_fqdn,
  check_client_access hash:/etc/postfix/maps/client_whitelist,
   check_policy_service inet:127.0.0.1:12525,
  check_policy_service unix:private/policy,
reject_sender_login_mismatch,   check_policy_serv
ice inet:127.0.0.1:6,  reject_rbl_client
zen.spamhaus.org=127.0.0.10,  reject_rbl_client
 zen.spamhaus.org=127.0.0.11,  reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spam
cop.net,   permit
smtpd_restriction_classes = reject_if_sender_domain_match, check_greylist
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = check_client_access
hash:/etc/postfix/maps/sender_access,
permit_sasl_authenticated,
   check_sender_access hash:/etc/postfix/maps/sender,
reject_sender_login_mismatch,   reject_unlis
ted_recipient,  reject_non_fqdn_sender,
reject_unknown_sender_domain,   reje
ct_unauth_destination,  warn_if_reject,
permit
smtpd_soft_error_limit = 10
smtpd_timeout = 70s
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.cert
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_r

Re: Open Relay (???)

[Terry Carmen]

> Jul  7 17:54:01 mx postfix/smtpd[31079]: disconnect from
> localhost.localdomain[127.0.0.1]


It looks like the mail is coming from a process running on your server
(localhost).

Do you host any websites, run webmail or have any local users?

If you're lucky, the "cleanup" line will contain a message id that give a clue
as to it's creator. For example, this shows a message that came from
squirrelmail.

Jul  7 16:41:05 wormhole postfix/cleanup[27697]: 50237503FB:
message-id=


Terry

Re: Open Relay (???)

[Victor Duchovni]

On Tue, Jul 07, 2009 at 05:24:02PM -0400, Terry Carmen wrote:

> > Jul  7 17:54:01 mx postfix/smtpd[31079]: disconnect from
> > localhost.localdomain[127.0.0.1]
> 
> 
> It looks like the mail is coming from a process running on your server
> (localhost).

No, the OP is just reporting the wrong part of the message's history
on his server. The logs of the message entering the system are required,
not logs of downstream processing in content_filters...

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Open Relay (???)

[Ralf Hildebrandt]

* Márcio Luciano Donada :

> command_time_limit = 1h
Why change this?

> inet_protocols = all
Default, why set this explicitly?

> mydomain = domain.com.br
> myhostname = mx.domain.com.br

Setting myhostname to mx.domain.com.br implies mydomain = domain.com.br

> relay_domains = $mydestination
You can probably set:
relay_domains =

> smtpd_banner = $myhostname ESMTP
Default, why set this explicitly?

> smtpd_client_restrictions = check_client_access hash:/etc/postfix/maps/access
What's in here?

> smtpd_delay_reject = yes
Default, why set this explicitly?

> smtpd_recipient_limit = 12
Way too low. The default is fine.

> smtpd_recipient_restrictions = 
>   check_recipient_access hash:/etc/postfix/maps/user-qa.cf,
>   reject_non_fqdn_recipient , 
>   reject_unknown_recipient_domain,
>   permit_sasl_authenticated, 
>   permit_mynetworks,
>   reject_unauth_destination,

This is not an open relay unless /etc/postfix/maps/user-qa.cf contains
some strange entries. Please show it.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: open relay

[Wietse Venema]

Jim McIver:
> Our webhosting company(which is offsite) has told me that the 
> postfix-2.5 on our Freebsd 7.2 server is being used as an open relay for 
> email so they have closed port 25.
> We want to be able to send email from the server, but not have it relay 
> for others. I've read what documentation I can find and believe I have 
> it setup correctly.
> Can anyone verify that the below settings should close the open 
> relay...webhosting company wants verification before they will re-open 
> port 25.

What is their definition of open relay? There are tons of ways that
a server can be mis-used to send spam that have nothing to do with
SMTP configuration.

Wietse

Re: open relay

[Reindl Harald]

How should they?

You do not specify any restrictions or valid addresses
This looks like a basic setup which must never see the internet

smtpd_recipient_restrictions = permit_mynetworks
 reject_non_fqdn_recipient
 reject_non_fqdn_sender
 reject_unlisted_sender
 permit_sasl_authenticated
 reject_unauth_destination
 reject_unknown_sender_domain
 reject_unknown_recipient_domain
 reject_invalid_hostname
 reject_unauth_pipelining

but you have to configure SASL-Authentication and read some manuals

Am 31.03.2011 17:28, schrieb Jim McIver:
> Our webhosting company(which is offsite) has told me that the postfix-2.5 on 
> our Freebsd 7.2 server is being used
> as an open relay for email so they have closed port 25.
> We want to be able to send email from the server, but not have it relay for 
> others. I've read what documentation I
> can find and believe I have it setup correctly.
> Can anyone verify that the below settings should close the open 
> relay...webhosting company wants verification
> before they will re-open port 25.
> 
> #postconf -n
> command_directory = /usr/local/sbin
> config_directory = /usr/local/etc/postfix
> daemon_directory = /usr/local/libexec/postfix
> data_directory = /var/db/postfix
> debug_peer_level = 2
> html_directory = no
> inet_interfaces = loopback-only
> local_transport = error:local delivery is disabled
> mail_owner = postfix
> mailq_path = /usr/local/bin/mailq
> manpage_directory = /usr/local/man
> mydestination = $myhostname, localhost.$mydomain, localhost
> mydomain = lmtribune.com
> mynetworks_style = host
> myorigin = $mydomain
> newaliases_path = /usr/local/bin/newaliases
> queue_directory = /var/spool/postfix
> readme_directory = no
> relay_domains =
> relayhost =
> sample_directory = /usr/local/etc/postfix
> sendmail_path = /usr/local/sbin/sendmail
> setgid_group = maildrop
> unknown_local_recipient_reject_code = 550
> 
> thx in advance,
> 

-- 

Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/



signature.asc
Description: OpenPGP digital signature

Re: open relay

[Victor Duchovni]

On Thu, Mar 31, 2011 at 08:28:08AM -0700, Jim McIver wrote:

> Our webhosting company(which is offsite) has told me that the postfix-2.5 
> on our Freebsd 7.2 server is being used as an open relay for email so they 
> have closed port 25.

Logs of a message that failed to be rejected?

> #postconf -n
> command_directory = /usr/local/sbin
> config_directory = /usr/local/etc/postfix
> daemon_directory = /usr/local/libexec/postfix
> data_directory = /var/db/postfix
> debug_peer_level = 2
> html_directory = no
> inet_interfaces = loopback-only

With this set, and no additional SMTP listeners in master.cf, you don't
accept any external SMTP traffic on port 25, so you can't be an open
relay. However, you may have vulnerable CGI scripts that allow external
users to send email to arbitrary destinations by filling in forms...

Audit your CGI web forms.

> local_transport = error:local delivery is disabled
> mail_owner = postfix
> mailq_path = /usr/local/bin/mailq
> manpage_directory = /usr/local/man
> mydestination = $myhostname, localhost.$mydomain, localhost
> mydomain = lmtribune.com
> mynetworks_style = host
> myorigin = $mydomain
> newaliases_path = /usr/local/bin/newaliases
> queue_directory = /var/spool/postfix
> readme_directory = no
> relay_domains =
> relayhost =
> sample_directory = /usr/local/etc/postfix
> sendmail_path = /usr/local/sbin/sendmail
> setgid_group = maildrop
> unknown_local_recipient_reject_code = 550

This Postfix configuration is not an open relay.

-- 
Viktor.

RE: Open relay

[Fazzina, Angelo]

So what is SASL using in Postfix ?
Is Postfix calling SASL, which calls PAM, which calls LDAP, to check the 
Password?


You must follow the trail of how they got the password if you say you changed 
it and it does not help.
-ALF

-Angelo Fazzina
Operating Systems Programmer / Analyst 
University of Connecticut,  UITS, SSG-Linux/ M&C
860-486-9075

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Paul van der Vlis
Sent: Friday, October 21, 2016 4:16 PM
To: postfix-users@postfix.org
Subject: Open relay

Hello,

I have a big problem, someone is using my mailserver for sending spam. I
see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when I
do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not help.
All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):

Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

As would my server sent it to my server...

Does somebody have a clou here?

With regards,
Paul van der Vlis.


Some settings and logs:

smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_sender_access hash:/etc/postfix/whitelist,
  reject_invalid_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  check_policy_service unix:private/shadelist,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  permit

smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_use_tls = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes

Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[Paul van der Vlis]

Hello Angelo and others,

Op 21-10-16 om 22:24 schreef Fazzina, Angelo:
> So what is SASL using in Postfix ?
> Is Postfix calling SASL, which calls PAM, which calls LDAP, to check the 
> Password?

Postfix is calling saslauthd, which calls PAM, which calls unix passwords.

> You must follow the trail of how they got the password if you say you changed 
> it and it does not help.

I don't think they have a correct username/password combination, because
the username is wrong.

Maybe it's possible to log the username/password Postfix get?

Maybe they are using some kind of trick to let Postfix think the mail
comes from localhost.

With regards,
Paul van der Vlis.


> -ALF
> 
> -Angelo Fazzina
> Operating Systems Programmer / Analyst 
> University of Connecticut,  UITS, SSG-Linux/ M&C
> 860-486-9075
> 
> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Paul van der Vlis
> Sent: Friday, October 21, 2016 4:16 PM
> To: postfix-users@postfix.org
> Subject: Open relay
> 
> Hello,
> 
> I have a big problem, someone is using my mailserver for sending spam. I
> see it in de logs. I can block the IP but then they use other IP's.
> 
> So far I know my server is up-to-date and correct configured. And when I
> do some open relay tests, everything is OK. Like this ones:
> http://www.mailradar.com/openrelay/
> http://mxtoolbox.com/diagnostic.aspx
> 
> The name of my mailserver is mail.vandervlis.nl, so far I see the
> spammers are using port 587. Please feel free to do tests.
> 
> What I see in the logs and in the headers of the spam is that they are
> using authentication. But the username is not correct. On my server I
> use usernames like "john", and this username lookslike an e-mail
> address, so with an "@" in it. The part before the @ is a correct
> username on my server, but when I change the password it does not help.
> All spam is recognizeble by this authenticated username.
> 
> In the headers I see this as the first "received" (I've changed the
> authenticated sender for privacy):
> 
> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
> (Authenticated sender: p...@puk.nl)
> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> 
> As would my server sent it to my server...
> 
> Does somebody have a clou here?
> 
> With regards,
> Paul van der Vlis.
> 
> 
> Some settings and logs:
> 
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   check_sender_access hash:/etc/postfix/whitelist,
>   reject_invalid_hostname,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_pipelining,
>   reject_unauth_destination,
>   check_policy_service unix:private/shadelist,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client zen.spamhaus.org,
>   reject_rbl_client ix.dnsbl.manitu.net,
>   permit
> 
> smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
> smtpd_use_tls = yes
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_exceptions_networks = $mynetworks
> smtpd_tls_loglevel = 1
> smtpd_tls_auth_only = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_tls_security_options = noanonymous
> broken_sasl_auth_clients = yes
> smtpd_sasl_authenticated_header = yes
> 
> Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
> client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl
> 
> 



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[li...@lazygranch.com]

On Fri, 21 Oct 2016 22:56:45 +0200
Paul van der Vlis  wrote:

> Hello Angelo and others,
> 
> Op 21-10-16 om 22:24 schreef Fazzina, Angelo:
> > So what is SASL using in Postfix ?
> > Is Postfix calling SASL, which calls PAM, which calls LDAP, to
> > check the Password?
> 
> Postfix is calling saslauthd, which calls PAM, which calls unix
> passwords.
> 
> > You must follow the trail of how they got the password if you say
> > you changed it and it does not help.
> 
> I don't think they have a correct username/password combination,
> because the username is wrong.
> 
> Maybe it's possible to log the username/password Postfix get?
> 
> Maybe they are using some kind of trick to let Postfix think the mail
> comes from localhost.
> 
> With regards,
> Paul van der Vlis.
> 
> 
> > -ALF
> > 
> > -Angelo Fazzina
> > Operating Systems Programmer / Analyst 
> > University of Connecticut,  UITS, SSG-Linux/ M&C
> > 860-486-9075
> > 
> > -Original Message-
> > From: owner-postfix-us...@postfix.org
> > [mailto:owner-postfix-us...@postfix.org] On Behalf Of Paul van der
> > Vlis Sent: Friday, October 21, 2016 4:16 PM To:
> > postfix-users@postfix.org Subject: Open relay
> > 
> > Hello,
> > 
> > I have a big problem, someone is using my mailserver for sending
> > spam. I see it in de logs. I can block the IP but then they use
> > other IP's.
> > 
> > So far I know my server is up-to-date and correct configured. And
> > when I do some open relay tests, everything is OK. Like this ones:
> > http://www.mailradar.com/openrelay/
> > http://mxtoolbox.com/diagnostic.aspx
> > 
> > The name of my mailserver is mail.vandervlis.nl, so far I see the
> > spammers are using port 587. Please feel free to do tests.
> > 
> > What I see in the logs and in the headers of the spam is that they
> > are using authentication. But the username is not correct. On my
> > server I use usernames like "john", and this username lookslike an
> > e-mail address, so with an "@" in it. The part before the @ is a
> > correct username on my server, but when I change the password it
> > does not help. All spam is recognizeble by this authenticated
> > username.
> > 
> > In the headers I see this as the first "received" (I've changed the
> > authenticated sender for privacy):
> > 
> > Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> > [87.92.55.206]) (Authenticated sender: p...@puk.nl)
> > by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> > Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> > 
> > As would my server sent it to my server...
> > 
> > Does somebody have a clou here?
> > 
> > With regards,
> > Paul van der Vlis.
> > 
> > 
> > Some settings and logs:
> > 
> > smtpd_relay_restrictions =
> >   permit_mynetworks,
> >   permit_sasl_authenticated,
> >   check_sender_access hash:/etc/postfix/whitelist,
> >   reject_invalid_hostname,
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >   reject_unknown_sender_domain,
> >   reject_unknown_recipient_domain,
> >   reject_unauth_pipelining,
> >   reject_unauth_destination,
> >   check_policy_service unix:private/shadelist,
> >   reject_rbl_client bl.spamcop.net,
> >   reject_rbl_client zen.spamhaus.org,
> >   reject_rbl_client ix.dnsbl.manitu.net,
> >   permit
> > 
> > smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
> > smtpd_use_tls = yes
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_exceptions_networks = $mynetworks
> > smtpd_tls_loglevel = 1
> > smtpd_tls_auth_only = yes
> > smtpd_sasl_security_options = noanonymous
> > smtpd_sasl_tls_security_options = noanonymous
> > broken_sasl_auth_clients = yes
> > smtpd_sasl_authenticated_header = yes
> > 
> > Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
> > client=unknown[94.26.41.188], sasl_method=PLAIN,
> > sasl_username=p...@puk.nl
> > 
> > 
> 
> 
> 

Perhaps I'm being a bit anal here, and given my skill level (or lack
thereof) I should stay of of this, but is this actually an open relay in
the strict sense? Maybe that is a red herring. If they are using 587,
that would be the master.cf file, not main.cf.

submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
 

Re: Open relay

[Wietse Venema]

Paul van der Vlis:
> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
> (Authenticated sender: p...@puk.nl)
> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

That is NOT RELAYING. That is receiving mail from a process that
runs on the same machine. This can happen when the machine runs a
bad web application.

Wietse

Re: Open relay

[Bill Cole]

On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:


Hello,

I have a big problem, someone is using my mailserver for sending spam. 
I

see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when 
I

do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not 
help.

All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):

Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi 
[87.92.55.206])

(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

As would my server sent it to my server...


Not exactly. That Received header indicates that the machine at 
87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi 
introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
proceeded to authenticate as the user whose name you've replaced with  
p...@puk.nl.


As a stopgap, you could add a directive like this to 
smtpd_helo_restrictions:


   check_helo_access pcre:/etc/postfix/helo_checks

And in that helo_checks file;

/127\.0\.0\.1/  REJECT you are not me


This will catch and reject formally correct IP literals as in this case 
and the more common bare IP form of claiming to be localhost. There's no 
reason for any mail client ever to say "EHLO [127.0.0.1]" except to 
cause a MTA to generate a confusing Received header.



Does somebody have a clou here?

With regards,
Paul van der Vlis.

Some settings and logs:


Those are inadequate to understand this problem.

See the bottom part of the Postfix DEBUG_README file, probably installed 
on your machine with Postfix (maybe in both plaintext and HTML) and 
always available on the Postfix website. It describes what information 
is needed to effectively get help here. The welcome message you got when 
you subscribed this list also referenced that document.


Paraphrasing the DEBUG_README and adapting its recommendations to this 
issue, you should include:


Full 'postconf -nf' output
Full 'postconf -Mf' output
Full headers of a sample spam message, redacted only to protect *USER* 
privacy. (Don't redact hostnames or IPs)
All log lines containing the Postfix queue id of the sample spam 
message.
If your SASL layer logs authentication successes and failures (perhaps 
in /var/log/auth.log) find the relevant log entries for the sample 
message.


There is no need for verbose logging by Postfix.

Re: Open relay

[Tomoyuki Murakami]

On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis  
wrote:
> Hello,

> Some settings and logs:
>
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   check_sender_access hash:/etc/postfix/whitelist,
>   reject_invalid_hostname,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_pipelining,
>   reject_unauth_destination,
>   check_policy_service unix:private/shadelist,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client zen.spamhaus.org,
>   reject_rbl_client ix.dnsbl.manitu.net,
>   permit

permit after all ?


pgpOWB99LbM2E.pgp
Description: PGP signature

Re: Open relay

[Christian Kivalo]

Am 22. Oktober 2016 08:18:36 MESZ, schrieb Tomoyuki Murakami 
:
>
>On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis
> wrote:
>> Hello,
>
>> Some settings and logs:
>>
>> smtpd_relay_restrictions =
>>   permit_mynetworks,
>>   permit_sasl_authenticated,
>>   check_sender_access hash:/etc/postfix/whitelist,
>>   reject_invalid_hostname,
>>   reject_non_fqdn_sender,
>>   reject_non_fqdn_recipient,
>>   reject_unknown_sender_domain,
>>   reject_unknown_recipient_domain,
>>   reject_unauth_pipelining,
>>   reject_unauth_destination,
>>   check_policy_service unix:private/shadelist,
>>   reject_rbl_client bl.spamcop.net,
>>   reject_rbl_client zen.spamhaus.org,
>>   reject_rbl_client ix.dnsbl.manitu.net,
>>   permit
>
>permit after all ?

Yes.

- Permit the stuff that shouldn't be rejected (mynetworks, sasl authenticated)
- Perform various checks and reject the things you don't like
- Permit everything that made it through that obstacle course

-- 
Christian Kivalo

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 01:31 schreef li...@lazygranch.com:
> Perhaps I'm being a bit anal here, and given my skill level (or lack
> thereof) I should stay of of this, but is this actually an open relay in
> the strict sense? Maybe that is a red herring. If they are using 587,
> that would be the master.cf file, not main.cf.
> 
> submission inet n   -   n   -   -   smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_reject_unlisted_recipient=no
>   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
>   -o milter_macro_daemon_name=ORIGINATING

This is the only thing what I have:
submission inet n  -   -   -   -   smtpd

Is this wrong?

I would like it to set rules for every port separate, but I didn't do it
till now.

With regards,
Paul van der Vlis.



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 01:46 schreef Wietse Venema:
> Paul van der Vlis:
>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
>> (Authenticated sender: p...@puk.nl)
>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> 
> That is NOT RELAYING. That is receiving mail from a process that
> runs on the same machine. This can happen when the machine runs a
> bad web application.

Thank you for your help!

Receiving mail from a web application is something what I have checked,
but I did not found anything in the Apache logs. And I see traffic on
port 587 from bad IP's when I log the firewall. I did also turn off
Apache for a while, and I still saw spam coming in. I will investigate
further, there are 3 web applications running on the machine.

What I did yesterday night what stopped the spam, is blocking the mail
from a specific sender (p...@puk.nl in my example) using
check_sender_access:

smtpd_recipient_restrictions =
permit_mynetworks,
check_sender_access hash:/etc/postfix/sender_access,
permit_sasl_authenticated,
(...)

The strange thing is that the username they use for authentication
(p...@puk.nl) is not a correct username. So maybe they will come in some
time later with another fake-username...

With regards,
Paul van der Vlis.

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 08:18 schreef Tomoyuki Murakami:
> 
> On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis  
> wrote:
>> Hello,
> 
>> Some settings and logs:
>>
>> smtpd_relay_restrictions =
>>   permit_mynetworks,
>>   permit_sasl_authenticated,
>>   check_sender_access hash:/etc/postfix/whitelist,
>>   reject_invalid_hostname,
>>   reject_non_fqdn_sender,
>>   reject_non_fqdn_recipient,
>>   reject_unknown_sender_domain,
>>   reject_unknown_recipient_domain,
>>   reject_unauth_pipelining,
>>   reject_unauth_destination,
>>   check_policy_service unix:private/shadelist,
>>   reject_rbl_client bl.spamcop.net,
>>   reject_rbl_client zen.spamhaus.org,
>>   reject_rbl_client ix.dnsbl.manitu.net,
>>   permit
> 
> permit after all ?

Yes, I looked at it yesterday, and I am not sure about it. But I am
using this kind of setup allready for a really long time (16 years?), so
I think it will be right.

But maybe I don't understand the logic completely, and do I have to
study more on the "firewall rules logic of Postfix".

With regards,
Paul van der Vlis.





-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/



signature.asc
Description: OpenPGP digital signature

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 04:32 schreef Bill Cole:
> On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:

>> 
>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
>> [87.92.55.206])
>> (Authenticated sender: p...@puk.nl)
>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>> 
>> As would my server sent it to my server...
> 
> Not exactly. That Received header indicates that the machine at
> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
> proceeded to authenticate as the user whose name you've replaced with 
> p...@puk.nl.
> 
> As a stopgap, you could add a directive like this to
> smtpd_helo_restrictions:
> 
>check_helo_access pcre:/etc/postfix/helo_checks
> 
> And in that helo_checks file;
> 
> /127\.0\.0\.1/REJECT you are not me

Thanks, a great idea to have standard in most cases.

> This will catch and reject formally correct IP literals as in this case
> and the more common bare IP form of claiming to be localhost. There's no
> reason for any mail client ever to say "EHLO [127.0.0.1]" except to
> cause a MTA to generate a confusing Received header.

Right.

With regards,
Paul van der Vlis.


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[Wietse Venema]

Bill Cole:
> > Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi 
> > [87.92.55.206])
> > (Authenticated sender: p...@puk.nl)
> > by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> > Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> > 
> > As would my server sent it to my server...
> 
> Not exactly. That Received header indicates that the machine at 
> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi 
> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
> proceeded to authenticate as the user whose name you've replaced with  
> p...@puk.nl.

Thanks, I missed that.

Wietse

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 13:41 schreef Wietse Venema:
> Bill Cole:
>>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi 
>>> [87.92.55.206])
>>> (Authenticated sender: p...@puk.nl)
>>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>>> 
>>> As would my server sent it to my server...
>>
>> Not exactly. That Received header indicates that the machine at 
>> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi 
>> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
>> proceeded to authenticate as the user whose name you've replaced with  
>> p...@puk.nl.
> 
> Thanks, I missed that.

Is the conclusion now, that Postfix is relaying here?

With regards,
Paul van der Vlis.



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[Repost]

On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:
> Op 22-10-16 om 13:41 schreef Wietse Venema:
> > Bill Cole:
> >>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> >>> [87.92.55.206])
> >>> (Authenticated sender: p...@puk.nl)
> >>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> >>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> >>> 
> >>> As would my server sent it to my server...
> >>
> >> Not exactly. That Received header indicates that the machine at
> >> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
> >> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
> >> proceeded to authenticate as the user whose name you've replaced with
> >> p...@puk.nl.
> >
> > Thanks, I missed that.
>
> Is the conclusion now, that Postfix is relaying here?
>


Reposting what was allready in this thread

| > As a stopgap, you could add a directive like this to
| > smtpd_helo_restrictions:
| >
| >check_helo_access pcre:/etc/postfix/helo_checks
| >
| > And in that helo_checks file;
| >
| > /127\.0\.0\.1/REJECT you are not me
|
| Thanks, a great idea to have standard in most cases.
|
| > This will catch and reject formally correct IP literals as in this case
| > and the more common bare IP form of claiming to be localhost. There's no
| > reason for any mail client ever to say "EHLO [127.0.0.1]" except to
| > cause a MTA to generate a confusing Received header.
|
| Right.

Re: Open relay

[Paul Schmehl]

--On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis 
 wrote:



Op 22-10-16 om 04:32 schreef Bill Cole:

On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:




Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
[87.92.55.206])
(Authenticated sender: p...@puk.nl)
by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

As would my server sent it to my server...


Not exactly. That Received header indicates that the machine at
87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
proceeded to authenticate as the user whose name you've replaced with
p...@puk.nl.

As a stopgap, you could add a directive like this to
smtpd_helo_restrictions:

   check_helo_access pcre:/etc/postfix/helo_checks

And in that helo_checks file;

/127\.0\.0\.1/REJECT you are not me


Thanks, a great idea to have standard in most cases.


I would make one suggestion.  I would reject the attempt silently.  No 
sense in tipping off the spammer to what he needs to do to work around it. 
Just use REJECT with no explanation.


"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher

Re: Open relay

[/dev/rob0]

On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:
> Op 22-10-16 om 13:41 schreef Wietse Venema:
> > Bill Cole:
> >>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi 
> >>> [87.92.55.206])
> >>> (Authenticated sender: p...@puk.nl)
> >>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> >>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> >>> 
> >>> As would my server sent it to my server...
> >>
> >> Not exactly. That Received header indicates that the machine
> >> T 87.92.55.206 which is actually named 
> >> 87-92-55-206.bb.dnainternet.fi introduced itself with "EHLO 
> >> [127.0.0.1]" on an encrypted session and proceeded to 
> >> authenticate as the user whose name you've replaced with 
> >> p...@puk.nl.
> > 
> > Thanks, I missed that.
> 
> Is the conclusion now, that Postfix is relaying here?

The only actual conclusion is that you have failed to put forth the 
necessary information, as Bill [I think] pointed you to the 
http://www.postfix.org/DEBUG_README.html#mail link.

What appears to be most likely, if we were given adequate 
information, is that an account has been compromised, and a botnet 
uses those credentials to relay spam through you.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

SV: Open relay

[Sebastian Nielsen]

Or even better: Accept the mail, but toss it away. Eg use, DISCARD instead.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Paul Schmehl
Skickat: den 22 oktober 2016 18:20
Till: Paul van der Vlis ; postfix-users@postfix.org
Ämne: Re: Open relay

--On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis
 wrote:

> Op 22-10-16 om 04:32 schreef Bill Cole:
>> On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:
>
>>> 
>>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
>>> [87.92.55.206])
>>> (Authenticated sender: p...@puk.nl)
>>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>>> 
>>> As would my server sent it to my server...
>>
>> Not exactly. That Received header indicates that the machine at
>> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi 
>> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and 
>> proceeded to authenticate as the user whose name you've replaced with 
>> p...@puk.nl.
>>
>> As a stopgap, you could add a directive like this to
>> smtpd_helo_restrictions:
>>
>>check_helo_access pcre:/etc/postfix/helo_checks
>>
>> And in that helo_checks file;
>>
>> /127\.0\.0\.1/REJECT you are not me
>
> Thanks, a great idea to have standard in most cases.

I would make one suggestion.  I would reject the attempt silently.  No sense
in tipping off the spammer to what he needs to do to work around it. 
Just use REJECT with no explanation.

"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Open relay

[/dev/rob0]

On Sat, Oct 22, 2016 at 11:19:36AM -0500, Paul Schmehl wrote:
> --On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis
>  wrote:
> >Op 22-10-16 om 04:32 schreef Bill Cole:
> >>/127\.0\.0\.1/REJECT you are not me
> >
> >Thanks, a great idea to have standard in most cases.
> 
> I would make one suggestion.  I would reject the attempt silently.  
> No sense in tipping off the spammer to what he needs to do to work 
> around it. Just use REJECT with no explanation.

The point of rejection messages is in case a human comes up against 
it (and even this one, it could happen.)  You need to let a novice 
postmaster know what s/he has misconfigured.

There is zero evidence over 2 decades that botnet spammers even have 
the capability to receive and parse their rejection messages, much 
less the interest in doing so.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Open relay

[Paul Schmehl]

--On October 22, 2016 at 11:27:56 AM -0500 "/dev/rob0"  
wrote:



On Sat, Oct 22, 2016 at 11:19:36AM -0500, Paul Schmehl wrote:

--On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis
 wrote:
> Op 22-10-16 om 04:32 schreef Bill Cole:
>>/127\.0\.0\.1/REJECT you are not me
>
> Thanks, a great idea to have standard in most cases.

I would make one suggestion.  I would reject the attempt silently.
No sense in tipping off the spammer to what he needs to do to work
around it. Just use REJECT with no explanation.


The point of rejection messages is in case a human comes up against
it (and even this one, it could happen.)  You need to let a novice
postmaster know what s/he has misconfigured.

There is zero evidence over 2 decades that botnet spammers even have
the capability to receive and parse their rejection messages, much
less the interest in doing so.


I wonder how you explain, over the past two decades, how spammers keep 
adjusting their tactics to get around the defenses that are put up to foil 
them.  Precognition?


We've been fighting this battle for, as you say, the past two decades, and 
the spammers have been successful at getting around our defenses.  I could 
list the many things we've done that they've overcome, but why bother? 
You're clearly experienced enough to know what they are.


"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 18:23 schreef /dev/rob0:
> On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:

>> Is the conclusion now, that Postfix is relaying here?
> 
> The only actual conclusion is that you have failed to put forth the 
> necessary information, as Bill [I think] pointed you to the 
> http://www.postfix.org/DEBUG_README.html#mail link.

Thanks, I did oversee that hint and I will study the page.
At the moment no spam is coming in anymore.

> What appears to be most likely, if we were given adequate 
> information, is that an account has been compromised, and a botnet 
> uses those credentials to relay spam through you.

Strange is, that the "Authenticated sender" account does not excist.
What does exist is an account for that mailadres and another account for
the part
for the "@", but I've changed the password of both and the spam did not
stop.

With regards,
Paul van der Vlis.

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[Bill Cole]

On 22 Oct 2016, at 12:19, Paul Schmehl wrote:

I would make one suggestion.  I would reject the attempt silently.  No 
sense in tipping off the spammer to what he needs to do to work around 
it. Just use REJECT with no explanation.


That's a nice hypothesis but it doesn't seem to play out in reality. 
I've been emitting specific (and yes, sometimes snarky) rejection 
messages on a variety of systems for all sorts of access rules, in part 
so I can keep track of what rules are being hit easily. I have never 
seen any hint that spammers behaving in grossly fraudulent ways (like 
EHLO arguments that claim to be the server they're talking to) 
substantively change their behavior in response to those messages. Keep 
in mind that essentially ANY idiosyncratically wrong EHLO argument seen 
only from spammers has been configured intentionally by someone who has 
no idea how cheap, simple, and reliable it is to reject spam on that 
basis. These are cognitively impaired spammers, not smart ones. The 
smart ones try very hard to look very normal and legitimate, not to 
stand out as something starkly different from any legitimate mail.

Re: Open relay

[Paul Schmehl]

--On October 22, 2016 at 1:51:12 PM -0400 Bill Cole 
 wrote:



On 22 Oct 2016, at 12:19, Paul Schmehl wrote:


I would make one suggestion.  I would reject the attempt silently.  No
sense in tipping off the spammer to what he needs to do to work around
it. Just use REJECT with no explanation.


That's a nice hypothesis but it doesn't seem to play out in reality. I've
been emitting specific (and yes, sometimes snarky) rejection messages on
a variety of systems for all sorts of access rules, in part so I can keep
track of what rules are being hit easily. I have never seen any hint that
spammers behaving in grossly fraudulent ways (like EHLO arguments that
claim to be the server they're talking to) substantively change their
behavior in response to those messages. Keep in mind that essentially ANY
idiosyncratically wrong EHLO argument seen only from spammers has been
configured intentionally by someone who has no idea how cheap, simple,
and reliable it is to reject spam on that basis. These are cognitively
impaired spammers, not smart ones. The smart ones try very hard to look
very normal and legitimate, not to stand out as something starkly
different from any legitimate mail.



And you don't think this spammer fits into the latter category?  He's 
clearly doing something very clever that is not the usual brute force 
cram-it-down-your-throat spam run.


"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher

Re: Open relay

[Allen Coates]

On 22/10/16 17:27, /dev/rob0 wrote:
> On Sat, Oct 22, 2016 at 11:19:36AM -0500, Paul Schmehl wrote:
>> --On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis
>>  wrote:
>>> Op 22-10-16 om 04:32 schreef Bill Cole:
/127\.0\.0\.1/REJECT you are not me
>>> Thanks, a great idea to have standard in most cases.
>> I would make one suggestion.  I would reject the attempt silently.  
>> No sense in tipping off the spammer to what he needs to do to work 
>> around it. Just use REJECT with no explanation.

I have also had  HELO statements announcing:-
my own public-facing ip address (from the outside of my NAT firewall),
spurious servers using my own domain name;
example.com (!);
and possibly more controversially, variations on localhost.

*ALL* my own machines are accepted by permit_mynetworks,  so anything
else purporting to belong to me is a demonstrable lie.

All the above are also rejected by my helo_access list.

Allen C






> The point of rejection messages is in case a human comes up against 
> it (and even this one, it could happen.)  You need to let a novice 
> postmaster know what s/he has misconfigured.
>
> There is zero evidence over 2 decades that botnet spammers even have 
> the capability to receive and parse their rejection messages, much 
> less the interest in doing so.

Re: Open relay

[Noel Jones]

On 10/22/2016 1:30 PM, Paul Schmehl wrote:

> He's clearly doing something very clever that is not the usual brute
> force cram-it-down-your-throat spam run.

No evidence has been presented that this is anything other than the
usual leaked-credentials account hijacking.  Any confusion is due to
a lack of information.

Postfix logs the sasl username presented by the spammer. Hopefully
the sasl backend logging will show why this name is unexpectedly
accepted, and is almost certainly not a bug or exploit.



  -- Noel Jones

Re: Open relay

[Bill Cole]

On 22 Oct 2016, at 12:39, Paul Schmehl wrote:

I wonder how you explain, over the past two decades, how spammers keep 
adjusting their tactics to get around the defenses that are put up to 
foil them.


This isn't demonstrably true, although it can look that way. The tactics 
that actually work to get spam delivered have changed, even without most 
individual spammers substantially changing their own tactics.


It has been about 20 years since a bogus local-ish EHLO did anything 
good for deliverability at a measurable number of sites and over 15 
since people started openly rejecting mail on that basis, yet yesterday 
and essentially every day my small personal server says some variation 
of "you are not me" to a couple dozen unique bots and it would be 
hundreds if I didn't have postscreen dropping PREGREET bot connections. 
Oddly, that's not very scale-dependent. On a system handling about 100x 
as much legit mail for 10x as many domains, there's only about twice as 
many bots trying tired old tricks that haven't worked in a long time. On 
both systems, that rate of clueless spam effort has remained stable 
(although noisy) for many years. Meanwhile, "snowshoe" spam has exploded 
over the past decade, but it isn't just a different tactic for getting 
delivered from the botspam, it's a completely different class of spam in 
content and strategy AND it is different spammers.

Re: Open relay

[Bill Cole]

On 22 Oct 2016, at 14:30, Paul Schmehl wrote:

--On October 22, 2016 at 1:51:12 PM -0400 Bill Cole 
 wrote:



On 22 Oct 2016, at 12:19, Paul Schmehl wrote:

I would make one suggestion.  I would reject the attempt silently.  
No
sense in tipping off the spammer to what he needs to do to work 
around

it. Just use REJECT with no explanation.


That's a nice hypothesis but it doesn't seem to play out in reality. 
I've
been emitting specific (and yes, sometimes snarky) rejection messages 
on
a variety of systems for all sorts of access rules, in part so I can 
keep
track of what rules are being hit easily. I have never seen any hint 
that
spammers behaving in grossly fraudulent ways (like EHLO arguments 
that

claim to be the server they're talking to) substantively change their
behavior in response to those messages. Keep in mind that essentially 
ANY
idiosyncratically wrong EHLO argument seen only from spammers has 
been
configured intentionally by someone who has no idea how cheap, 
simple,
and reliable it is to reject spam on that basis. These are 
cognitively
impaired spammers, not smart ones. The smart ones try very hard to 
look

very normal and legitimate, not to stand out as something starkly
different from any legitimate mail.



And you don't think this spammer fits into the latter category?  He's 
clearly doing something very clever that is not the usual brute force 
cram-it-down-your-throat spam run.


Not so much. Spambots have been doing authenticated port 587 submission 
for a dozen years. It's easier to do in volume today because there have 
been huge sever-side compromises of auth credentials and uncountable 
hordes of PC's infected with information-thief malware of one sort or 
another. Finding a working account & password is done by brute force 
now, with bots testing known pairs against a server until one matches. 
For example, last week I had a bot test auth for a dozen different 
"tagged" addresses against my IMAP, POP3, and submission servers on 2 
IPs (primary and secondary MX records, both actually on the same host) 
within less than 2 minutes. All of those addresses were given in 
supposed confidence to exactly one commercial entity each, most of whom 
have had publicized breaches  in recent years. They've automated 
targeted account compromise.


So sure: you could put an unexpressive unique ID into each REJECT rule 
instead of a clear(ish) explanation. They would make their catches 
trackable in logs but keep the spammer from knowing exactly why a 
rejection happened. It's just not clear that it matters. They are doing 
something pointless that makes them easy to catch and they have 
automated every aspect of their spamming.

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 18:23 schreef /dev/rob0:
> On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:

> The only actual conclusion is that you have failed to put forth the 
> necessary information, as Bill [I think] pointed you to the 
> http://www.postfix.org/DEBUG_README.html#mail link.

The problem is that somebody did send spam using port 587 with a not
excisting username, and I am interested how that is possible.

sigmund:/var/log# postconf -Mf
smtp   inet  n   -   -   -   -   smtpd -v
26 inet  n   -   -   -   -   smtpd
465inet  n   -   -   -   -   smtpd
submission inet  n   -   -   -   -   smtpd
pickup fifo  n   -   -   60  1   pickup
cleanupunix  n   -   -   -   0   cleanup
qmgr   fifo  n   -   -   300 1   qmgr
rewriteunix  -   -   -   -   -   trivial-rewrite
bounce unix  -   -   -   -   0   bounce
defer  unix  -   -   -   -   0   bounce
trace  unix  -   -   -   -   0   bounce
verify unix  -   -   -   -   1   verify
flush  unix  n   -   -   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
smtp   unix  -   -   -   -   -   smtp
relay  unix  -   -   -   -   -   smtp
showq  unix  n   -   -   -   -   showq
error  unix  -   -   -   -   -   error
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
maildrop   unix  -   n   n   -   -   pipe flags=DRhu
user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp   unix  -   n   n   -   -   pipe flags=Fqhu
user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix  -   n   n   -   -   pipe flags=F
user=ftn
argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp  unix  -   n   n   -   -   pipe flags=Fq.
user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender $recipient
scalemail-backend unix - n   n   -   2   pipe flags=R
user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
${user} ${extension}
amavis unix  -   -   n   -   2   smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n   -   n   -   -   smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
shadelist  unix  -   n   n   -   -   spawn user=nobody
argv=/usr/bin/perl /usr/local/bin/shadelist.pl -w
nlwhitelist.dnsbl.bit.nl
tlsmgr unix  -   -   -   1000?   1   tlsmgr
scache unix  -   -   -   -   1   scache
discardunix  -   -   -   -   -   discard
retry  unix  -   -   -   -   -   error

-

sigmund:/var/log# saslfinger -s
saslfinger - postfix Cyrus sasl configuration zo okt 23 00:09:27 CEST 2016
version: 1.0.4
mode: server-side SMTP AUTH

-- basics --
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
Postfix: 2.11.3
System: Debian GNU/Linux 8 \n \l

-- smtpd is linked to --
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
libsasl2.so.2 => /usr/lib/i386-linux-gnu/libsasl2.so.2 (0xb73d1000)

-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_tls_loglevel = 1
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_use_tls = yes
postconf: w

Re: Open relay

[Paul van der Vlis]

Op 22-10-16 om 21:12 schreef Noel Jones:
> On 10/22/2016 1:30 PM, Paul Schmehl wrote:
> 
>> He's clearly doing something very clever that is not the usual brute
>> force cram-it-down-your-throat spam run.
> 
> No evidence has been presented that this is anything other than the
> usual leaked-credentials account hijacking.  Any confusion is due to
> a lack of information.

The "Authenticated sender" does not excist as a user account. It is an
correct e-mail address, but not an user account with what you can
authenticate.

> Postfix logs the sasl username presented by the spammer. Hopefully
> the sasl backend logging will show why this name is unexpectedly
> accepted, and is almost certainly not a bug or exploit.

I will look for a sasl backend logging method.

The spammers are still trying. Every time from another IP, so I cannot
log on a specific IP.

With regards,
Paul van der Vlis


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Open relay

[Noel Jones]

On 10/22/2016 5:36 PM, Paul van der Vlis wrote:
> The "Authenticated sender" does not excist as a user account. It is an
> correct e-mail address, but not an user account with what you can
> authenticate.

And yet that's the username postfix provides to the backend.  The
only mystery here is why the backend accepts it. This is almost
certainly due to some unintentional configuration rather than a bug
or exploit.

You should concentrate your efforts on the backend. All you'll get
out of postfix is that some username and password was passed to the
backend, and the backend replied they were valid.

Further debugging in postfix is pointless.


  -- Noel Jones

Re: Open relay

[Bill Cole]

On 22 Oct 2016, at 18:50, Noel Jones wrote:


On 10/22/2016 5:36 PM, Paul van der Vlis wrote:
The "Authenticated sender" does not excist as a user account. It is 
an

correct e-mail address, but not an user account with what you can
authenticate.


And yet that's the username postfix provides to the backend.  The
only mystery here is why the backend accepts it. This is almost
certainly due to some unintentional configuration rather than a bug
or exploit.

You should concentrate your efforts on the backend. All you'll get
out of postfix is that some username and password was passed to the
backend, and the backend replied they were valid.


This makes me ponder a question:

What does Postfix show in the Received header if authentication is 
attempted and fails but the sender keeps going and is is not rejected by 
a later restriction?



Further debugging in postfix is pointless.


If the answer to the above question is "it records the attempted 
authentication identity" then this is not so. We already know that the 
submission service is grossly misconfigured, as it has no overrides of 
any settings for the port 25 smtpd.


The OP has ignored repeated requests for postconf -nf output and 
comprehensive relevant log extracts but any logging is likely to be 
unclear in any case because of his failure to configure submission 
wisely. We KNOW submission is using an inherently insecure config and he 
asserts that this is coming though the submission service. It couldn't 
hurt to fix the glaring problem with submission config, since it 
provides a theoretical path for mail to be relayed without even an 
attempt to authenticate: just fail to be rejected by his complex 
smtp_relay_restrictions.  That list ends in 'permit' and includes a very 
suspicious (especially for submission) 'check_sender_access 
hash:/etc/postfix/whitelist' which presumably has 'permit' entries for 
sender addresses which are not subject to any sort of authentication.

Re: Open relay

[Wietse Venema]

Bill Cole:
> What does Postfix show in the Received header if authentication is 
> attempted and fails but the sender keeps going and is is not rejected by 
> a later restriction?

There is no username unless the user was logged in.

/* RFC 4954 Section 6. */
smtpd_chat_reply(state, "235 2.7.0 Authentication successful");
if ((sasl_username = xsasl_server_get_username(state->sasl_server)) == 0)
msg_panic("cannot look up the authenticated SASL username");
state->sasl_username = mystrdup(sasl_username);
printable(state->sasl_username, '?');
state->sasl_method = mystrdup(sasl_method);
printable(state->sasl_method, '?');

Either this, or an NGINX proxy sent the logged-in username with XCLIENT.

Note that Postfix does not look inside SASL protocol messages. It
has no idea how the protocols work and gets the username from the
Cyrus SASL library or from a Dovecot authentication server.

Wietse

Re: Open relay

[Ansgar Wiechers]

On 2016-10-23 Paul van der Vlis wrote:
> Op 22-10-16 om 18:23 schreef /dev/rob0:
>> The only actual conclusion is that you have failed to put forth the 
>> necessary information, as Bill [I think] pointed you to the 
>> http://www.postfix.org/DEBUG_README.html#mail link.
>
> The problem is that somebody did send spam using port 587 with a not
> excisting username, and I am interested how that is possible.
>
> sigmund:/var/log# postconf -Mf

So you finally decided to show the output of "postconf -Mf" and
"saslfinger -s". Good. Now you just need to provide the rest of the
information Bill Cole asked of you 2 days ago:

- Full output of "postconf -nf".
- Full headers of a sample message (you may obfuscate personal
  information about the recipient).
- All log lines associated with that particular message. At the very
  least the output of "grep  /var/log/mail.log".

  In case you don't know how to find the queue ID in a log message, it's
  this part of the log line:

postfix/smtpd[]: 2758BBF4062: ...
  ^^^

And did you already investigate why the authentication backend considers
"p...@puk.nl" a valid user, as Noel Jones asked? What did you find out?

Without all of the information mentioned above you're just wasting
everyone's time.

---

Probably unrelated, because the messages in question apparently are
received via submission, but still: you may want to disable verbose
logging for the smtpd on port 25. Remove the "-v" from this line in
master.cf:

> smtp   inet  n   -   -   -   -   smtpd -v

Verbose logging is only required in very specific debugging scenarios
and wont do you any good for regular operations or troubleshooting.

Regards
Ansgar Wiechers

ISP open relay

[Wesley Peng]

Hello

My ISP email even doesn’t require SMTP AUTH. Will they be acting as open
relay? How to stop abuse of outgoing mail?

Regards

Postfix Open Relay Issue

[Severian37]

Good day,

My postfix email server has been listed by dsnbl.njabl.org as an open relay,
but I'm not sure why. I tested the server from another site, and it passes
every test.

My main.cf is setup with the following:
__

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases

body_checks = regexp:/etc/postfix/maps/body_checks
broken_sasl_auth_clients = yes

command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024

daemon_directory = /usr/libexec/postfix
debug_peer_level = 2

header_checks = regexp:/etc/postfix/maps/header_checks
html_directory = no

inet_interfaces = all

local_recipient_maps = hash:/etc/postfix/relay_recipients

mail_owner = postfix
mailbox_size_limit = 1500020
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 6048
mime_header_checks = regexp:/etc/postfix/maps/mime_header_checks

mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, servpt.com, myexg.myemailserver.com;
myexg.myemailserver.local

mydomain = myemailserver.com
myhostname = mail.myemailserver.com

mynetworks = localhost, mail.myemailserver.com, plq138,
plq139.myemailserver.com, myexg, myexg.myemailserver.local,
fdsexg.myemailserver.com, plq138.myemailserver.com, boditree.net,
a1w.myemailserver.com, apd.myemailserver.com, awd.myemailserver.com,
aaw.myemailserver.com, awa.myemailserver.com, axw.myemailserver.com,
aws.myemailserver.com, awp.myemailserver.com, dirw.myemailserver.com,
dwi.myemailserver.com, dws.myemailserver.com, ewc.myemailserver.com,
fcwc.myemailserver.com, ndw.myemailserver.com, taw.myemailserver.com,
twd.myemailserver.com, uawn.myemailserver.com, uww.myemailserver.com,
wahq.myemailserver.com, wrc.myemailserver.com, parts.myemailserver.com,
parts2.myemailserver.com

mynetworks_style = host

newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES
relay_recipient_maps = hash:/etc/postfix/relay_recipients

resolve_dequoted_address = yes

sample_directory = /usr/share/doc/postfix-2.2.10/samples

sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_null_access_lookup_key = <>

smtpd_recipient_restrictions = check_sender_access
hash:/etc/postfix/dsn_exceptions,reject_unauth_pipelining,   
reject_non_fqdn_recipient,reject_unknown_recipient_domain,   
permit_mynetworks,check_sender_access hash:/etc/postfix/access,  
check_sender_access hash:/etc/postfix/dsn_exceptions,   
reject_rbl_client relays.mail-abuse.orgpermit_sasl_authenticated,   
reject_unauth_destination,reject_rbl_client bl.spamcop.net,   
reject_rbl_client sbl-xbl.spamhaus.org,reject_rbl_client
dnsbl.njabl.org,reject_rbl_client cn.rbl.cluecentral.net,   
reject_rbl_client

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = myemailserver.com
smtpd_sasl_security_options = noanonymous

smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/dsn_exceptions,reject_rhsbl_sender rhsbl.ahbl.org,
   
reject_rhsbl_sender hash:/etc/postfix/access
transport_maps = hash:/etc/postfix/transport

unknown_hostname_reject_code = 550
unknown_local_recipient_reject_code = 550
___

njabl.org did a relay test where they send a msg on my email server from
sender postmas...@myemailserver.com, and it apparently sent back to them,
despite the fact their mail server was not my domain.  

Where is the loophole in my config?


Thanks for your help -
-- 
View this message in context: 
http://www.nabble.com/Postfix-Open-Relay-Issue-tp25981301p25981301.html
Sent from the Postfix mailing list archive at Nabble.com.

Re: Open relay question

[Noel Jones]

On 11/5/2010 2:28 PM, Alejandro Facultad wrote:

Dear, I'm in Internet and testing if my mail server is an Open
Relay. So I execute:

telnet mail.mycompany.com 25

After that I do:

mail from: us...@mycompany.com
OK
rcpt to: us...@mycompany.com
OK
data
This is a test !!!
.
QUEUED

The mail from user1 to user2 (both from my company) was sent
OK !!!

Is this behavior normal or is it an open relay ??? Can I sent
a message from one local user to another local user, being
that I come from Internet and not from LAN ???

Thanks a lot

A.F.




Yes, that's normal.  "Open relay" means the RCPT can be an 
unrelated domain eg. @hotmail.com.

Re: Open relay question

[Alejandro Facultad]

Thanks but, is it right if coming from Internet I enter to your mail server and 
after that I send a message from your mail account to your project manager's 
mail account telling he's an asshole ???

I now SPF is ideal for avoid this behavior, but I think the first example is an 
"open relay" feature.

Thanks a lot.





De: Noel Jones 
Para: postfix-users@postfix.org
Enviado: viernes, 5 de noviembre, 2010 16:32:01
Asunto: Re: Open relay question

On 11/5/2010 2:28 PM, Alejandro Facultad wrote:
> Dear, I'm in Internet and testing if my mail server is an Open
> Relay. So I execute:
>
> telnet mail.mycompany.com 25
>
> After that I do:
>
> mail from: us...@mycompany.com
> OK
> rcpt to: us...@mycompany.com
> OK
> data
> This is a test !!!
> .
> QUEUED
>
> The mail from user1 to user2 (both from my company) was sent
> OK !!!
>
> Is this behavior normal or is it an open relay ??? Can I sent
> a message from one local user to another local user, being
> that I come from Internet and not from LAN ???
>
> Thanks a lot
>
> A.F.
>
>

Yes, that's normal.  "Open relay" means the RCPT can be an 
unrelated domain eg. @hotmail.com.


  

Re: Open relay question

[Mauricio Tavares]

On 11/05/2010 03:41 PM, Alejandro Facultad wrote:

Thanks but, is it right if coming from Internet I enter to your mail
server and after that I send a message from your mail account to your
project manager's mail account telling he's an asshole ???

I now SPF is ideal for avoid this behavior, but I think the first
example is an "open relay" feature.


What about smtp auth?


Thanks a lot.


*De:* Noel Jones 
*Para:* postfix-users@postfix.org
*Enviado:* viernes, 5 de noviembre, 2010 16:32:01
*Asunto:* Re: Open relay question

On 11/5/2010 2:28 PM, Alejandro Facultad wrote:
 > Dear, I'm in Internet and testing if my mail server is an Open
 > Relay. So I execute:
 >
 > telnet mail.mycompany.com 25
 >
 > After that I do:
 >
 > mail from: us...@mycompany.com <mailto:us...@mycompany.com>
 > OK
 > rcpt to: us...@mycompany.com <mailto:us...@mycompany.com>
 > OK
 > data
 > This is a test !!!
 > .
 > QUEUED
 >
 > The mail from user1 to user2 (both from my company) was sent
 > OK !!!
 >
 > Is this behavior normal or is it an open relay ??? Can I sent
 > a message from one local user to another local user, being
 > that I come from Internet and not from LAN ???
 >
 > Thanks a lot
 >
 > A.F.
 >
 >

Yes, that's normal. "Open relay" means the RCPT can be an
unrelated domain eg. @hotmail.com.

Re: Open relay question

[Pete]

On Fri, 2010-11-05 at 12:41 -0700, Alejandro Facultad wrote:
> Thanks but, is it right if coming from Internet I enter to your mail
> server and after that I send a message from your mail account to your
> project manager's mail account telling he's an asshole ???
> 
> I now SPF is ideal for avoid this behavior, but I think the first
> example is an "open relay" feature.
> 
> Thanks a lot.
> 
> 
> 
> __
> De: Noel Jones 
> Para: postfix-users@postfix.org
> Enviado: viernes, 5 de noviembre, 2010 16:32:01
> Asunto: Re: Open relay question
> 
> On 11/5/2010 2:28 PM, Alejandro Facultad wrote:
> > Dear, I'm in Internet and testing if my mail server is an Open
> > Relay. So I execute:
> >
> > telnet mail.mycompany.com 25
> >
> > After that I do:
> >
> > mail from: us...@mycompany.com
> > OK
> > rcpt to: us...@mycompany.com
> > OK
> > data
> > This is a test !!!
> > .
> > QUEUED
> >

Hello,

If you can connect into a mail server externally (e.g mycompany.com) and
send mail through that server without having to provide any means of
authentication to another domain entirely (e.g myothercompany.com) then
that is an open relay. 

AFAICT your example used the same domain. If the mail server was
configured to accept mail for 'mycompany.com' then it's doing its job in
your example.

HTH.

Regards,

Pete.



signature.asc
Description: This is a digitally signed message part

Re: Open relay question

[Will Fong]

On 11/05/2010 12:41 PM, Alejandro Facultad wrote:
Thanks but, is it right if coming from Internet I enter to your mail 
server and after that I send a message from your mail account to your 
project manager's mail account telling he's an asshole ???


I now SPF is ideal for avoid this behavior, but I think the first 
example is an "open relay" feature.


Thanks a lot.



Hi Alejandro,

The example you described is not relaying.

Relaying is when the MTA you connected to needs to send the message to 
another server. Being an "open relay" means the MTA will receive 
messages for anyone on the Internet to anyone on the Internet.


Hope that clears things up.

-will

Re: Open relay question

[Noel Jones]

On 11/5/2010 2:41 PM, Alejandro Facultad wrote:

Thanks but, is it right if coming from Internet I enter to
your mail server and after that I send a message from your
mail account to your project manager's mail account telling
he's an asshole ???

I now SPF is ideal for avoid this behavior, but I think the
first example is an "open relay" feature.


Open relay is about the recipient domain, not the sender domain.

If you don't want to allow your own domain as unauthenticated 
sender, you can control that with a check_sender_access map. 
Examples are in the mail list archives.

Re: Open relay question

[Victor Duchovni]

On Fri, Nov 05, 2010 at 12:41:06PM -0700, Alejandro Facultad wrote:

> Thanks but, is it right if coming from Internet I enter to your mail
> server and after that I send a message from your mail account to your
> project manager's mail account telling he's an asshole ???

Don't confuse the envelope sender (which most recipients neither see
nor understand) with the "From:" header which most recipients do see
and don't understand.

The "From:" header is easily (and often legitimately) forged. For example,
the Postfix-users list sends your own posts to you, from the Internet. The
"From:" header still bears your address. Sure, the envelope sender is
not, but the risk you pose applies to the "From:" header not the envelope.

Applying policy restrictions to the "From:" header, is fraught with
complexity and peril. I don't want to get into the politics of SIDF, DKIM,
... the bottom line is that people largely have unrealistic expectations
of what email authentication technologies can do for them.

-- 
Viktor.

Re: Open relay question

[mouss]

Le 05/11/2010 20:41, Alejandro Facultad a écrit :
Thanks but, is it right if coming from Internet I enter to your mail 
server and after that I send a message from your mail account to your 
project manager's mail account telling he's an asshole ???




that's the same as if someone sends you a letter claiming tobe your 
father and saying the same. it's a lie, not an open relay.


an open relay is when someone causes you to annoy someone else.
said otherwise: I don't care if joe tells your boss he is an asshole, 
whomever joe might be. but I wouldn't be happy if _joe_ makes _you_ send 
_me_ a message (whatever the message is).


I now SPF is ideal for avoid this behavior, but I think the first 
example is an "open relay" feature.


Please don't talk about spf again on this list. spf devots are not 
welcome here.

RE: Open relay question

[Alfonso Alejandro Reyes Jimenez]

But that would be spoofing not relay right?

 

Relay is when you let other users send emails to any other domain claiming be 
someone in your organization.

 

Spoofing is when you pretend to be someone you are not, right now I cant 
remember how to prevent this kind of attacks but you may search google (that’s 
how I fixed it).

 

You may consider any type of authentication. As far as I know (from the list) 
SPF is not the solution if you don’t know exactly what you are doing.

 

Have a great day.

 

Saludos. 
  
   
  
Ing. Alfonso Alejandro Reyes Jiménez 
  Analista del sector Gobierno 
  
E-mail: aare...@scitum.com.mx <mailto:aare...@scitum.com.mx>  
Telefono: 91 50 74 00 ext. 7489 
Movil: (044) 55 52 98 34 82

 

La información contenida en el presente correo es confidencial y para uso 
exclusivo de la persona o institución a que se refiere. Si usted no es el 
receptor deliberado es ilegal cualquier distribución, divulgación, 
reproducción, completa o parcial, aprovechamiento, uso o cualquier otra acción 
relativa a ella. Por favor notifique al emisor e inmediatamente bórrela de 
forma permanente de cualquier computadora en la que resida y en caso de 
existir, destruya cualquier copia impresa.

 

 

De: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] En 
nombre de mouss
Enviado el: viernes, 05 de noviembre de 2010 03:12 p.m.
Para: postfix users
Asunto: Re: Open relay question

 

Le 05/11/2010 20:41, Alejandro Facultad a écrit : 

Thanks but, is it right if coming from Internet I enter to your mail server and 
after that I send a message from your mail account to your project manager's 
mail account telling he's an asshole ???


that's the same as if someone sends you a letter claiming tobe your father and 
saying the same. it's a lie, not an open relay.

an open relay is when someone causes you to annoy someone else. 
said otherwise: I don't care if joe tells your boss he is an asshole, whomever 
joe might be. but I wouldn't be happy if _joe_ makes _you_ send _me_ a message 
(whatever the message is). 




I now SPF is ideal for avoid this behavior, but I think the first example is an 
"open relay" feature.


Please don't talk about spf again on this list. spf devots are not welcome 
here. 

<>

Re: Open relay question

[mouss]

Le 05/11/2010 22:26, Alfonso Alejandro Reyes Jimenez a écrit :


But that would be spoofing not relay right?

Relay is when you let other users send emails to any other domain 
claiming be someone in your organization.




no there's no claim.
open relay is when someone uses your server to send mail to people 
outside of your organisation. it doesn't matter who they claim to be. 
they can tell the truth. the thing is: it is unauthorized relay.


a long time ago, "open relay" was a natural thing ("collaboration"). 
unfortunately, spammers/abusers have killed this collaboration.



Spoofing is when you pretend to be someone you are not, right now I 
cant remember how to prevent this kind of attacks but you may search 
google (that’s how I fixed it).





the first question to ask yourself is: why would you care? in most 
cases, the recipient can take care of that.

Testing For Open Relay

[Carlos Williams]

I just finished a new Postfix 2.6 installation on a Debian server in a
co-location and just wanted to make sure I am properly testing this
machine is not a 'open relay' before I open it out to the public:

I was told to go to the following URL http://www.abuse.net/relay.html
and I entered my external IP address in the 1st line and nothing else.
After 17 tests, I get the following at the bottom:

"Relay test result
All tests performed, no relays accepted."

Does this mean I am safe? I read somewhere that in my main.cf I should
have the following entry:

relay_domains =

"relay_domains: is a list of destination domains this system will
relay mail to. By setting it to be blank we ensure that our mail
server isn't acting as an open relay for untrusted networks. The
reader is advised to test that their system isn't acting as an open
relay here: http://www.abuse.net/relay.html";

Now that being said, I don't have relay_domains entry in my main.cf
however according to the site they recommend I test, I don't appear to
be one. Do I need this entry in my main.cf or am I fine? Is there an
other way to test for being an open relay or should I feel safe about
this?

*postconf -n*

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
home_mailbox = mail/
inet_interfaces = all
mailbox_size_limit = 0
message_size_limit = 10485760
mydestination = $config_directory/mydestination
mydomain = omgwtf.com
myhostname = mx.omgwtf.com
mynetworks = $config_directory/mynetworks
myorigin = omgwtf.com
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_use_tls = no

Re: SV: Open relay

[/dev/rob0]

On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote:
> Or even better: Accept the mail, but toss it away. Eg use, DISCARD 
> instead.

Oh, ugh, definitely not.  This is terrible advice.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

SV: SV: Open relay

[Sebastian Nielsen]

Yeah, in this situation it might be a bad idea as the problem is not really
HELO 127.0.0.1, but rather that a account is compromised.
I would rather limit the relay so authorized accounts can only be used from
authorized IP adresses, like the local branch.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För /dev/rob0
Skickat: den 22 oktober 2016 18:29
Till: postfix-users@postfix.org
Ämne: Re: SV: Open relay

On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote:
> Or even better: Accept the mail, but toss it away. Eg use, DISCARD 
> instead.

Oh, ugh, definitely not.  This is terrible advice.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SV: Open relay

[John @ KLaM]

Why? If it smells bad, toss it in the garbage. We work on this basis.

We are thinking about the idea of approved senders, anybody the we send to 
is automatically add to an approved sender database. If you want to send to 
us send an email to the PM, if you are approved you get added to the list.
I have been playing with the idea that entries would be good for n months 
from of the last message sent by us.

The usual addresses (postmaster, admin...) accept all email.



On October 22, 2016 12:30:02 PM /dev/rob0  wrote:


On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote:

Or even better: Accept the mail, but toss it away. Eg use, DISCARD
instead.


Oh, ugh, definitely not.  This is terrible advice.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Concern of open relay

[Ben Johnson]

Hello!

I've noticed increased Postfix activity as of late and am concerned that
something is configured inadequately (i.e., open-relay). For "postconf
-n" output, please skip to the end of this message.

So, I installed pflogsumm and my concerns seem valid. I'll address each
point of concern.

Firstly, the Grand Totals are much larger than expected (especially
deferrals), given the tenancy on this server:


Grand Totals

messages

  13993   received
  17602   delivered
  0   forwarded
  19486   deferred  (294359  deferrals)
   5439   bounced
348   rejected (1%)
  0   reject warnings
  0   held
  0   discarded (0%)

  28386k  bytes received
  55491k  bytes delivered
690   senders
 43   sending hosts/domains
  11302   recipients
641   recipient hosts/domains


Also, nearly this entire next section is full of domains which we do not
host (obviously). What's interesting, too, is that we do host *Web*
services for "example.com" (sanitized for privacy reasons), but not
email (no MX records in DNS for this domain point to the server in
question -- they point to a different email provider).


Host/Domain Summary: Message Delivery
--
 sent cnt  bytes   defers   avg dly max dly host/domain
  ---  ---  --- --- ---
   543817837k   0 6.5 s   37.0 s  example.com
   4183 3409k9540 1.8 h   59.6 h  yahoo.com
   4094 3207k  259218 9.9 h   51.5 h  aol.com
783   436136130.5 m2.9 h  hotmail.com
755 1021k 531 3.1 h   30.9 h  gmail.com
136   106885 6803 9.8 h   51.4 h  aim.com
129   104380  207 1.1 h   10.6 h  ymail.com
 8469503  136 1.2 h9.5 h  yahoo.fr
 7764989  157 1.7 h7.2 h  yahoo.co.uk


Continuing on, I find that recipients at this domain have received 13814
messages in this time period. But how is this possible if we don't even
host email for the client whose domain I am calling "example.com"? The
domain is not configured in Postfix, there are no mailboxes for users at
this domain, etc.


Host/Domain Summary: Messages Received
---
 msg cnt   bytes   host/domain
  ---  ---
  1381413177k  example.com


And not only are messages being delivered to these non-existent
mailboxes (at least according to Postfix and/or pflogsumm), but users at
this domain (again, for which we do not host email -- Web only) are also
sending mail. Note that none of these local-parts are valid; they seem
auto-generated:


Senders by message count

146   mavis_lebl...@example.com
144   patrice_sc...@example.com
140   kathrine_gen...@example.com
124   alana_spen...@example.com
110   ann_ll...@example.com
110   augusta_gallo...@example.com
108   nadia_crawf...@example.com
106   gladys_b...@example.com
102   jane_mc...@example.com
 96   bobbi_char...@example.com
 94   christina_schnei...@example.com
 82   glenda_bar...@example.com
[list continues for a couple thousand fake addresses]


And interspersed with legitimate entries (see first item, for example),
I find more of this garbage for the sanitized domain that I'm calling
"example.com". This goes on for over 10,000 entries:


Recipients by message count
---
 59   sa...@real-domain-for-which-we-actually-host-email.com
 41   margery_spe...@example.com
 40   augusta_gallo...@example.com
 34   mavis_lebl...@example.com
 34   yvette_herr...@example.com
 31   gladys_b...@example.com
 28   sallie_bu...@example.com
 26   briana_ke...@example.com
 25   vera_atkin...@example.com
 24   eloise_wil...@example.com
 24   joy_b...@example.com
[10,000+ more entries here]


And then some 1,800 messages with no size data:


Messages with no size data
--
 00508E89F0  lili_alf...@hotmail.com
 00555E8C05  br...@yahoo.com
 00576E81B4  st8...@hotmail.com
 00A09E924C  aguiam...@aol.com
 00BEEE820C  srus...@aol.com
 00DBDE8CEB  rinmar2...@aol.com
 00E0AE920D  tj_v_l...@hotmail.com
 00E55E8BB3  brein...@mybluelight.com
 01263E6B2D  trila...@aol.com
 01584E8F94  srush1...@aol.com
 015C2E8984  laithza...@yahoo.com
 02136E855B  omar...@ymail.com
 0253CE81C6  st8ofden...@aol.com
[1,800+ more entries here]


And last but not least (note the tremendous [for this system] number of
deferrals); clearly, other mail systems are black-listing this system.
I've replaced this system's IP address with XXX.XXX.XXX.XXX:


message deferral detail
---
  error (total: 271035)
175000   4.7.1 : (DYN:T1
 85460   5.7.1 : (RLY:B1
  1446   25: Connection timed out
   827   lost connection with mta5.am0.yahoodns.net[98.138.112.32]
whil...
   727   lost connection with mta5.am0

Fixing open relay problem

[Stephen McHenry]

I've been running Postfix for many years now (so thanks to Wietse and all
the others who have put in hard work to make it such a great mail system)
and recently I built a new mail server and copied most of the config files
from the old one.

After a couple of months, I began to notice that it appeared to be getting
used (infrequently) as an open relay, despite my attempts to lock it down
so that couldn't happen. Then, the problem got worse. The one pattern I
noticed was that all the messages had forged senders that were from my
domain (e.g., bogussen...@mydomain.com).

I've poured through the documentation, and a couple of times thought I
found the answer, only to make a change and have it not work. My band-aid
(while researching the real solution) has been to firewall off access from
IP address ranges that were the sources of the email. But to be clear,
that's only a band-aid until a real solution is in place.

The two config parameters that seem most relevant to the problem are listed
below:
(from postconf -n)

*smtpd*_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, permit_auth_destination, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, reject_unauth_destination,
reject_unlisted_recipient, reject_unauth_destination check_recipient_access
regexp:/etc/postfix/recipient_checks.regexp, check_recipient_access
hash:/etc/postfix/recipient_checks, reject_unauth_pipelining,
reject_invalid_hostname, reject_non_fqdn_hostname, reject_rbl_client
domain-name, permit


(and from postconf -d)

*smtpd*_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
defer_unauth_destination

What's really confounding me is that it seems to be (properly) rejecting
all relay email except those that have mydomain.com in their from address.
Adding to that confusion is that this same set of config parameters used to
work fine on the old system, so I've also been looking at relevant defaults
that changed. Unfortunately, I'm coming up dry at this point.

Any help or pointers would be greatly appreciated.

Thanks.


-- 

Stephen

Stephen McHenry

Re: ISP open relay

[Dan Mahoney]

Presumably they know what your IP is because they gave it to you. That’s the 
authorization.

I am willing to bet that if you tried to send mail from off network you 
wouldn’t be able to without doing SMTP auth 

Sent from my iPhone

> On Jan 12, 2020, at 16:15, Wesley Peng  wrote:
> 
> 
> Hello
> 
> My ISP email even doesn’t require SMTP AUTH. Will they be acting as open 
> relay? How to stop abuse of outgoing mail?
> 
> Regards 

Re: ISP open relay

[Gerben Wierda]

Some ISP’s even go further my catching all traffic to port 25 to any system 
outsuide their network (other than to their own MTAs) blocking it or directing 
that to their own MTA. That is because of course one hacked system in their 
network means an open relay from their network and that is bad for the 
reputation of the network. So, they may force all clients to go to their relay. 
I guess not many ISPs still do this anymore, though some may still block port 
25 to anywhere but their own mail relay.

It is many years ago, but at some point my mail could not be delivered (I was 
sending to 25 with STARTTLS) and after investigation it turned out that the ISP 
(in this case telecom provider KPN) was redirecting all traffic to their own 
MTA which then spoofed being my mail server. It was very funny to try connect 
to my mail.rna.nl postfix MTA to be greeted with “This is sendmail at 
mail.rna.nl”. Of course this went wrong as soon as authentication was started.

Gerben Wierda
Chess and the Art of Enterprise Architecture <https://ea.rna.nl/the-book/>
Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>
Architecture for Real Enterprises 
<https://www.infoworld.com/blog/architecture-for-real-enterprises/> at InfoWorld
On Slippery Ice <https://eapj.org/on-slippery-ice/> at EAPJ

> On 13 Jan 2020, at 01:38, Dan Mahoney  wrote:
> 
> Presumably they know what your IP is because they gave it to you. That’s the 
> authorization.
> 
> I am willing to bet that if you tried to send mail from off network you 
> wouldn’t be able to without doing SMTP auth 
> 
> Sent from my iPhone
> 
>> On Jan 12, 2020, at 16:15, Wesley Peng  wrote:
>> 
>> 
>> Hello
>> 
>> My ISP email even doesn’t require SMTP AUTH. Will they be acting as open 
>> relay? How to stop abuse of outgoing mail?
>> 
>> Regards 
> 

Re: ISP open relay

[Jaroslaw Rafa]

Dnia 13.01.2020 o godz. 15:50:59 Gerben Wierda pisze:
> Some ISP’s even go further my catching all traffic to port 25 to any
> system outsuide their network (other than to their own MTAs) blocking it
> or directing that to their own MTA. That is because of course one hacked
> system in their network means an open relay from their network and that is
> bad for the reputation of the network. So, they may force all clients to
> go to their relay. I guess not many ISPs still do this anymore, though
> some may still block port 25 to anywhere but their own mail relay.

I once found an ISP that blocked port 25 completely, even not allowing to
connect to their mail relay (actually, they didn't provide any mail relay at
all to their users, so there was nowhere to connect to). You were forced to
use ports 587 or 465 for outgoing mail.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: ISP open relay

[@lbutlr]

On 13 Jan 2020, at 07:58, Jaroslaw Rafa  wrote:
> You were forced to use ports 587 or 465 for outgoing mail.

Yes, that is a sensible ISP.



-- 
And she was lying in the grass And she could hear the highway
breathing And she could see a nearby factory She's making sure
she is not dreaming

Open relay or compromised user?

[Guy]

Hi guys,

I've got some mail in the queue that's clearly spam. The from address
is [EMAIL PROTECTED] and the source server is
"7c.91.5746.static.theplanet.com [70.87.145.124]" The recipient
addresses are random domains that do not belong to me. The server is
supposed to be a gateway and outgoing server for our users.

I've tried telnet to port 25 on the box and get relay access denied
trying to send to a non local domain (gmail.com). So either my config
is completely screwed (which is very possible) or I've got a
compromised user. If it's a compromised user, is it possible for
postfix to include the authenticated username in the message headers?

Below is a postconf -n from the gateway/smtp server. Any advice on
what I'm missing or bad settings would be great. Also, which of the
standard config examples would cover what I'm trying to do with this
server? Or should I just start reading through the base configuration?
Or should I just hurry up and get the Book of Postfix? :P

Thanks
Guy

[EMAIL PROTECTED]:/var/spool/postfix/hold# postconf -n
2bounce_notice_recipient = [EMAIL PROTECTED]
anvil_rate_time_unit = 60s
bounce_notice_recipient = [EMAIL PROTECTED]
bounce_template_file = /etc/postfix/bounce.cf
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
cyrus_sasl_config_path = /etc/postfix/sasl/
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 30
delay_notice_recipient = [EMAIL PROTECTED]
error_notice_recipient = [EMAIL PROTECTED]
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.2.10/html
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains = sbl-xbl.spamhaus.org
message_size_limit = 3124
mynetworks = 127.0.0.0/8, 72.9.230.26
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.2.10/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_connection_count_limit = 30
smtpd_client_connection_rate_limit = 100
smtpd_client_message_rate_limit = 100
smtpd_client_recipient_rate_limit = 100
smtpd_error_sleep_time = 1s
smtpd_hard_error_limit = 20
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,  reject_invalid_hostname,
reject_non_fqdn_sender, reject_unknown_sender_domain,
reject_unauth_destination,  check_recipient_access
hash:/etc/postfix/spamlovers,  check_client_access
cidr:/etc/postfix/postfix-dnswl-permit, reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
reject_rbl_client psbl.surriel.com,   reject_rhsbl_client
zen.spamhaus.org,   reject_rhsbl_client bl.spamcop.net,
check_policy_service inet:127.0.0.1:10031,  permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_soft_error_limit = 10
smtpd_tls_CAfile = /etc/ssl/certs/ca-bundle.crt
smtpd_tls_cert_file = /etc/ssl/certs/imapd.pem
smtpd_tls_key_file = /etc/ssl/private/imapd.pem
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
mysql:/etc/postfix/mysql_virtual_catchall_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_transport = smtp:barracuda.aluminati.org


-- 
Don't just do something...sit there!

Re: Postfix Open Relay Issue

[Sahil Tandon]

On Tue, 20 Oct 2009, Severian37 wrote:

> My postfix email server has been listed by dsnbl.njabl.org as an open relay,
> but I'm not sure why. I tested the server from another site, and it passes
> every test.
> 
> My main.cf is setup with the following:

No.  Paste the output of 'postconf -n'.  See DEBUG_README before
replying to this message.`

> sample_directory = /usr/share/doc/postfix-2.2.10/samples

Upgrade.

> smtpd_recipient_restrictions = check_sender_access
> hash:/etc/postfix/dsn_exceptions

What is in this file?

> check_sender_access hash:/etc/postfix/access,  

And this file?

> njabl.org did a relay test where they send a msg on my email server from
> sender postmas...@myemailserver.com, and it apparently sent back to them,
> despite the fact their mail server was not my domain.  
> 
> Where is the loophole in my config?

Do you really need to obfuscate your server's hostname?  If so, at least
follow DEBUG_README and provide some logging that corresponds with
njabl.org's relay test.

-- 
Sahil Tandon 

Help, still an open relay.‏

[M M]

Hello all, 

I just finished setting up a postfix server with mysql/virtual users. I can 
send and receive emails fine. But my server is an open relay according to 
online tests. I've tried many and they all list my server as an open relay. 
I've tried my best to correct this problem but i can't figure it out. Maybe you 
can help me out. I've posted my main.cf

Thanks!

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/dovecot.pem
smtpd_tls_key_file=/etc/ssl/private/dovecot.pem
smtpd_tls_security_level = may
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_per_site = hash:/etc/postfix/tls_per_site
smtpd_tls_CAfile = /etc/postfix/CAcert.pem

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = example.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname
mydomain = example.com
myorigin = $mydomain
relayhost =
mynetworks = 127.0.0.1/8,198.100.50.0/24
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 2048
recipient_delimiter = +
inet_interfaces = all
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = 
mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
virtual_transport = dovecot

dovecot_destination_recipient_limit = 1

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
content_filter = smtp-amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

show_user_unknown_table_name = no

smtpd_helo_required = yes
strict_rfc821_envelopes = yes
smtpd_delay_reject = no
disable_vrfy_command = yes
unknown_address_reject_code  = 554
unknown_hostname_reject_code = 554
unknown_client_reject_code   = 554


smtpd_helo_restrictions = 
permit_mynetworks,reject_invalid_hostname,reject_unknown_hostname

smtpd_sender_restrictions = 
hash:/etc/postfix/access,reject_unknown_recipient_domain,reject_non_fqdn_sender

smtpd_data_restrictions = reject_unauth_pipelining

smtpd_recipient_restrictions =

  reject_invalid_hostname,

  reject_non_fqdn_sender,

  reject_non_fqdn_recipient,

  reject_unknown_sender_domain,

  reject_unknown_recipient_domain,

  permit_mynetworks,

  reject_unauth_destination,

  permit_sasl_authenticated,

  reject_unauth_pipelining,   
_
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

Re: Testing For Open Relay

[Noel Jones]

Carlos Williams wrote:

I just finished a new Postfix 2.6 installation on a Debian server in a
co-location and just wanted to make sure I am properly testing this
machine is not a 'open relay' before I open it out to the public:

I was told to go to the following URL http://www.abuse.net/relay.html
and I entered my external IP address in the 1st line and nothing else.
After 17 tests, I get the following at the bottom:

"Relay test result
All tests performed, no relays accepted."

Does this mean I am safe? I read somewhere that in my main.cf I should
have the following entry:

relay_domains =


Yes, this is usually a good idea if you don't have 
relay_domains (a domain you are MX for, but final delivery is 
elsewhere).




"relay_domains: is a list of destination domains this system will
relay mail to. 


Correct.


By setting it to be blank we ensure that our mail
server isn't acting as an open relay for untrusted networks. 


Not exactly.  The "danger" is that by default postfix will 
accept subdomains of domains listed in mydestination, which 
are then undeliverable and must be bounced.

An example:
mydestination = example.com
postfix will by default accept mail to any...@foo.example.com, 
which will be undeliverable and must be bounced, creating 
backscatter.  This is usually a minor problem, but it's easily 
fixed.  It certainly isn't an "open relay".



The
reader is advised to test that their system isn't acting as an open
relay here: http://www.abuse.net/relay.html";


That's good advice, but it takes some real bone-headed moves 
to make postfix a real open relay.




Now that being said, I don't have relay_domains entry in my main.cf
however according to the site they recommend I test, I don't appear to
be one. Do I need this entry in my main.cf or am I fine? Is there an
other way to test for being an open relay or should I feel safe about
this?


Add "relay_domain =" to your main.cf.  It does prevent a minor 
problem.





*postconf -n*


no glaring errors.

  -- Noel Jones

Am I an open relay?

[Dave]

Hello,
I'm adjusting my postfix configuration to try to cut down on the spam i'm
getting. I have noticed an event in my maillog that has me concerned that
i'm now inadvertently an open relay. If this is so i'd like to fix it.
Here's the error:

Aug  4 11:18:12  postfix/smtp[22025]: 48A91150900A8:
to=,
relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31,
delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok)
Aug  4 11:18:12  postfix/qmgr[21957]: 48A91150900A8: removed

And a postconf -n:

address_verify_map = btree:/var/spool/postfix/verified_senders
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
biff = no
broken_sasl_auth_clients = yes
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
inet_interfaces = 127.0.0.1, 
invalid_hostname_reject_code = 554
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 104857600
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 20971520
mime_header_checks = pcre:/etc/postfix/mime_header_checks
multi_recipient_bounce_reject_code = 554
mydomain = example.com
myhostname = mail.example.com
mynetworks = 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_fqdn_reject_code = 554
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
recipient_delimiter = +
relay_domains_reject_code = 554
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
show_user_unknown_table_name = no
smtp_helo_timeout = 60s
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
reject_unverified_sender reject_unverified_recipient
reject_multi_recipient_bounce, permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination,  check_recipient_access
pcre:/etc/postfix/recipient_checks.pcre,check_helo_access
hash:/etc/postfix/helo_checks, check_helo_access
pcre:/etc/postfix/helo_checks.pcre check_sender_mx_access
cidr:/etc/postfix/bogus_mx  reject_rbl_client zen.spamhaus.org,
reject_rbl_client black.uribl.com, reject_rbl_client combined.rbl.msrbl.net,
reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = 
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/postfix/ssl/ca-cert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/ssl/smtp.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtp.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_cache
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
unknown_relay_recipient_reject_code = 554
unknown_virtual_alias_reject_code = 554
unknown_virtual_mailbox_reject_code = 554
unverified_recipient_reject_code = 554
unverified_sender_reject_code = 554
virtual_alias_maps = hash:/etc/postfix/virtual_alias
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = /etc/postfix/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 1000
virtual_uid_maps = static:5000

Thanks.
Dave.

Re: Open relay, found it

[Paul van der Vlis]

Op 23-10-16 om 13:32 schreef Ansgar Wiechers:
> On 2016-10-23 Paul van der Vlis wrote:
>> Op 22-10-16 om 18:23 schreef /dev/rob0:
>>> The only actual conclusion is that you have failed to put forth the 
>>> necessary information, as Bill [I think] pointed you to the 
>>> http://www.postfix.org/DEBUG_README.html#mail link.
>>
>> The problem is that somebody did send spam using port 587 with a not
>> excisting username, and I am interested how that is possible.
>>
>> sigmund:/var/log# postconf -Mf
> 
> So you finally decided to show the output of "postconf -Mf" and
> "saslfinger -s". Good. Now you just need to provide the rest of the
> information Bill Cole asked of you 2 days ago:
> 
> - Full output of "postconf -nf".
> - Full headers of a sample message (you may obfuscate personal
>   information about the recipient).
> - All log lines associated with that particular message. At the very
>   least the output of "grep  /var/log/mail.log".

I am sorry when I did not give the right information. I did read the
link, and did what was asked there.

>   In case you don't know how to find the queue ID in a log message, it's
>   this part of the log line:
> 
> postfix/smtpd[]: 2758BBF4062: ...
>   ^^^
> And did you already investigate why the authentication backend considers
> "p...@puk.nl" a valid user, as Noel Jones asked? What did you find out?

Yes, and I found out that when the username is "p...@puk.nl" SASL
actually checks on "piet":
--
saslauthd[19855] :do_auth : auth success: [user=piet]
[service=smtp] [realm=puk.nl] [mech=pam]
--

I did some more tests, and it seems to be that the spammer actually did
know the password. After changing the password, the logging changed:
--
saslauthd[20161] :do_auth : auth failure: [user=piet]
[service=smtp] [realm=puk.nl] [mech=pam]
-



With regards,
Paul van der Vlis.



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

RE: Open relay, found it

[L . P . H . van Belle]

Hai Paul, 

I saw you got it fixed, comprimized pass as i suspected.  ;-) 

I saw also this in you log. 
from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206] 

This should never be allowed. ( from 127.0.0.1 ) ( on the external ip )
Thats impossible imo.

To fix that you can use something like below. 
Just make sure every known hostname and ipnumber of the server is listed here. 

Beware with these 3, these can give false positives.
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname, 


(pcre:/etc/postfix/helo.pcre) 
## Namebase
/^ip6-localhost$/   554 Don't use my own hostname
/^localhost$/   554 Don't use my own hostname
/^localhost\.localdomain$/  554 Don't use my own hostname
/^localhost\.yourdomain\.tld$/   554 Don't use my own hostname
/^localhost\.subdom\.yourdomain\.tld$/554 Don't use my own hostname

/^yourdomain\.tld$/  554 Don't use my own domainname
/^hostname\.yourdomain\.tld$/  554 Don't use my own hostname
/^hostname\.subdom\.yourdomain\.tld$/   554 Don't use my own hostname

## IP Based
/^127\.0\.0\.1$/554 Don't use my own IP address
/^\[127\.0\.0\.1\]$/554 Don't use my own IP address
/^\:\:1$/   554 Don't use my own IP address
/^\[\:\:1\]$/   554 Don't use my own IP address
/^\1\.2\.3\.4$/ 554 Don't use my own IP address
/^\[1\.2\.3\.4]$/   554 Don't use my own IP address
# and add ipv6 ip if you use it.

## Optional, but can gives false blocks.
#/^[0-9.]+$/ 554 Your software is not RFC 2821 compliant: 
EHLO/HELO must be a hostname.domain.tld or an address-literal (IP enclosed in 
brackets)
#/^[0-9]+(\.[0-9]+){3}$/ 554 Your software is not RFC 2821 compliant: 
EHLO/HELO must be a hostname.domain.tld or an address-literal (IP enclosed in 
brackets)
# /^[0-9.-]+$/   550 Your software is not RFC 2821 compliant: 
EHLO/HELO must be a hostname.domain.tld or an address-literal (IP enclosed in 
brackets)
# /^[0-9]+(\.[0-9]+){3}$/   REJECT Invalid hostname


# added in main.cf
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access hash:/etc/postfix/overrule/allow_helo_access.map
check_helo_access pcre:/etc/postfix/pcre/helo.pcre,
permit_sasl_authenticated,
   reject_invalid_helo_hostname,
   reject_non_fqdn_helo_hostname,
   reject_unknown_helo_hostname,
reject_unauth_destination,
reject_unauth_pipelining


Greetz, 

Louis



> -Oorspronkelijk bericht-
> Van: p...@vandervlis.nl [mailto:owner-postfix-us...@postfix.org] Namens
> Paul van der Vlis
> Verzonden: zondag 23 oktober 2016 13:51
> Aan: postfix-users@postfix.org
> Onderwerp: Re: Open relay, found it
> 
> Op 23-10-16 om 13:32 schreef Ansgar Wiechers:
> > On 2016-10-23 Paul van der Vlis wrote:
> >> Op 22-10-16 om 18:23 schreef /dev/rob0:
> >>> The only actual conclusion is that you have failed to put forth the
> >>> necessary information, as Bill [I think] pointed you to the
> >>> http://www.postfix.org/DEBUG_README.html#mail link.
> >>
> >> The problem is that somebody did send spam using port 587 with a not
> >> excisting username, and I am interested how that is possible.
> >>
> >> sigmund:/var/log# postconf -Mf
> >
> > So you finally decided to show the output of "postconf -Mf" and
> > "saslfinger -s". Good. Now you just need to provide the rest of the
> > information Bill Cole asked of you 2 days ago:
> >
> > - Full output of "postconf -nf".
> > - Full headers of a sample message (you may obfuscate personal
> >   information about the recipient).
> > - All log lines associated with that particular message. At the very
> >   least the output of "grep  /var/log/mail.log".
> 
> I am sorry when I did not give the right information. I did read the
> link, and did what was asked there.
> 
> >   In case you don't know how to find the queue ID in a log message, it's
> >   this part of the log line:
> >
> > postfix/smtpd[]: 2758BBF4062: ...
> >   ^^^
> > And did you already investigate why the authentication backend considers
> > "p...@puk.nl" a valid user, as Noel Jones asked? What did you find out?
> 
> Yes, and I found out that when the username is "p...@puk.nl" SASL
> actually checks on "piet":
> --
> saslauthd[19855] :do_auth : auth success: [user=piet]
> [service=smtp] [realm=puk.nl] [mech=pam]
> --
> 
> I did some more tests, and it seems to be that the spammer actually did
> know the password. After changing the password, the logging changed:
> --
> saslauthd[20161] :do_auth : auth failure: [user=piet]
> [service=smtp] [realm=puk.nl] [mech=pam]
> -
> 
> 
> 
> With regards,
> Paul van der Vlis.
> 
> 
> 
> --
> Paul van der Vlis Linux systeembeheer Groningen
> https://www.vandervlis.nl/

authenticated open relay postfix-mysql

[Lang Alex]

Hi there,

-debian 7, postfix 2.9.6
-no local domain, no mailboxes (root also aliased out of machine)
-only open relay with authorized people, mysql db backend
-no long way:   postfix -dovecot sasl - pam - mysql conect
-only direct:   postfix - local mysql ( - view to remote dbs,thats 
another story)


is it possible?

or any auth login/passwd means sasl thus dovecot is a must?

I googled for some time, have not found simple yes/no, nor some 
no-sasl-howto


Thanks for clarification,

Alex

Re: Concern of open relay

[Leonardo Rodrigues]

Em 07/07/14 13:24, Ben Johnson escreveu:

Hello!

I've noticed increased Postfix activity as of late and am concerned that
something is configured inadequately (i.e., open-relay). For "postconf
-n" output, please skip to the end of this message.



It's much easier that you had some account hijacked and bots are 
using it to send the messages. Check the queueids of some messages 
looking for the sasl_username used for sending it. If you find lots of 
suspect messages sent by the same user, then you find your problem !


--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertru...@solutti.com.br
My SPAMTRAP, do not email it

Re: Concern of open relay

[Noel Jones]

On 7/7/2014 11:56 AM, Leonardo Rodrigues wrote:
> Em 07/07/14 13:24, Ben Johnson escreveu:
>> Hello!
>>
>> I've noticed increased Postfix activity as of late and am
>> concerned that
>> something is configured inadequately (i.e., open-relay). For
>> "postconf
>> -n" output, please skip to the end of this message.
>>
> 
> It's much easier that you had some account hijacked and bots are
> using it to send the messages. Check the queueids of some messages
> looking for the sasl_username used for sending it. If you find lots
> of suspect messages sent by the same user, then you find your problem !
> 


And it's not unusual to find spammers abusing some web form to send
spam.  Check your web server logs for evidence.



  -- Noel Jones

Re: Concern of open relay

[Ben Johnson]

On 7/7/2014 1:45 PM, Noel Jones wrote:
> On 7/7/2014 11:56 AM, Leonardo Rodrigues wrote:
>> Em 07/07/14 13:24, Ben Johnson escreveu:
>>> Hello!
>>>
>>> I've noticed increased Postfix activity as of late and am
>>> concerned that
>>> something is configured inadequately (i.e., open-relay). For
>>> "postconf
>>> -n" output, please skip to the end of this message.
>>>
>>
>> It's much easier that you had some account hijacked and bots are
>> using it to send the messages. Check the queueids of some messages
>> looking for the sasl_username used for sending it. If you find lots
>> of suspect messages sent by the same user, then you find your problem !
>>
> 
> 
> And it's not unusual to find spammers abusing some web form to send
> spam.  Check your web server logs for evidence.
> 
> 
> 
>   -- Noel Jones
> 
> 

Thanks, Leonardo and Noel! I really appreciate the prompt replies.

Leonardo, I see no indication that whomever is sending this mail has
authenticated. And given that local connections are permitted to send
mail without authenticating on this server, I will pursue Noel's
suggested course of action next.

I'll let you know if I can't find the source...

Thanks again,

-Ben

Re: Concern of open relay

[Ben Johnson]

On 7/7/2014 2:47 PM, Ben Johnson wrote:
> Thanks, Leonardo and Noel! I really appreciate the prompt replies.
> 
> Leonardo, I see no indication that whomever is sending this mail has
> authenticated. And given that local connections are permitted to send
> mail without authenticating on this server, I will pursue Noel's
> suggested course of action next.
> 
> I'll let you know if I can't find the source...
> 
> Thanks again,
> 
> -Ben

You were right!

It was a compromised Joomla site. I was able to spot it almost
immediately due to excessive CPU usage.

What's disconcerting is that the Joomla site is completely up-to-date,
including all extensions, so the vulnerability is either zero-day or
with another stack component. But that's here nor there.

Thanks again, both of you!

-Ben

Re: Concern of open relay

[li...@rhsoft.net]

Am 07.07.2014 22:44, schrieb Ben Johnson:
> On 7/7/2014 2:47 PM, Ben Johnson wrote:
>> Thanks, Leonardo and Noel! I really appreciate the prompt replies.
>>
>> Leonardo, I see no indication that whomever is sending this mail has
>> authenticated. And given that local connections are permitted to send
>> mail without authenticating on this server, I will pursue Noel's
>> suggested course of action next.
>>
>> I'll let you know if I can't find the source...
>>
>> Thanks again,
>>
>> -Ben
> 
> You were right!
> 
> It was a compromised Joomla site. I was able to spot it almost
> immediately due to excessive CPU usage.
> 
> What's disconcerting is that the Joomla site is completely up-to-date,
> including all extensions, so the vulnerability is either zero-day or
> with another stack component. But that's here nor there

more likely it is using one of the tons of crap plugins written by a monkey
i faced Joomla plugins with code nobody right in his brain ever writes like
"file_put_contents($random_request_var, $random_request_var); in some gallery
plugin years ago

most plugins are written by clueless people for their own needs which
think they do someboddy a favor by make them public and no longer care
for updates as never cared for security by missing knowledge

rule 1: don't install Joomla if you care for security at all
rule 2: if you think you need it anyways don't install random plugins

the most important rule: *never ever* allow endusers to install any plugin

Is it an open relay?

[Roger Walters]

Hello,

Doing a research work about wrongly configured mail MTAs and how they
contribute to spam, I found out a bunch of domains which seem to be open
relays, however, the outgoing e-mails never seem to arrive to the specified
RCPT TO address.

The conversation seems somewhat like this:

roger@walters ~ $ telnet supposedlyopenrelay.com 25
Trying 216.XXX.XXX.XXX...
Connected to supposedlyopenrelay.com.
Escape character is '^]'.
220 xxx.xxx.com ESMTP Postfix
EHLO supposedlyopenrelay.com
250-xxx.xxx.com
250-PIPELINING
250-SIZE 1
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: 
250 2.1.0 Ok
RCPT TO: 
250 2.1.5 Ok
DATA
354 End data with .
Test!

.
250 2.0.0 Ok: queued as 7D688A9A7CF48
quit
221 2.0.0 Bye
Connection closed by foreign host.

As far as I know, if the MTA generates a queue ID, it means the message has
been accepted for delivery. However, although the RCPT TO domain is mine, I
don't see anything in the mail log about that host even trying to connect
mine!

So my question is: Even if the host doesn't seem to be sending that e-mail,
it has been accepted for delivery, so should it be considered as an open
relay? And just by curiosity, what could be blocking this delivery if the
host isn't even trying to connect to my mail server?

Thanks for any hint.

Regards,

Roger Walters

Re: Fixing open relay problem

[Dominic Raferd]

On Tue, 22 Jan 2019 at 06:22, Stephen McHenry 
wrote:

> I've been running Postfix for many years now (so thanks to Wietse and all
> the others who have put in hard work to make it such a great mail system)
> and recently I built a new mail server and copied most of the config files
> from the old one.
>
> After a couple of months, I began to notice that it appeared to be getting
> used (infrequently) as an open relay, despite my attempts to lock it down
> so that couldn't happen. Then, the problem got worse. The one pattern I
> noticed was that all the messages had forged senders that were from my
> domain (e.g., bogussen...@mydomain.com).
>
> I've poured through the documentation, and a couple of times thought I
> found the answer, only to make a change and have it not work. My band-aid
> (while researching the real solution) has been to firewall off access from
> IP address ranges that were the sources of the email. But to be clear,
> that's only a band-aid until a real solution is in place.
>
> The two config parameters that seem most relevant to the problem are
> listed below:
> (from postconf -n)
>
> *smtpd*_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, permit_auth_destination, reject_non_fqdn_sender,
> reject_non_fqdn_recipient, reject_unknown_sender_domain,
> reject_unknown_recipient_domain, reject_unauth_destination,
> reject_unlisted_recipient, reject_unauth_destination check_recipient_access
> regexp:/etc/postfix/recipient_checks.regexp, check_recipient_access
> hash:/etc/postfix/recipient_checks, reject_unauth_pipelining,
> reject_invalid_hostname, reject_non_fqdn_hostname, reject_rbl_client
> domain-name, permit
>
>
> (and from postconf -d)
>
> *smtpd*_relay_restrictions = permit_mynetworks,
> permit_sasl_authenticated, defer_unauth_destination
>
> What's really confounding me is that it seems to be (properly) rejecting
> all relay email except those that have mydomain.com in their from
> address. Adding to that confusion is that this same set of config
> parameters used to work fine on the old system, so I've also been looking
> at relevant defaults that changed. Unfortunately, I'm coming up dry at this
> point.
>
> Any help or pointers would be greatly appreciated.
>

I think you are just lucky that this didn't happen till now. Note that
postconf -d just shows the defaults, not what you are using.

My approach (a typical one I think) is to block all emails with envelope
sender @mydomain.com unless the client has authenticated via port 465 or
587:

master.cf:
#note - smtps is port 465
465   inet  n   -   y   -   -   smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o
smtpd_recipient_restrictions=$smtpd_recipient_restrictions_authenticated
#submission=port 587
587inet  n   -   y   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
  -o syslog_name=postfix/submission
  -o smtpd_sasl_auth_enable=yes
  -o
smtpd_recipient_restrictions=$smtpd_recipient_restrictions_authenticated

main.cf:
...
# for authenticated senders only
smtpd_recipient_restrictions_authenticated =
# make the implicit permit explicit
permit
# for all others
smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/sender_access
...
...

sender_access:
...
mydomain.com REJECT privileged domain without authentication
...

Note: this stops fake envelope sender using domain.com, but does not stop
fake 'From:' header using domain.com; for the latter I use DMARC. I also
use header_checks to detect fakes such as From: domi...@mydomain.com <
fakesen...@fakedomain.com>.

Re: Fixing open relay problem

[Larry Stone]

On Jan 22, 2019, at 1:30 AM, Dominic Raferd  wrote:
> 
> On Tue, 22 Jan 2019 at 06:22, Stephen McHenry  
> wrote:
>> (and from postconf -d)
>> smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
>> defer_unauth_destination
>> 
>> 
> I think you are just lucky that this didn't happen till now. Note that 
> postconf -d just shows the defaults, not what you are using.
> 

Yes. Please shows us the postconf -n value of smtpd_relay_restrictions

> My approach (a typical one I think) is to block all emails with envelope 
> sender @mydomain.com unless the client has authenticated via port 465 or 587:

Not so typical IMHO. And probably unneeded to solve the OP’s problem. Once we 
see what he really had in smtp_relay_restrictions, we are likely to find a 
simple issue there that he can easily fix.

-- 
Larry Stone
lston...@stonejongleux.com

Re: Fixing open relay problem

[Viktor Dukhovni]

On Mon, Jan 21, 2019 at 10:21:07PM -0800, Stephen McHenry wrote:

> The two config parameters that seem most relevant to the problem are listed
> below:
> (from postconf -n)
> 
> smtpd_recipient_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   permit_auth_destination,

Though it does not explain the purported open relay issue,
"permit_auth_destination" here makes no sense.  I think you should
delete it.  Anything it does not permit is sure to be blocked below,
so it is simpler to just move "reject_unauth_destination" here
(multiple back-to-back conditional rejects "commute" and a conditional
permit followed by the opposite reject is equivalent to that permit
followed by an unconditional "reject").  So this is effectively your
last rule.

>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_destination,

With the "permit_auth_destination" above, nothing ever gets past
this point.  So all the rules below are then pointless.

>   reject_unlisted_recipient,
>   reject_unauth_destination,
>   check_recipient_access regexp:/etc/postfix/recipient_checks.regexp,
>   check_recipient_access hash:/etc/postfix/recipient_checks,
>   reject_unauth_pipelining,
>   reject_invalid_hostname,
>   reject_non_fqdn_hostname,
>   reject_rbl_client domain-name,
>   permit

> (and from postconf -d)
> 
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   defer_unauth_destination

I charitably assume you're posting "postconf -d" because you don't
specify this at all in main.cf.  It is best to not let the default
stand in this case, and to replace "defer_unauth_destination" with
"reject_unauth_destination".

With that default in place, relaying can only happen:

1.  From clients in "mynetworks"
2.  From SASL authenticated accounts
3.  To domains listed in mydestination, relay_domains,
virtual_mailbox_domains, virtual_alias_domains.

So if mail from 3rd parties is being routed to 3rd parties, one of
these three is the problem.  The 3rd can be an issue if something
in your system is resending mail based on "To/Cc" headers, rather
than the message envelope.  Check for misconfigured message processing
code.

Finally, make sure that the "open relay" messages are actually coming
in via SMTP.  There's always web forms, and the like.

> What's really confounding me is that it seems to be (properly) rejecting
> all relay email except those that have mydomain.com in their from address.
> Adding to that confusion is that this same set of config parameters used to
> work fine on the old system, so I've also been looking at relevant defaults
> that changed. Unfortunately, I'm coming up dry at this point.
> 
> Any help or pointers would be greatly appreciated.

1.  You should check master.cf, and especially its "submission" entry
for any poorly configured rules.

2.  You should post the *full* output of "postconf -nf" with
no reformatting of the output even to change line breaks.

3.  You should post logs that show Postfix accepting and
delivering an instance of unauthorized relaying.

4.  Make sure you don't have any compromised SASL accounts

5.  Make sure that "mynetworks" is not misconfigured.

6.  Make sure that master.cf overrides (postconf -Mf?) are
not breaking relay control for either port 25, or submission,
...

-- 
Viktor.

Re: Fixing open relay problem

[Stephen McHenry]

On Tue, Jan 22, 2019 at 6:49 AM Viktor Dukhovni 
wrote:

> On Mon, Jan 21, 2019 at 10:21:07PM -0800, Stephen McHenry wrote:
>
> > The two config parameters that seem most relevant to the problem are
> listed
> > below:
> > (from postconf -n)
> >
> > smtpd_recipient_restrictions =
> >   permit_mynetworks,
> >   permit_sasl_authenticated,
> >   permit_auth_destination,
>
> Though it does not explain the purported open relay issue,
> "permit_auth_destination" here makes no sense.  I think you should
> delete it.  Anything it does not permit is sure to be blocked below,
> so it is simpler to just move "reject_unauth_destination" here
> (multiple back-to-back conditional rejects "commute" and a conditional
> permit followed by the opposite reject is equivalent to that permit
> followed by an unconditional "reject").  So this is effectively your
> last rule.
>
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >   reject_unknown_sender_domain,
> >   reject_unknown_recipient_domain,
> >   reject_unauth_destination,
>
> With the "permit_auth_destination" above, nothing ever gets past
> this point.  So all the rules below are then pointless.
>
> >   reject_unlisted_recipient,
> >   reject_unauth_destination,
> >   check_recipient_access regexp:/etc/postfix/recipient_checks.regexp,
> >   check_recipient_access hash:/etc/postfix/recipient_checks,
> >   reject_unauth_pipelining,
> >   reject_invalid_hostname,
> >   reject_non_fqdn_hostname,
> >   reject_rbl_client domain-name,
> >   permit
>

Good suggestions. I will make this change.

>
> > (and from postconf -d)
> >
> > smtpd_relay_restrictions =
> >   permit_mynetworks,
> >   permit_sasl_authenticated,
> >   defer_unauth_destination
>
> I charitably assume you're posting "postconf -d" because you don't
> specify this at all in main.cf.


Yes, that was why.


> It is best to not let the default
> stand in this case, and to replace "defer_unauth_destination" with
> "reject_unauth_destination".
>

Will make this change too.

I wonder if it would make sense to do some sort of a "postlint" to check
for configuration problems - at least the obvious ones. Maybe there are too
many variations in how servers need to be configured to be practical. Dunno.

>
> With that default in place, relaying can only happen:
>
> 1.  From clients in "mynetworks"
> 2.  From SASL authenticated accounts
> 3.  To domains listed in mydestination, relay_domains,
>     virtual_mailbox_domains, virtual_alias_domains.
>
> So if mail from 3rd parties is being routed to 3rd parties, one of
> these three is the problem.  The 3rd can be an issue if something
> in your system is resending mail based on "To/Cc" headers, rather
> than the message envelope.  Check for misconfigured message processing
> code.
>
> Finally, make sure that the "open relay" messages are actually coming
> in via SMTP.  There's always web forms, and the like.
>
> > What's really confounding me is that it seems to be (properly) rejecting
> > all relay email except those that have mydomain.com in their from
> address.
> > Adding to that confusion is that this same set of config parameters used
> to
> > work fine on the old system, so I've also been looking at relevant
> defaults
> > that changed. Unfortunately, I'm coming up dry at this point.
> >
> > Any help or pointers would be greatly appreciated.
>
> 1.  You should check master.cf, and especially its "submission" entry
> for any poorly configured rules.
>
> 2.  You should post the *full* output of "postconf -nf" with
> no reformatting of the output even to change line breaks.
>
> 3.  You should post logs that show Postfix accepting and
> delivering an instance of unauthorized relaying.
>

While I was distilling some log records for #3, I discovered that #4 looked
like it was the problem. I guess I'm so conditioned to thinking that a
problem is due to something I did (e.g., misconfig), that I started diving
into config files without stopping to think of this (obvious) one.

I changed the password on the account that looked to be compromised,
unblocked the firewall rules for "the world", and all has been quiet on the
western front - in terms of actual relaying, that is... I've had 1487
attempts from 77 different hosts since I made these changes. The reason for
my delay

Open Relay on local lan

[Software Information]

 Hi All
I have my postfix server up and running now for some time. Recently though,
auditors made a deal that the server is an open relay. It is true that on
the local lan it is. What's the best way to change this behavior? For
example, is there a way to configure postfix to accept mail from say two
domains, test.net and test.com but no other?

Regards
SI

Re: Open relay or compromised user?

[Noel Jones]

Guy wrote:

Hi guys,

I've got some mail in the queue that's clearly spam. The from address
is [EMAIL PROTECTED] and the source server is
"7c.91.5746.static.theplanet.com [70.87.145.124]" The recipient
addresses are random domains that do not belong to me. The server is
supposed to be a gateway and outgoing server for our users.

I've tried telnet to port 25 on the box and get relay access denied
trying to send to a non local domain (gmail.com). So either my config
is completely screwed (which is very possible) or I've got a
compromised user. If it's a compromised user, is it possible for
postfix to include the authenticated username in the message headers?

Below is a postconf -n from the gateway/smtp server. Any advice on
what I'm missing or bad settings would be great. Also, which of the
standard config examples would cover what I'm trying to do with this
server? Or should I just start reading through the base configuration?
Or should I just hurry up and get the Book of Postfix? :P

Thanks
Guy



You don't appear to have any errors in your postconf -n that 
could possibly cause an open relay.


To find the source of the spam, grep your logs for the QUEUEID 
displayed by the mailq command.  If the mail has been in the 
logs a couple days, you may need to examine logs that have 
been rotated out.  The objective is to find the first entry 
referring to the unwanted mail and determine how it entered 
postfix.  If it was SASL authenticated, that will be logged.
Another common point of abuse is web scripts.  If your server 
has www software on it, that could be the problem.


Postfix 2.3 and later can report the sasl user in the headers;
http://www.postfix.org/postconf.5.html#smtpd_sasl_authenticated_header

Postfix 2.5 and newer also support RFC 3848 to report 
authentication/encryption status in the Received: header, but 
this doesn't record the user name.


--
Noel Jones



[EMAIL PROTECTED]:/var/spool/postfix/hold# postconf -n
2bounce_notice_recipient = [EMAIL PROTECTED]
anvil_rate_time_unit = 60s
bounce_notice_recipient = [EMAIL PROTECTED]
bounce_template_file = /etc/postfix/bounce.cf
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
cyrus_sasl_config_path = /etc/postfix/sasl/
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 30
delay_notice_recipient = [EMAIL PROTECTED]
error_notice_recipient = [EMAIL PROTECTED]
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.2.10/html
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains = sbl-xbl.spamhaus.org
message_size_limit = 3124
mynetworks = 127.0.0.0/8, 72.9.230.26
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.2.10/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_connection_count_limit = 30
smtpd_client_connection_rate_limit = 100
smtpd_client_message_rate_limit = 100
smtpd_client_recipient_rate_limit = 100
smtpd_error_sleep_time = 1s
smtpd_hard_error_limit = 20
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,  reject_invalid_hostname,
reject_non_fqdn_sender, reject_unknown_sender_domain,
reject_unauth_destination,  check_recipient_access
hash:/etc/postfix/spamlovers,  check_client_access
cidr:/etc/postfix/postfix-dnswl-permit, reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
reject_rbl_client psbl.surriel.com,   reject_rhsbl_client
zen.spamhaus.org,   reject_rhsbl_client bl.spamcop.net,
check_policy_service inet:127.0.0.1:10031,  permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_soft_error_limit = 10
smtpd_tls_CAfile = /etc/ssl/certs/ca-bundle.crt
smtpd_tls_cert_file = /etc/ssl/certs/imapd.pem
smtpd_tls_key_file = /etc/ssl/private/imapd.pem
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
mysql:/etc/postfix/mysql_virtual_catchall_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_transport = smtp:barracuda.aluminati.org

Re: Open relay or compromised user?

[Guy]

Hi Noel

2008/11/19 Noel Jones <[EMAIL PROTECTED]>:
> You don't appear to have any errors in your postconf -n that could possibly
> cause an open relay.

Thanks for looking.

> To find the source of the spam, grep your logs for the QUEUEID displayed by
> the mailq command.  If the mail has been in the logs a couple days, you may
> need to examine logs that have been rotated out.  The objective is to find
> the first entry referring to the unwanted mail and determine how it entered
> postfix.  If it was SASL authenticated, that will be logged.
> Another common point of abuse is web scripts.  If your server has www
> software on it, that could be the problem.

There is no web server on the machine. Apparently my brain is switched
off though, not looking for the sasl line in the logs.
Feel just a leeetle stupid right now. :P

Thanks
Guy

-- 
Don't just do something...sit there!

Re: Open relay or compromised user?

[mouss]

Guy a écrit :
> Hi guys,
> 
> I've got some mail in the queue that's clearly spam. The from address
> is [EMAIL PROTECTED] and the source server is
> "7c.91.5746.static.theplanet.com [70.87.145.124]" The recipient
> addresses are random domains that do not belong to me. The server is
> supposed to be a gateway and outgoing server for our users.
> 
> I've tried telnet to port 25 on the box and get relay access denied
> trying to send to a non local domain (gmail.com). So either my config
> is completely screwed (which is very possible) or I've got a
> compromised user. If it's a compromised user, is it possible for
> postfix to include the authenticated username in the message headers?
>


your logs should tell you whether the transaction was authenticated.
look for sasl_username.

if you want headers to contain submission infos, set:

smtpd_sasl_authenticated_header = yes
smtpd_tls_received_header = yes



> [snip]

internal open relay, but 'relaying denied'

[Mattias Berge]

Hi,

I want to configure an local open relay, no authentication etc.
I get "Relaying denied" from the local networks in mynetwork.

Can anyone help me by telling me what I am missing?

Dec  5 15:06:12 smtp postfix/smtpd[10374]: connect from unknown[10.47.17.193
]
Dec  5 15:06:12 smtp postfix/smtpd[10374]: NOQUEUE: reject: RCPT from
unknown[10.47.17.193]: 554 5.7.1 <[EMAIL PROTECTED]>: Relay access denied;
 from=<[EMAIL PROTECTED]> to=<[EMAIL PROTECTED]> proto=ESMTP 
helo=<[10.47.17.193]>
Dec  5 15:06:12 smtp postfix/smtpd[10374]: disconnect from unknown[
10.47.17.193]

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
local_recipient_maps =
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = relay.myhost.se, localhost
myhostname = relay.myhost.se
mynetworks = 127.0.0.0/8, 10.57.17.0/24, 192.168.100.0/24, 1.2.3.4/32
recipient_delimiter = +
relay_domains =
relay_recipient_maps =
relayhost =
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes


-- 
Mattias Berge

Re: Help, still an open relay.?

[Victor Duchovni]

On Tue, Apr 06, 2010 at 01:21:26PM -0800, M M wrote:

> [...] my server is an open relay according to online tests.
> 
> mynetworks = 127.0.0.1/8, 198.100.50.0/24

Make sure external clients are not NAT translated into this address space.

> virtual_mailbox_domains =
>   mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Make sure this table does not match all lookup keys, report the output of:

$ postmap -q a.test mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

> virtual_alias_maps = 
> mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf

Make sure this table does not match all lookup keys, report the output of:

$ postmap -q a.test \
mysql:/etc/postfix/mysql-virtual-alias-maps.cf \
mysql:/etc/postfix/mysql-email2email.cf

> smtpd_recipient_restrictions =
>   reject_invalid_hostname,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   permit_mynetworks,
>   reject_unauth_destination,
>   permit_sasl_authenticated,
>   reject_unauth_pipelining, 

The "permit_sasl_authenticated" is pretty useless after
"reject_unauth_destination". With this, the only way for you to be an
"open relay" (show logs of messages you accepted that should not have
been accepted) is if mynetworks is wrong (NAT?) or the domain lists
(mydestination, virtual_alias_domains, virtual_mailbox_domains, ...)
are wrong. My bet is on misconfigured SQL queries.

-- 
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment.  If you are interested, please drop me a note.

RE: Help, still an open relay.?

[M M]

Solved!. Thanks

The problem was external clients were NAT translated. Had my network guy undo 
it and its working fine now!

Thanks again!

P.S - Victor,  what is the best practice to have smtpd_recipient_restrictions? 
in which order?

> Date: Tue, 6 Apr 2010 17:57:57 -0400
> From: victor.ducho...@morganstanley.com
> To: postfix-users@postfix.org
> Subject: Re: Help, still an open relay.?
> 
> On Tue, Apr 06, 2010 at 01:21:26PM -0800, M M wrote:
> 
>> [...] my server is an open relay according to online tests.
>> 
>> mynetworks = 127.0.0.1/8, 198.100.50.0/24
> 
> Make sure external clients are not NAT translated into this address space.
> 
>> virtual_mailbox_domains =
>>  mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
> 
> Make sure this table does not match all lookup keys, report the output of:
> 
> $ postmap -q a.test mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
> 
>> virtual_alias_maps = 
>> mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
> 
> Make sure this table does not match all lookup keys, report the output of:
> 
> $ postmap -q a.test \
>   mysql:/etc/postfix/mysql-virtual-alias-maps.cf \
>   mysql:/etc/postfix/mysql-email2email.cf
> 
>> smtpd_recipient_restrictions =
>>   reject_invalid_hostname,
>>   reject_non_fqdn_sender,
>>   reject_non_fqdn_recipient,
>>   reject_unknown_sender_domain,
>>   reject_unknown_recipient_domain,
>>   permit_mynetworks,
>>   reject_unauth_destination,
>>   permit_sasl_authenticated,
>>   reject_unauth_pipelining,    
> 
> The "permit_sasl_authenticated" is pretty useless after
> "reject_unauth_destination". With this, the only way for you to be an
> "open relay" (show logs of messages you accepted that should not have
> been accepted) is if mynetworks is wrong (NAT?) or the domain lists
> (mydestination, virtual_alias_domains, virtual_mailbox_domains, ...)
> are wrong. My bet is on misconfigured SQL queries.
> 
> -- 
>   Viktor.
> 
> P.S. Morgan Stanley is looking for a New York City based, Senior Unix
> system/email administrator to architect and sustain our perimeter email
> environment.  If you are interested, please drop me a note.
  
_
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

Re: Am I an open relay?

[Ralf Hildebrandt]

* Dave :
> Hello,
> I'm adjusting my postfix configuration to try to cut down on the spam i'm
> getting. I have noticed an event in my maillog that has me concerned that
> i'm now inadvertently an open relay. If this is so i'd like to fix it.
> Here's the error:
> 
> Aug  4 11:18:12  postfix/smtp[22025]: 48A91150900A8:
> to=,
> relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31,
> delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok)
> Aug  4 11:18:12  postfix/qmgr[21957]: 48A91150900A8: removed

And the other entries for 48A91150900A8 ?

Not an open relay, unless you played clever tricks in master.cf

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Am I an open relay?

[Ralf Hildebrandt]

* Dave :
> Hello,
> I'm adjusting my postfix configuration to try to cut down on the spam i'm
> getting. I have noticed an event in my maillog that has me concerned that
> i'm now inadvertently an open relay. If this is so i'd like to fix it.
> Here's the error:
> 
> Aug  4 11:18:12  postfix/smtp[22025]: 48A91150900A8:
> to=,
> relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31,
> delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok)
> Aug  4 11:18:12  postfix/qmgr[21957]: 48A91150900A8: removed

That's sender address verification

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Am I an open relay?

[Noel Jones]

Dave wrote:

Hello,
I'm adjusting my postfix configuration to try to cut down on the spam i'm
getting. I have noticed an event in my maillog that has me concerned that
i'm now inadvertently an open relay. If this is so i'd like to fix it.
Here's the error:

Aug  4 11:18:12  postfix/smtp[22025]: 48A91150900A8:
to=,
relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31,
delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok)
Aug  4 11:18:12  postfix/qmgr[21957]: 48A91150900A8: removed


This is a sender verification probe from your 
reject_unverified_sender restriction.  Notice the 
"deliverable" tag.


As a general rule it's a bad idea to verify all senders since 
some mail admins see this as abuse and will blacklist you. 
Best use with caution.


  -- Noel Jones

RE: Am I an open relay?

[Dave]

Hi,
Thanks for your reply. For reject_unverified_sender  what would be a
better way of dealing with it?
Thanks.
Dave.


-Original Message-
From: Noel Jones [mailto:njo...@megan.vbhcs.org] 
Sent: Tuesday, August 04, 2009 1:02 PM
To: dave.meh...@gmail.com; postfix-users@postfix.org
Subject: Re: Am I an open relay?

Dave wrote:
> Hello,
> I'm adjusting my postfix configuration to try to cut down on the spam 
> i'm getting. I have noticed an event in my maillog that has me 
> concerned that i'm now inadvertently an open relay. If this is so i'd like
to fix it.
> Here's the error:
> 
> Aug  4 11:18:12  postfix/smtp[22025]: 48A91150900A8:
> to=,
> relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, 
> delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug  4 
> 11:18:12  postfix/qmgr[21957]: 48A91150900A8: removed

This is a sender verification probe from your reject_unverified_sender
restriction.  Notice the "deliverable" tag.

As a general rule it's a bad idea to verify all senders since some mail
admins see this as abuse and will blacklist you. 
Best use with caution.

   -- Noel Jones

RE: Am I an open relay?

[Dave]

Hello,
Thanks for your reply. I have not added any services to master.cf.
Thanks a lot.
Dave.
 

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Ralf Hildebrandt
Sent: Tuesday, August 04, 2009 12:59 PM
To: postfix-users@postfix.org
Subject: Re: Am I an open relay?

* Dave :
> Hello,
> I'm adjusting my postfix configuration to try to cut down on the spam 
> i'm getting. I have noticed an event in my maillog that has me 
> concerned that i'm now inadvertently an open relay. If this is so i'd like
to fix it.
> Here's the error:
> 
> Aug  4 11:18:12  postfix/smtp[22025]: 48A91150900A8:
> to=,
> relay=mail.autourdupiano.com[62.128.135.33]:25, delay=31, 
> delays=0/0/31/0.12, dsn=2.0.0, status=deliverable (250 ok) Aug  4 
> 11:18:12  postfix/qmgr[21957]: 48A91150900A8: removed

And the other entries for 48A91150900A8 ?

Not an open relay, unless you played clever tricks in master.cf

--
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Am I an open relay?

[Noel Jones]

Dave wrote:

Hi,
Thanks for your reply. For reject_unverified_sender  what would be a
better way of dealing with it?
Thanks.
Dave.


http://www.postfix.org/ADDRESS_VERIFICATION_README.html#forged_sender

Or decide if it really offers much value to your filtering. 
Most mail that would be rejected due to undeliverable sender 
can be rejected other ways.


  -- Noel Jones