[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

> It was common practice to allow your (from the ISP PoV) clients to submit
> mail via SMTP, through port 25 on your mailserver.  Some ISPs still do
this.
> The client authentication here is done via client IP address, no further
> checks.
>
> Next, enciphered and authenticated mail submission became common, where
> client can connect from the internet and submit mail, auithentication done
> via user/password (later using different ways).
>
> The alternative ports 465 and 587 are used here.  The authentication
should
> be mandatory on these ports, as well as encryption (on port 465
implicitly,
> before SMTP comes in, on port 587 using STARTTLS SMTP extension).
>
> Some providers started to require SMTP authentication for any mail
> submission long ago.
>
> Also, because port 25 is used for server-server communication, some
> providers started blocking their clients from connecting to port 25 of
> remote (or even local) hosts, preventing clients from sending spam this
way.

This is a good point. It seems odd they're presenting the functionality
they are
by using this port. In all other cases, it's 587.

> The sender address is completely unrelated to this, providers may or may
not
> verify, if the client is authorized to send mail from provided address,
e.g.
> compare login name to list of allowed sending addresses.
>
> Further, envelope (mail from:) and header From: senders may be two
different
> addresses (this question pops up here once in a while).
>
> From traditional point of view an open relay is mail server that allows
you
> to relay non-local mail without authentication - you connect, send mail,
> server will accept it and pass it to he recipient.
>
> The "local" in this case means any domain that is configured on server
> ("I handle this domain, so I accept mail for it").  Mail for such domain
may
> be delivered to local users (mail destination), or relay servers (mail
> gateway, backup MX servers) etc.
>
> SPF/DKIM/DMARC mechanism were designed for recipient of the mail, not for
> sending/relaying server.
>
> Yes, of course. I'm accidentally blurring the lines between these
discussions
> and my end goal. Although unlikely, I could make the decision SMTP is too
> insecure for my needs. (SMTP is supposed to function this way, but it
doesn't
> mean that it must be acceptable to me.)
>
> As others mentioned, this is very broad question.

Yes, that was intentional. It was to start a discussion, and to narrow it
as required.
If this mailing list isn't suitable, please point me to a better place (if
one is known).

> If you have mail server, nobody should stop you from sending mail to
anyone
> by connecting to recipients' SMTP servers, but nobody is required to
accept
> mail from you.

What I take from this is we want mail to get there rather than risk users
to lose
faith in the reliability of the system. If I have a problem with this
layout, I'd have
to argue elsewhere.

No one so far seems particularly surprised by my findings, and I mostly
expected
this. However, this has given me a few items to explore with the provider
that
I didn't have before.

On Wed, Apr 19, 2023 at 4:03 AM Matus UHLAR - fantomas via Postfix-users <
postfix-users@postfix.org> wrote:

> On 17.04.23 13:38, Tyler Montney via Postfix-users wrote:
> >Before getting started, this has been publicly disclosed by someone else a
> >while ago. However, I still don't think it's necessary to name the
> >organization to explain myself. My goal here is not only to give a proper
> >argument to the provider, but also my own curiosity and research (on the
> >workings of SMTP).
> >
> >I use a mail provider (Provider A) which has thousands of organizations.
> >This provider allows unauthenticated SMTP to other organizations so long
> as
> >they're using them as a provider (within their ecosystem). Of course, you
> >cannot send unauthenticated email to other providers. I have tried one of
> >my other larger providers, Provider B, and I was unable to do this
> >successfully. Provider A claims this behavior is by design, as some
> devices
> >have simple or no authentication capabilities. Provider B has similar
> >allowances but all of their methods require a form of authentication.
>
> It was common practice to allow your (from the ISP PoV) clients to submit
> mail via SMTP, through port 25 on your mailserver.  Some ISPs still do
> this.
> The client authentication here is done via client IP address, no further
> checks.
>
> Next, enciphered and authenticated mail submission became common, where
> client can connect from the internet and submit mail, auithentication done
> via user/password (later using different ways).
>
> The alternative ports 465 and 587 are used here.  The authentication
> should
> be mandatory on these ports, as well as encryption (on port 465
> implicitly,
> before SMTP comes in, on port 587 using STARTTLS SMTP extension).
>
> Some providers started to require SMTP authentication for any mail
> submission long ago.
>
> Also, 

[pfx] Re: Open relay clarification

