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:

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

[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: [Feature-request] (smtpd_)milter_exceptions

[Wietse Venema]

Wietse Venema:
> Looks like either 1) an exclusion mechanism or 2) a selection
> mechanism would do the job.
> 
> 1) Nullifies the smtpd_milters setting depending on the client.
> 
> 2) Chooses the smtpd_milters setting depending on the client.
> 
> I'll think about it.

I've implemented the second variant. If you maintain configurations
by hand, then excluding mynetworks will be a bit of extra work. I
recommend that configurations aren't maintained by hand.

Wietse

smtpd_milter_maps (default: empty)
   Lookup tables  with  client  address-dependent  Milter  settings.   The
   lookup  result  overrides  the  smtpd_milters setting, and has the same
   syntax.

   Note: lookup tables cannot return empty  responses.  Specify  a  lookup
   result  of  DISABLE (case does not matter) to indicate that Milter sup-
   port should be disabled.

   Example to disable Milters for local clients:

   /etc/postfix/main.cf:
   smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_map
   smtpd_milters = inet:host:port, { inet:host:port, ... }, ...

   /etc/postfix/smtpd_milter_map:
   # Disable Milters for local clients.
   127.0.0.0/8DISABLE
   192.168.0.0/16 DISABLE
   ::/64  DISABLE
   2001:db8::/32  DISABLE

   This feature is available in Postfix 3.2 and later.

Re: permit after all

[Paul van der Vlis]

Op 22-10-16 om 19:49 schreef L.P.H. van Belle:
> paul, check if there are messages still in queue. 

I've cleaned the queue every minute using crontab, removing the mail
from that specific recipient.

> i had a comprimized account also and same as you it didnt stop. it did
> after clearing up the queue list.
> 
> the user in question has used its email and pass om a website which was
>  omprimized, at least thats what i think. 

No, I know the user. He is working for me.

And the "authenticated username" does not excist on the server as a user
what can authenticate. Only as an e-mail address.

> i my case i allow my users only from specific countries for smtp, 
> limited by firewalling. (xtables geoip)

My customers go in holliday or work in other countries.

> i also use zpush (active sync) through webserver, for mobile devices for
> other countrie support.
> 
> not a fix, but help avoiding this problem is abuse.
> 
> and check if you landed on black lists. 

I am. But I am not sure I can delist, because I don't know how they did
it. Maybe they start again.

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