[Matus UHLAR - fantomas via Postfix-users]

On 17.04.23 13:38, Tyler Montney via Postfix-users wrote:

Before getting started, this has been publicly disclosed by someone else a
while ago. However, I still don't think it's necessary to name the
organization to explain myself. My goal here is not only to give a proper
argument to the provider, but also my own curiosity and research (on the
workings of SMTP).

I use a mail provider (Provider A) which has thousands of organizations.
This provider allows unauthenticated SMTP to other organizations so long as
they're using them as a provider (within their ecosystem). Of course, you
cannot send unauthenticated email to other providers. I have tried one of
my other larger providers, Provider B, and I was unable to do this
successfully. Provider A claims this behavior is by design, as some devices
have simple or no authentication capabilities. Provider B has similar
allowances but all of their methods require a form of authentication.


It was common practice to allow your (from the ISP PoV) clients to submit 
mail via SMTP, through port 25 on your mailserver.  Some ISPs still do this.  
The client authentication here is done via client IP address, no further 
checks.


Next, enciphered and authenticated mail submission became common, where 
client can connect from the internet and submit mail, auithentication done 
via user/password (later using different ways).


The alternative ports 465 and 587 are used here.  The authentication should 
be mandatory on these ports, as well as encryption (on port 465 implicitly, 
before SMTP comes in, on port 587 using STARTTLS SMTP extension).


Some providers started to require SMTP authentication for any mail 
submission long ago.


Also, because port 25 is used for server-server communication, some 
providers started blocking their clients from connecting to port 25 of 
remote (or even local) hosts, preventing clients from sending spam this way.



The sender address is completely unrelated to this, providers may or may not 
verify, if the client is authorized to send mail from provided address, e.g.  
compare login name to list of allowed sending addresses.


Further, envelope (mail from:) and header From: senders may be two different 
addresses (this question pops up here once in a while).




Mechanisms such as SPF or spam filtering certainly are effective here, but
unauthenticated SMTP seems like a core failing. "Open relay" is the first
thing that comes to mind; however, is it really an open relay?


From traditional point of view an open relay is mail server that allows you 
to relay non-local mail without authentication - you connect, send mail, 
server will accept it and pass it to he recipient.


The "local" in this case means any domain that is configured on server
("I handle this domain, so I accept mail for it").  Mail for such domain may 
be delivered to local users (mail destination), or relay servers (mail 
gateway, backup MX servers) etc.


SPF/DKIM/DMARC mechanism were designed for recipient of the mail, not for 
sending/relaying server.


sending server of course may verify sender address and refuse mail if the 
sender is not local/known/configured, whether it's on domain or address 
level (see above).



As
mentioned, I cannot send from Provider A to Provider B. The scope is
limited to just this ecosystem. But is there an expectation on how limited
that really is? Say for instance only Provider A and Provider B existed in
all the world, and Provider B was 1% of all servers. Surely that would not
be acceptable to most.


As others mentioned, this is very broad question.

If you have mail server, nobody should stop you from sending mail to anyone 
by connecting to recipients' SMTP servers, but nobody is required to accept 
mail from you.


If you rely on your provider to submit mail, it's up to them to set their 
requirements.



It is my belief that unauthenticated SMTP best practice should only
function when sending within the same domain (f...@domain.com -->
b...@domain.com).


Unless you are owner of domain.com, please use example.com, example.net or 
example.org instead.


The best practice should be requiring your to authenticate to send mail at all 
(port 465/587, block port 25) when you are considered to be end-user, 
or not to limit you at all AND allow you to connect port 25 to any server on 
internet to send mail to them, leaving the decision on the recipient, when 
you are mail server (being able to receive mail via SMTP may not to be a 
requirement here).



Unless they're in an approved senders list, it does not
matter whether the same server, company, ecosystem, and so forth. (Perhaps
there is some unforeseen dependency in being a multi-organization mail
provider, where this is required.) I have reviewed RFC 2821 but have not
found anything concrete, just that it MAY accept or reject as it sees fit
[3.7].


RFC 5321 (and previous) did not care if you will accept mail, they only 
cared how mail it supposed be send/delivered.


the 

[pfx] Re: Open relay clarification

[Jaroslaw Rafa via Postfix-users]

Dnia 18.04.2023 o godz. 12:11:06 Tyler Montney via Postfix-users pisze:
> > - mail for all local domains coming in on port 25 should be accepted (of
> > course considering all usual restrictions - the recipient exists, the
> > sending IP is not on a blacklist etc.)
> >
> > - mail for all non-local domains coming in on port 25 should be outright
> > rejected with "Relay access denied" (or similar) message.
> >
> > There is no authenticated submission on port 25.
> 
> I do not see anything in the RFC explicitly prohibiting authenticated
> submission.

I agree that it is not prohibited, but because there are separate ports
defined for authenticated submission, the current best practice (used by
most mail server administrators, and also being actively recommended here on
this list) is to not enable authentication on port 25 (btw. this also largely
reduces the scale of password-guessing attacks). Port 25 is considered to be
strictly for incoming mail (to "local" domains), and ports 465/587 are for
outgoing mail (usually to "non-local" domains, although one may as well send
to another local domain on the same server).
-- 
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."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

> By "local", I mean here the domains for which that particular server is
the
> final destination, ie. the mail delivered locally and the server "knows"
> what to do with it.

I can't find anything more on what *local* is per the RFC, just that it
must be defined.
Based on that, I guess any argument to what should be local is outside the
scope.

> Note that the term "delivered locally" is quite broad and may include
> *forwarding* the mail to other servers, eg. by aliases defined locally on
> the server. But still, the mail *is* delivered locally, it just happens to
> be delivered to an alias that forwards it elsewhere.
>
> In terms of Postfix, I interpret the term "local" in the meaning I used
> above as everything that is not in the default domain class (see
> http://www.postfix.org/ADDRESS_CLASS_README.html ), ie. all domains for
> which the server is configured to "handle" mail somehow. We can discuss if
> this description includes relay domain class, but it definitely (at least
> for me) includes local domain class, virtual alias domain class and
virtual
> mailbox domain class.
>
> In the meaning above, yes. They are all hosted on that server, so they are
> local. The "operational" difference between local and non-local is simple
> for me:

"Operational" is an acceptable way of distinguishing this.

If the RFC made any reference to "open relay", I could suggest it be revised
to include definitions for local. "Traditionally local" would be the
default but an
optimized "operationally local" would be the preferred. It could very well
be within
scope if it was treated as "rules of the road", as is the point of this
RFC. Sender and admins
expect consistent and safe results when it comes to delivery. Section 7.1
exists but
seems mostly to advise against misguided attempts to prevent spoofing.

> - mail for all local domains coming in on port 25 should be accepted (of
> course considering all usual restrictions - the recipient exists, the
> sending IP is not on a blacklist etc.)
>
> - mail for all non-local domains coming in on port 25 should be outright
> rejected with "Relay access denied" (or similar) message.
>
> There is no authenticated submission on port 25.

I do not see anything in the RFC explicitly prohibiting authenticated
submission.
(I will admit I have been somewhat using "authentication" and
"authorization" interchangeably.)
7.1 does say that the inherent nature of SMTP cannot be authenticated
(again,
going back to that "misguided attempt to secure SMTP [leading to more
problems]").
Perhaps because you could easily forge a submission as a relay?

On Tue, Apr 18, 2023 at 6:23 AM Jaroslaw Rafa via Postfix-users <
postfix-users@postfix.org> wrote:

> Dnia 17.04.2023 o godz. 19:59:48 Tyler Montney via Postfix-users pisze:
> > And that's a definition I've been struggling with: What is *local* in
> > relation to SMTP?
>
> By "local", I mean here the domains for which that particular server is the
> final destination, ie. the mail delivered locally and the server "knows"
> what to do with it.
>
> Note that the term "delivered locally" is quite broad and may include
> *forwarding* the mail to other servers, eg. by aliases defined locally on
> the server. But still, the mail *is* delivered locally, it just happens to
> be delivered to an alias that forwards it elsewhere.
>
> In terms of Postfix, I interpret the term "local" in the meaning I used
> above as everything that is not in the default domain class (see
> http://www.postfix.org/ADDRESS_CLASS_README.html ), ie. all domains for
> which the server is configured to "handle" mail somehow. We can discuss if
> this description includes relay domain class, but it definitely (at least
> for me) includes local domain class, virtual alias domain class and virtual
> mailbox domain class.
>
> > What if I'm a managed service provider hosting email on Postfix? Are all
> my
> > customers considered local?
>
> In the meaning above, yes. They are all hosted on that server, so they are
> local. The "operational" difference between local and non-local is simple
> for me:
>
> - mail for all local domains coming in on port 25 should be accepted (of
> course considering all usual restrictions - the recipient exists, the
> sending IP is not on a blacklist etc.)
>
> - mail for all non-local domains coming in on port 25 should be outright
> rejected with "Relay access denied" (or similar) message.
>
> There is no authenticated submission on port 25.
> --
> 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."
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to 

[pfx] Re: Open relay clarification

[Jaroslaw Rafa via Postfix-users]

Dnia 17.04.2023 o godz. 19:59:48 Tyler Montney via Postfix-users pisze:
> And that's a definition I've been struggling with: What is *local* in
> relation to SMTP?

By "local", I mean here the domains for which that particular server is the
final destination, ie. the mail delivered locally and the server "knows"
what to do with it.

Note that the term "delivered locally" is quite broad and may include
*forwarding* the mail to other servers, eg. by aliases defined locally on
the server. But still, the mail *is* delivered locally, it just happens to
be delivered to an alias that forwards it elsewhere.

In terms of Postfix, I interpret the term "local" in the meaning I used
above as everything that is not in the default domain class (see
http://www.postfix.org/ADDRESS_CLASS_README.html ), ie. all domains for
which the server is configured to "handle" mail somehow. We can discuss if
this description includes relay domain class, but it definitely (at least
for me) includes local domain class, virtual alias domain class and virtual
mailbox domain class.

> What if I'm a managed service provider hosting email on Postfix? Are all my
> customers considered local?

In the meaning above, yes. They are all hosted on that server, so they are
local. The "operational" difference between local and non-local is simple
for me:

- mail for all local domains coming in on port 25 should be accepted (of
course considering all usual restrictions - the recipient exists, the
sending IP is not on a blacklist etc.)

- mail for all non-local domains coming in on port 25 should be outright
rejected with "Relay access denied" (or similar) message.

There is no authenticated submission on port 25.
-- 
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."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

>   One important information is missing here: on what port?

Good catch. Port 25.

>   There should be no authentication on port 25 and all mail destined for
local
>   domains should be accepted.
>
>   There should be mandatory authentication on ports 465/587.
>
>   As both acme.com and corley.com are local to provider A, on port 25 any
mail
>   to any of these domains should be accepted, regardless of sender,
without
>   authentication.

And that's a definition I've been struggling with: What is *local* in
relation to SMTP?

What if I'm a managed service provider hosting email on Postfix? Are all my
customers considered local?
Wouldn't *local* be considered the domains under an organization's control?

>   However, on ports 465 or 587, authentication should be required,
regardless
>   of destination.
>
> If authentication is required on port 25, or no authentication is allowed
on
>   port 465 or 587, someone has misconfigured something.

On Mon, Apr 17, 2023 at 4:58 PM Jaroslaw Rafa via Postfix-users <
postfix-users@postfix.org> wrote:

> Dnia 17.04.2023 o godz. 14:49:11 Noel Jones via Postfix-users pisze:
> > Please keep replies on list.
> >
> > On 4/17/2023 2:16 PM, Tyler Montney wrote:
> > >I'll put it this way, since I'm struggling to word this:
> > >
> > >Provider A contains the following customers:
> > >Acme Corporation (acme.com )
> > >Corley Motors (corley.com )
> > >
> > >Provider B contains the following customers:
> > >ConSec (consec.com )
> > >Teldar Paper (teldar.com )
> > >
> > >f...@acme.com can send to b...@corley.com without authentication.
>
> One important information is missing here: on what port?
>
> There should be no authentication on port 25 and all mail destined for
> local
> domains should be accepted.
>
> There should be mandatory authentication on ports 465/587.
>
> As both acme.com and corley.com are local to provider A, on port 25 any
> mail
> to any of these domains should be accepted, regardless of sender, without
> authentication.
>
> However, on ports 465 or 587, authentication should be required, regardless
> of destination.
>
> If authentication is required on port 25, or no authentication is allowed
> on
> port 465 or 587, someone has misconfigured something.
> --
> 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."
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Jaroslaw Rafa via Postfix-users]

Dnia 17.04.2023 o godz. 14:49:11 Noel Jones via Postfix-users pisze:
> Please keep replies on list.
> 
> On 4/17/2023 2:16 PM, Tyler Montney wrote:
> >I'll put it this way, since I'm struggling to word this:
> >
> >Provider A contains the following customers:
> >Acme Corporation (acme.com )
> >Corley Motors (corley.com )
> >
> >Provider B contains the following customers:
> >ConSec (consec.com )
> >Teldar Paper (teldar.com )
> >
> >f...@acme.com can send to b...@corley.com without authentication.

One important information is missing here: on what port?

There should be no authentication on port 25 and all mail destined for local
domains should be accepted.

There should be mandatory authentication on ports 465/587.

As both acme.com and corley.com are local to provider A, on port 25 any mail
to any of these domains should be accepted, regardless of sender, without
authentication.

However, on ports 465 or 587, authentication should be required, regardless
of destination.

If authentication is required on port 25, or no authentication is allowed on
port 465 or 587, someone has misconfigured something.
-- 
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."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

On 4/17/2023 3:59 PM, Tyler Montney via Postfix-users wrote:


That is the purpose of this discussion, to determine what exactly 
this scenario presents. As stated above, Provider A is aware and 
believes it's acceptable. It is acceptable because their 
documentation has features which rely on it. No justification why 
these features require it was given, so their reasoning for initial 
acceptance is poor. To put it another way, it's like RFC-Ignorant. 
You don't HAVE to list a postmaster address, but it's such a small 
gesture to play nice with the rest of the world. Why rely entirely 
on your spam filter (or unknown mitigations) when a common feature 
such as authentication will do the job? Why the risk?


This is a local spam problem.

Report abuse to your provider. If the provider is unwilling or 
unable to fix the abuse, find another provider.



  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

> Please keep replies on list.
>You've explained what's observable, but not why it's a problem.
> Any random server on the internet can send to b...@corley.com without
> authentication. The original sender may or may not authenticate to
> *their* mail server, corley.com cannot control that. So corley.com
> accepts unauthenticated mail all day long.
> How is this different?

"This provider allows unauthenticated SMTP [Provider A] ... I have tried
one of my other larger providers, Provider B, and I was unable to do this
successfully."

In context, I am able to send as anyone to anyone without restriction.
Spoofing is bad. On top of this, a similar provider preventing this implies
a problem.

But if you're attempting to deliver a message to b...@corley.com, why use
"any random server on the internet" when you can tell one of corley's
servers to do it? (This assumes Acme is a supplier of Corley and you're
trying to trick Corley into paying an invoice.) As far as I can tell, there
is no difference between a legitimate message coming from Acme or a
malicious actor spoofing Acme.

> Some providers require all to authenticate, without exception. This
> is generally considered good, but providers may use other methods to
> prevent abuse of their system.

Most messages done in this manner go to spam, so this method could be
considered an alternative. However, that is part of this discussion. Is
something like this acceptable? Why allow a substitution like this at all?
(What are the benefits of making it optional? Doesn't this go against the
nature of standardization?) How does one know when substitution is
acceptable? (In other words, can we be accused of "cherry picking"?)

> I still don't see a problem. If someone has found a way to abuse
> this, then the abuse should be reported to the provider.

That is the purpose of this discussion, to determine what exactly this
scenario presents. As stated above, Provider A is aware and believes it's
acceptable. It is acceptable because their documentation has features which
rely on it. No justification why these features require it was given, so
their reasoning for initial acceptance is poor. To put it another way, it's
like RFC-Ignorant. You don't HAVE to list a postmaster address, but it's
such a small gesture to play nice with the rest of the world. Why rely
entirely on your spam filter (or unknown mitigations) when a common feature
such as authentication will do the job? Why the risk?

On Mon, Apr 17, 2023 at 2:49 PM Noel Jones via Postfix-users <
postfix-users@postfix.org> wrote:

> Please keep replies on list.
>
> On 4/17/2023 2:16 PM, Tyler Montney wrote:
> > I'll put it this way, since I'm struggling to word this:
> >
> > Provider A contains the following customers:
> > Acme Corporation (acme.com )
> > Corley Motors (corley.com )
> >
> > Provider B contains the following customers:
> > ConSec (consec.com )
> > Teldar Paper (teldar.com )
> >
> > f...@acme.com can send to b...@corley.com
> > without authentication.
>
> You've explained what's observable, but not why it's a problem.
> Any random server on the internet can send to b...@corley.com without
> authentication. The original sender may or may not authenticate to
> *their* mail server, corley.com cannot control that. So corley.com
> accepts unauthenticated mail all day long.
> How is this different?
>
> > f...@acme.com
> > must authenticate in order to send to
> > f...@consec.com . Similarly, f...@consec.com
> > must authenticate in order to send to
> > b...@teldar.com .
> >
>
> Some providers require all to authenticate, without exception. This
> is generally considered good, but providers may use other methods to
> prevent abuse of their system.
>
> I still don't see a problem. If someone has found a way to abuse
> this, then the abuse should be reported to the provider.
>
>
>-- Noel Jones
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

Please keep replies on list.

On 4/17/2023 2:16 PM, Tyler Montney wrote:

I'll put it this way, since I'm struggling to word this:

Provider A contains the following customers:
Acme Corporation (acme.com )
Corley Motors (corley.com )

Provider B contains the following customers:
ConSec (consec.com )
Teldar Paper (teldar.com )

f...@acme.com can send to b...@corley.com 
without authentication. 


You've explained what's observable, but not why it's a problem.
Any random server on the internet can send to b...@corley.com without 
authentication. The original sender may or may not authenticate to 
*their* mail server, corley.com cannot control that. So corley.com 
accepts unauthenticated mail all day long.

How is this different?

f...@acme.com 
must authenticate in order to send to 
f...@consec.com . Similarly, f...@consec.com 
must authenticate in order to send to 
b...@teldar.com .




Some providers require all to authenticate, without exception. This 
is generally considered good, but providers may use other methods to 
prevent abuse of their system.


I still don't see a problem. If someone has found a way to abuse 
this, then the abuse should be reported to the provider.



  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

On 4/17/2023 1:38 PM, Tyler Montney via Postfix-users wrote:


I use a mail provider (Provider A) which has thousands of 
organizations. This provider allows unauthenticated SMTP to other 
organizations so long as they're using them as a provider (within 
their ecosystem). Of course, you cannot send unauthenticated email 
to other providers. I have tried one of my other larger providers, 
Provider B, and I was unable to do this successfully. Provider A 
claims this behavior is by design, as some devices have simple or no 
authentication capabilities. Provider B has similar allowances but 
all of their methods require a form of authentication.


I'm probably missing something... If they're willing to accept 
(unauthenticated) general internet mail from any well-behaved server 
to their customer, what does it matter if it's from another customer?


Sure, most providers require authentication to send any mail, but I 
don't see where this is a problem.


  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: Open Relay on local lan

[John Peach]

On 07/25/2018 01:36 PM, @lbutlr wrote:


On 24 Jul 2018, at 11:31, Software Information  
wrote:

Recently though, auditors made a deal that the server is an open relay.


Based on the rest of this thread, it sounds very much like the auditors are 
incompetent. I mean, not knowing what an open relay is is concerning.


I still remember trying to explain to auditors why I did not have AV on 
a Solaris server and, having won that battle, having to prove it really 
was Solaris.











--
John
PGP Public Key: 412934AC

Re: Open Relay on local lan

[@lbutlr]

On 24 Jul 2018, at 11:31, Software Information  
wrote:
> Recently though, auditors made a deal that the server is an open relay.

Based on the rest of this thread, it sounds very much like the auditors are 
incompetent. I mean, not knowing what an open relay is is concerning.

Re: Open Relay on local lan

[Software Information]

Wow. you learn as you go. Thanks very much for the insight. I will
experiment to see what works best for us.

On Wed, Jul 25, 2018 at 10:44 AM, Viktor Dukhovni <
postfix-us...@dukhovni.org> wrote:

>
>
> > On Jul 25, 2018, at 11:24 AM, Software Information <
> softwareinfor...@gmail.com> wrote:
> >
> > Hi. Thanks for replying. Let's say my internal domain is test.com. I
> can telnet to the server and send an email as u...@example.com out to
> anyone on the internet. They have a problem with that. So I thought maybe I
> could fix this by configuring the server to only accept outgoing mail from
> us...@test.com. Not sure if that is best of there is a better way.
>
> That's not what an "open relay" is.  What you have is, arguably, a lack
> of "egress filtering", where you're not checking that messages leaving
> your network claim to originate from your network.
>
> Whether such "egress filtering" is the right thing to do depends on what
> use-cases you support for email.
>
>1.  Do you have any externally reachable email lists that expand
>to a recipient list that includes external addresses?  Say a
>list for a board of directors, that includes outside directors?
>
>2.  Do any of your users automatically and legitimately forward some
>of their incoming mail to an external mailbox?
>
>3.  Do any of your users "resend" messages, retaining the original
>message structure, adding only Resent-{From,Date,Message-Id}
>headers?
>
> In cases 1 and 2, you'd expect to see some legitimate outbound email
> that has an external "From:" address and an external envelope sender
> address.  In case 3, you'd expect to see some legitimate outbound
> email that has an external "From:" (header) address.
>
> It is not too difficult to configure Postfix to restrict outbound
> email to internal envelope sender addresses, which will work,
> provided you don't have cases 1, 2 or similar.
>
> It is considerably more difficult to restrict external email
> delivery based on the message "From:" header.  What should
> happen with a multi-recipient message with some internal
> and some external recipients when it is discovered that
> the "From:" header is not internal?  You'd need a complex
> content filter or milter to implement policies in this
> space.
>
> The auditors were following a checklist, their job is done
> once they've raised every potential issue.  Now you need to
> decide which issues require changes, and which issues are
> acceptable features of your environment.
>
> If you do decide to filter outbound email by envelope sender,
> you can add:
>
>main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtpd_sender_restrictions =
> check_sender_access ${indexed}relay-senders,
> reject_unauth_destination
>
>relay-senders:
> example.com permit_mynetworks, permit_sasl_authenticated
> example.net permit_mynetworks, permit_sasl_authenticated
>
> --
> --
> Viktor.
>
>

Re: Open Relay on local lan

[Viktor Dukhovni]

> On Jul 25, 2018, at 11:24 AM, Software Information 
>  wrote:
> 
> Hi. Thanks for replying. Let's say my internal domain is test.com. I can 
> telnet to the server and send an email as u...@example.com out to anyone on 
> the internet. They have a problem with that. So I thought maybe I could fix 
> this by configuring the server to only accept outgoing mail from 
> us...@test.com. Not sure if that is best of there is a better way.

That's not what an "open relay" is.  What you have is, arguably, a lack
of "egress filtering", where you're not checking that messages leaving
your network claim to originate from your network.

Whether such "egress filtering" is the right thing to do depends on what
use-cases you support for email.

   1.  Do you have any externally reachable email lists that expand
   to a recipient list that includes external addresses?  Say a
   list for a board of directors, that includes outside directors?

   2.  Do any of your users automatically and legitimately forward some
   of their incoming mail to an external mailbox?

   3.  Do any of your users "resend" messages, retaining the original
   message structure, adding only Resent-{From,Date,Message-Id}
   headers?

In cases 1 and 2, you'd expect to see some legitimate outbound email
that has an external "From:" address and an external envelope sender
address.  In case 3, you'd expect to see some legitimate outbound
email that has an external "From:" (header) address.

It is not too difficult to configure Postfix to restrict outbound
email to internal envelope sender addresses, which will work,
provided you don't have cases 1, 2 or similar.

It is considerably more difficult to restrict external email
delivery based on the message "From:" header.  What should
happen with a multi-recipient message with some internal
and some external recipients when it is discovered that
the "From:" header is not internal?  You'd need a complex
content filter or milter to implement policies in this
space.

The auditors were following a checklist, their job is done
once they've raised every potential issue.  Now you need to
decide which issues require changes, and which issues are
acceptable features of your environment.

If you do decide to filter outbound email by envelope sender,
you can add:

   main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_sender_restrictions =
check_sender_access ${indexed}relay-senders,
reject_unauth_destination

   relay-senders:
example.com permit_mynetworks, permit_sasl_authenticated
example.net permit_mynetworks, permit_sasl_authenticated

-- 
-- 
Viktor.

Re: Open Relay on local lan

[Software Information]

Hi. Thanks for replying. Let's say my internal domain is test.com. I can
telnet to the server and send an email as u...@example.com out to anyone on
the internet. They have a problem with that. So I thought maybe I could fix
this by configuring the server to only accept outgoing mail from
us...@test.com. Not sure if that is best of there is a better way.

On Wed, Jul 25, 2018 at 8:42 AM, Viktor Dukhovni  wrote:

>
>
> > On Jul 24, 2018, at 1:31 PM, Software Information <
> softwareinfor...@gmail.com> wrote:
> >
> > 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.
>
> If there are systems on your network that need to use the machine as a
> smarthost for outbound mail, and it is not practical to enable SASL or
> TLS client certificate authentication, then allowing all systems on your
> internal network to send email is not considered unreasonable.  You can
> don't generally have to make changes in response to every finding by your
> auditors, documenting the reason why you accept the status-quo is likely
> sufficient.
>
> > What's the best way to change this behavior?
>
> If the various and sundry systems on your LAN don't need to send email
> to the public Internet, you could by default restrict them to send email
> only to your own domains, and make specific exceptions for authenticated
> clients and/or particular hosts.
>
> > For example, is there a way to configure postfix to accept mail from say
> > two domains, test.net and test.com but no other?
>
> Limiting sender domains does not close an open relay.  Open relaying
> is about being to send to *any* recipient, rather than being able to
> send as any sender.
>
> What do your auditors mean when *they* say "open relay"?  If they
> mean the ability to send from remote domains, you could perhaps
> limit outbound mail to just envelope senders in your own domains,
> but keep in mind that this will not prevent external addresses
> in the message "From:" or "Resent-From:" headers.
>
> --
> Viktor.
>
>

Re: Open Relay on local lan

[Viktor Dukhovni]

> On Jul 24, 2018, at 1:31 PM, Software Information 
>  wrote:
> 
> 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.

If there are systems on your network that need to use the machine as a
smarthost for outbound mail, and it is not practical to enable SASL or
TLS client certificate authentication, then allowing all systems on your
internal network to send email is not considered unreasonable.  You can
don't generally have to make changes in response to every finding by your
auditors, documenting the reason why you accept the status-quo is likely
sufficient.

> What's the best way to change this behavior?

If the various and sundry systems on your LAN don't need to send email
to the public Internet, you could by default restrict them to send email
only to your own domains, and make specific exceptions for authenticated
clients and/or particular hosts.

> For example, is there a way to configure postfix to accept mail from say
> two domains, test.net and test.com but no other?

Limiting sender domains does not close an open relay.  Open relaying
is about being to send to *any* recipient, rather than being able to
send as any sender.

What do your auditors mean when *they* say "open relay"?  If they
mean the ability to send from remote domains, you could perhaps
limit outbound mail to just envelope senders in your own domains,
but keep in mind that this will not prevent external addresses
in the message "From:" or "Resent-From:" headers.

-- 
Viktor.

RE: Open Relay on local lan

[Fazzina, Angelo]

Hi, I run 2.10.1

I think this should help
http://www.postfix.org/VIRTUAL_README.html

maybe
virtual_alias_domains =  test.net test.com


not sure what you would need to configure for
mynetworks =
http://www.postfix.org/postconf.5.html#mynetworks


-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

ang...@uconn.edu
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

From: owner-postfix-us...@postfix.org  On 
Behalf Of Software Information
Sent: Tuesday, July 24, 2018 1:31 PM
To: postfix-users@postfix.org
Subject: Open Relay on local lan

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

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

[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

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

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

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

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

[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

[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

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

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

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

[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 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 njo...@megan.vbhcs.org
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 njo...@megan.vbhcs.org
*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 njo...@megan.vbhcs.org
 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

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

Re: Open Relay (???)

[Ralf Hildebrandt]

* Márcio Luciano Donada mdon...@auroraalimentos.com.br:

 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 (???)

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

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=d82e40699ae1412316736573384c8811.squir...@webmail.cnysupport.com


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:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users

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

[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=bobbycle...@yahoo.com, 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=che...@hangsengbank.org, size=1203, nrcpt=1 (queue active)
 Feb 14 04:08:41 mail postfix/smtp[19212]: 2F97218A856:
 to=bobbycle...@yahoo.com, 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=che...@hangsengbank.org, size=1203, nrcpt=1 (queue active)
 Feb 14 04:46:06 mail postfix/qmgr[4249]: 2F97218A856:
 to=bobbycle...@yahoo.com, 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=che...@hangsengbank.org, size=1203, nrcpt=1 (queue active)
 Feb 14 05:42:07 mail postfix/qmgr[4249]: 2F97218A856:
 to=bobbycle...@yahoo.com, 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=che...@hangsengbank.org, size=1203, nrcpt=1 (queue active)
 Feb 14 07:10:43 mail postfix/qmgr[4249]: 2F97218A856:
 to=bobbycle...@yahoo.com, 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=che...@hangsengbank.org, 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
 

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]