[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

[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: 

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

[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

[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

[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

[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

[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: permit after all

[L . P . H . van Belle]

paul, check if there are messages still in queue. 


i had a comprimized account also and same as you it didnt stop. it did after 
clearing up the queue list.


the user in question has used its email and pass om a website which was  
omprimized, at least thats what i think. 


i my case i allow my users only from specific countries for smtp, 
limited by firewalling. (xtables geoip)


i also use zpush (active sync) through webserver, for mobile devices for other 
countrie support.


not a fix, but help avoiding this problem is abuse.


and check if you landed on black lists. 


greetz 


louis

Op 22 okt. 2016 om 19:31 heeft Bill Cole 
 het volgende geschreven:


On 22 Oct 2016, at 8:54, /dev/rob0 wrote:

Should "closing 'permit' lines" be removed from live
configurations?

Of course not.  That is how it works.  If not specified as the OP did
it, the ending value of any restriction stage is "permit".  If not,
mail would not be accepted at all.

Not exactly. In principle one can end a restriction list with 'reject' 
if all desired 'permit' cases are covered by previous directives. In 
smtpd_recipient_restrictions this implies a check_recipient_access 
directive that permits local recipients (obviously AFTER anti-spam 
restrictions). And of course, many master.cf files include a service 
defined like this:

submission inet  n   -   n   -   -   smtpd
-o syslog_name=postfix/submit
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

Re: permit after all

[Bill Cole]

On 22 Oct 2016, at 8:54, /dev/rob0 wrote:


Should "closing 'permit' lines" be removed from live
configurations?


Of course not.  That is how it works.  If not specified as the OP did
it, the ending value of any restriction stage is "permit".  If not,
mail would not be accepted at all.


Not exactly. In principle one can end a restriction list with 'reject' 
if all desired 'permit' cases are covered by previous directives. In 
smtpd_recipient_restrictions this implies a check_recipient_access 
directive that permits local recipients (obviously AFTER anti-spam 
restrictions). And of course, many master.cf files include a service 
defined like this:


submission inet  n   -   n   -   -   smtpd
-o syslog_name=postfix/submit
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

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

[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

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

[/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:

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:

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 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:

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

[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 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: permit after all

[/dev/rob0]

On Sat, Oct 22, 2016 at 09:33:35AM +0200, Geert Stappers wrote:
> On Sat, Oct 22, 2016 at 03:18:36PM +0900, Tomoyuki Murakami wrote:
> > On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis wrote:
> > > smtpd_relay_restrictions =

This is a strange choice for spam controls.  It's intended (as a new 
feature of Postfix 2.10) only to control permission for relaying.
Typically all the spam controls should go in recipient restrictions.
I don't suppose there is anything *wrong* with doing it this way, 
except that most of this has nothing to do with relaying, and it is 
confusing to someone who comes after you and has to understand the 
configuration you made.

> > >   permit_mynetworks,
> > >   permit_sasl_authenticated,

On port 25 one should not be allowing relay, so these don't belong.

> > >   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,

This is the only line that belongs here for port 25.  It should be 
overridden for the submission service:

[master.cf]
submission [ ... ] smtpd
-o smtpd_relay_restrictions=$mua_relay_restrictions
[ ... ]

[main.cf]

mua_relay_restrictions = permit_sasl_authenticated,
reject_unauth_destination

(permit_mynetworks deliberately omitted, because it's a better 
practice to always require AUTH from relaying clients, but those who 
still want IP-address-based relay permission can use it.)

> > >   check_policy_service unix:private/shadelist,
> > >   reject_rbl_client bl.spamcop.net,

This is an odd choice which can lead to a lot of woe.  Spamcop is an 
automated list which often is too aggressive in blocking.

> > >   reject_rbl_client zen.spamhaus.org,
> > >   reject_rbl_client ix.dnsbl.manitu.net,

I'm not personally familiar with this list so I wouldn't use it here.
I am familiar with and DO recommend using Zen, however.

> > >   permit
> > 
> > permit after all ?
> 
> Hummm. In networking firewall rules it common[1] to have
> a couple of deny rules with an allow rule closing such groups.
> 
> 
> Rereading http://www.postfix.org/SMTPD_ACCESS_README.html did
> not show any "closing permit".

Look again, the paragraph after the examples:
http://www.postfix.org/SMTPD_ACCESS_README.html#lists
"The end of the list is equivalent to a PERMIT result."

> Should "closing 'permit' lines" be removed from live 
> configurations?

Of course not.  That is how it works.  If not specified as the OP did 
it, the ending value of any restriction stage is "permit".  If not, 
mail would not be accepted at all.

> [1] Common sense is the least common sense of all :-(

In this case common sense is to keep rereading the aforementioned 
README until you get it. :)
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: [Feature-request] (smtpd_)milter_exceptions

[Wietse Venema]

Looks like either 1) an exclusion mechanism or 2) a selection
mechanism would do the job.

1) Nullifies the smtpd_milters setting depending on the client.

2) Chooses the smtpd_milters setting depending on the client.

I'll think about it.

Wietse

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 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

[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 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 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

[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

permit after all WAS: Open relay

[Geert Stappers]

On Sat, Oct 22, 2016 at 03:18:36PM +0900, Tomoyuki Murakami wrote:
> 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 ?

Hummm. In networking firewall rules it common[1] to have
a couple of deny rules with an allow rule closing such groups.


Rereading http://www.postfix.org/SMTPD_ACCESS_README.html did
not show any "closing permit".

Should "closing 'permit' lines" be removed from live configurations?


Groeten
Geert Stappers

[1] Common sense is the least common sense of all :-(
-- 
Leven en laten leven

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