> Consider reading Postfix documentation.
> The error message is described there.

I haven't found it. Could you paste it?

> While the Postfix documentation Dr. Venema referred to has the necessary
> clues, you can find Debian-specific ones in the full Debian bug record
> and those clues may be more immediately useful if you don't want to
> build Postfix from the pristine source:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638045

Will it solve the problem if I switch to Dovecot SASL?

Am 05.12.2012 22:02, schrieb jugree@...:
>> Consider reading Postfix documentation.
>> The error message is described there.
>
> I haven't found it. Could you paste it?
>
>> While the Postfix documentation Dr. Venema referred to has the necessary
>> clues, you can find Debian-specific ones in the full Debian bug record
>> and those clues may be more immediately useful if you don't want to
>> build Postfix from the pristine source:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638045
>
> Will it solve the problem if I switch to Dovecot SASL?

if you are already using dovecot - yes!

this way you have one single instance for login on smtpd
and imap/pop3 which also would reflect settings like below
which saved my life due migration to linux from OSX EIMS
because there where tons of user with % instead @ in their
configuration and to be 100% sure i also forced usernames
to lowercase independent of the input

auth_username_translation =
%@AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz

On Dec 5, 2012, at 2:02 PM, jugree@... wrote:

> Will it solve the problem if I switch to Dovecot SASL?

I've been using the Dovecot SASL option for several years on Debian Lenny and
Squeeze, largely because figuring out Cyrus looked like too much work, and it
was simple and quick to set up. It's worked flawlessly.

Thanks, Weitse, for the option.

--
Glenn English

Dan Lists:
> On Wed, Dec 5, 2012 at 11:55 AM, Wietse Venema <wietse@...> wrote:
> >
> > I will not base Postfix development on UNDOCUMENTED return values.
> > That is unmaintainable.
>
> I've brought it up on the FreeBSD lists.  I suggested that it is a bug
> for getpwnam_r to act the way it is.  I'll probably end up submitting
> a bug report.  I think getpwnam_r should act differently.  If not, it
> should be documented.
>
> > I can offer to provide a config option with an errno whitelist for
> > getpwxx_r errno values, so that you can deal with the mess.
>
> That would certainly work.  Thanks.

OK. This is something that I have wanted for a long time with mailbox
write errors. Right now the behavior is hard-coded.

	 Wietse

jugree@...:
> > Consider reading Postfix documentation.
> > The error message is described there.
>
> I haven't found it. Could you paste it?

Well there is at least one section that covers "not found" or
"missing" authentication mechanisms.

The problem is a mis-match between smtpd_sasl_security_options
(e.g., noplaintext) and the available server mechanisms (e.g.,
plaintext only).

	 Wietse

> The problem is a mis-match between smtpd_sasl_security_options
> (e.g., noplaintext) and the available server mechanisms (e.g.,
> plaintext only).

I've configured UNIX-domain socket communication, enabled SASL
authentication and authorization(0), but I'm still getting `fatal: no
SASL authentication mechanisms'.

Is it connected with my configuration? Is it connected with the
version of Postfix?

dovecot.conf:
mechanisms = plain

main.cf:
smtpd_sasl_security_options = noanonymous, noplaintext

AFAICT, it can't be connected with `noplaintext' because it `allows
plaintext mechanisms, but only over a TLS-encrypted connection'(1).

# postconf -a
cyrus
dovecot

(0) http://www.postfix.org/SASL_README.html#server_dovecot_comm
(1) http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options

On 12/5/2012 7:23 PM, jugree@... wrote:
>> The problem is a mis-match between smtpd_sasl_security_options
>> (e.g., noplaintext) and the available server mechanisms (e.g.,
>> plaintext only).
>
> I've configured UNIX-domain socket communication, enabled SASL
> authentication and authorization(0), but I'm still getting `fatal: no
> SASL authentication mechanisms'.
>
> Is it connected with my configuration? Is it connected with the
> version of Postfix?
>
> dovecot.conf:
> mechanisms = plain

If you're using dovecot now, make sure you set in main.cf
smtpd_sasl_type = dovecot

Make sure "postconf -n" output contains the settings you expect!


>
> main.cf:
> smtpd_sasl_security_options = noanonymous, noplaintext

Well there's the problem.  Postfix says noplaintext but dovecot only
has PLAIN.

>
> AFAICT, it can't be connected with `noplaintext' because it `allows
> plaintext mechanisms, but only over a TLS-encrypted connection'(1).

For the above statement to be true, you need both
  smtpd_sasl_security_options = noanonymous, noplaintext
  smtpd_sasl_tls_security_options = noanonymous

and for the above to /work/ dovecot needs to offer a non-plaintext
mechanism, such as CRAM-MD5.

I would strongly suggest removing the "noplaintext" keyword during
testing.



   -- Noel Jones

Hi Everyone,

On 01/12/12 18:19, Noel Jones wrote:
> On 12/1/2012 11:11 AM, PGR wrote:
>> Hi Everyone,
>>
>> I would like to know how to stop/forbid this server to send us their emails
>>
>> The content of received email is
>>
>> Received: from web-groupsolweb1.aquaray.com (unknown [95.128.42.80])
>>  by mail.domain.tld (Postfix) with ESMTP
>>  for <info@...>; Fri, 30 Nov 2012 00:56:49 +0100 (CET)
>> Received: from PC-de-thib (2.147.3.109.rev.sfr.net [109.3.147.2])
>>  by web-groupsolweb1.aquaray.com (Postfix) with SMTP id E4515974A2C
>>  for <info@...>; Tue, 27 Nov 2012 03:59:06 +0100 (CET)
>>
>> The contain of mail.log
>>
>> Nov 30 00:56:49 serv001 postfix/smtpd[21866]: warning: 95.128.42.80:
>> address not listed for hostname web-groupsolweb1.aquaray.com
>> Nov 30 00:56:49 serv001 postfix/smtpd[21866]: connect from
>> unknown[95.128.42.80]
>
> Add a check_client_access map to reject them.  Something like:
>
> # main.cf
> smtpd_client_restrictions =
>   check_client_access hash:/etc/postfix/client_blacklist
>
> # client_blacklist
> 95.128.42.80  REJECT listed in client blacklist
Both have been done

/etc/postfix$ grep iglobe.be *
client-blacklist:.iglobe.be REJECT 555 Spam not tolerated

/etc/postfix$ grep client-blacklist *
main.cf:smtpd_client_restrictions = permit_mynetworks,
check_client_access hash:/etc/postfix/client-blacklist,
reject_rbl_client dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,reject_unknown_reverse_client_hostname

and I'm still getting unwanted email (from iglobe.be in this example)

Received: from paganini.iglobe.be (diegem.iglobe.be [62.182.56.170])
          by mail.domain.tld (Postfix) with ESMTP
          for <user@...>; Wed, 5 Dec 2012 12:51:37 +0100 (CET)
Received: from pluto.be-housing.be (unknown [192.168.137.94])
          by paganini.iglobe.be (Postfix) with ESMTP id 69C6688B77
          for <user@...>; Wed, 5 Dec 2012 12:51:39 +0100 (CET)
Received: from 84.194.91.122 (localhost [127.0.0.1])
         by pluto.be-housing.be (Postfix) with SMTP id 01744158023
         for <user@...>; Wed, 5 Dec 2012 12:51:36 +0100 (CET)

Any suggestions on what is going on my configuration?

Cheers
--
PGR

> and for the above to /work/ dovecot needs to offer a non-plaintext
> mechanism, such as CRAM-MD5.

> I would strongly suggest removing the "noplaintext" keyword during
> testing.

Can it be used on a regular basis (i.e., not just for testing)? Will it be
better to enable a non-plaintext mechanism? Which one is the best?

(I haven't tried yet.)

Pierre-Gilles RAYNAUD:
> /etc/postfix$ grep iglobe.be *
> client-blacklist:.iglobe.be REJECT 555 Spam not tolerated

Why do you have a '.' before the domain?
Where is this documented?

	 Wietse

On 06/12/2012 13:08, Giuseppe De Nicolo' wrote:
> Hi all,
>
>      I have received a complaint from a customer thats sit on our
> server(postconf  down below ) about not receiving a message from a
> particular sender  domain  " @olmar.191.it "

Your customer in not able to receive emails from olmar.191.it

> grep mx.191.biz /var/log/maillog* and this is the output :
>
> /var/log/maillog.1:Nov 27 12:42:22 darkstar postfix/smtp[2032]:
> D43C1214A4: to=<roberto.pucci@...>,
> relay=mx.191.biz[77.238.27.187]:25, delay=3.1,
> delays=0.01/0.03/0.79/2.3, dsn=2.0.0, status=sent (250 ok:  Message
> 215728826 accepted)

but this log entry is for an outgoing message to zanelli.191.it. There
is no evidence of incoming messages in the log excerpt you produced.

Cheers,
Daniele

On 12/6/2012 4:54 AM, jugree@... wrote:
>> and for the above to /work/ dovecot needs to offer a non-plaintext
>> mechanism, such as CRAM-MD5.
>
>> I would strongly suggest removing the "noplaintext" keyword during
>> testing.
>
> Can it be used on a regular basis (i.e., not just for testing)?

Yes, tell dovecot to offer non-plaintext mechanisms.

Alternately, tell postfix to not offer non-TLS AUTH with main.cf
smtpd_tls_auth_only = yes

> Will it be
> better to enable a non-plaintext mechanism? Which one is the best?

There is no best, there is only what fits your needs.  I expect it's
common to specify
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous

and then after verifying that SASL works, adding
smtpd_tls_auth_only = yes


   -- Noel Jones

On 12/06/2012 01:27 PM, Daniele Nicolodi wrote:
> On 06/12/2012 13:08, Giuseppe De Nicolo' wrote:
>> Hi all,
>>
>>       I have received a complaint from a customer thats sit on our
>> server(postconf  down below ) about not receiving a message from a
>> particular sender  domain  " @olmar.191.it "
> Your customer in not able to receive emails from olmar.191.it
>
>> grep mx.191.biz /var/log/maillog* and this is the output :
>>
>> /var/log/maillog.1:Nov 27 12:42:22 darkstar postfix/smtp[2032]:
>> D43C1214A4: to=<roberto.pucci@...>,
>> relay=mx.191.biz[77.238.27.187]:25, delay=3.1,
>> delays=0.01/0.03/0.79/2.3, dsn=2.0.0, status=sent (250 ok:  Message
>> 215728826 accepted)
> but this log entry is for an outgoing message to zanelli.191.it. There
> is no evidence of incoming messages in the log excerpt you produced.
>
> Cheers,
> Daniele
>
>

Hi Danele,

      As I stated I did grep for the mx record  which happens to be
responsible for all the second level domain 191.it and subsequent third
level doman ( zanetti olmar etc.) , the main point is exatly that into
my server log seems this person "never" tried to send nothing to me BUT
on the orher side he does affirm he did , I m quite positive this is a
problem not related to my server ,what I was asking is a external point
of view of the situation in case I negleted some flaw into my setup.

      Cheers

On 12/5/2012 11:22 PM, Pierre-Gilles RAYNAUD wrote:
> Hi Everyone,
>
> On 01/12/12 18:19, Noel Jones wrote:
>> On 12/1/2012 11:11 AM, PGR wrote:
>>> Hi Everyone,
>>>
>>> I would like to know how to stop/forbid this server to send us their emails
>>>
>>> The content of received email is
>>>
>>> Received: from web-groupsolweb1.aquaray.com (unknown [95.128.42.80])
>>>  by mail.domain.tld (Postfix) with ESMTP
>>>  for <info@...>; Fri, 30 Nov 2012 00:56:49 +0100 (CET)
>>> Received: from PC-de-thib (2.147.3.109.rev.sfr.net [109.3.147.2])
>>>  by web-groupsolweb1.aquaray.com (Postfix) with SMTP id E4515974A2C
>>>  for <info@...>; Tue, 27 Nov 2012 03:59:06 +0100 (CET)
>>>
>>> The contain of mail.log
>>>
>>> Nov 30 00:56:49 serv001 postfix/smtpd[21866]: warning: 95.128.42.80:
>>> address not listed for hostname web-groupsolweb1.aquaray.com
>>> Nov 30 00:56:49 serv001 postfix/smtpd[21866]: connect from
>>> unknown[95.128.42.80]
>>
>> Add a check_client_access map to reject them.  Something like:
>>
>> # main.cf
>> smtpd_client_restrictions =
>>   check_client_access hash:/etc/postfix/client_blacklist
>>
>> # client_blacklist
>> 95.128.42.80  REJECT listed in client blacklist
> Both have been done
>
> /etc/postfix$ grep iglobe.be *
> client-blacklist:.iglobe.be REJECT 555 Spam not tolerated

Wow, that doesn't look anything like the example I supplied.

The domain form with a leading dot ".example.com" will only work if
you adjust the default setting of parent_domain_matches_subdomains.
I think most folks use the default setting and "example.com"; use
whichever you prefer.

Don't make up reject codes; the "555" you specify is not valid.
Just use "REJECT reason" and let postfix decide the proper code.

Use example.com instead of someone's name.



   -- Noel Jones

>
> /etc/postfix$ grep client-blacklist *
> main.cf:smtpd_client_restrictions = permit_mynetworks,
> check_client_access hash:/etc/postfix/client-blacklist,
> reject_rbl_client dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org,reject_unknown_reverse_client_hostname
>
> and I'm still getting unwanted email (from iglobe.be in this example)
>
> Received: from paganini.iglobe.be (diegem.iglobe.be [62.182.56.170])
>          by mail.domain.tld (Postfix) with ESMTP
>          for <user@...>; Wed, 5 Dec 2012 12:51:37 +0100 (CET)
> Received: from pluto.be-housing.be (unknown [192.168.137.94])
>          by paganini.iglobe.be (Postfix) with ESMTP id 69C6688B77
>          for <user@...>; Wed, 5 Dec 2012 12:51:39 +0100 (CET)
> Received: from 84.194.91.122 (localhost [127.0.0.1])
>         by pluto.be-housing.be (Postfix) with SMTP id 01744158023
>         for <user@...>; Wed, 5 Dec 2012 12:51:36 +0100 (CET)
>
> Any suggestions on what is going on my configuration?
>
> Cheers
> --
> PGR
>

On 12/05/2012 03:57 PM, Benny Pedersen wrote:
> Muzaffer Tolga Özses skrev den 04-12-2012 09:10:
>
>> mydestination = localhost
>
> try using it as default, comment it in main.cf
>
> if it still loops then recipient domain is missing in mysql
>
> virtual_mailbox_domains
>
>> virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
>> virtual_mailbox_domains =
>> mysql:/etc/postfix/mysql_virtual_domains_maps.cf
>
> try postmap -q example.org
> mysql:/etc/postfix/mysql_virtual_domains_maps.cf
>
> no output ?, then example.org is missing in sql data, make sure
> mydestination domains exists here, if you want to change it to just
> localhost in main.cf
>
> test with youŕ own domain to make sure it works
>
> mail.bilgisayarciniz.org
>
> are missing ?
>
> drupalizm.com
>
> works in postmap
>
>
Hi again,

I've resolved all but one of these bouncing issues. How do I silently
discard e-mails sent to an unknown user, because they also bounce?

Regards,

Le 06/12/2012 14:58, Muzaffer Tolga Özses a écrit :
>
> On 12/05/2012 03:57 PM, Benny Pedersen wrote:
>> Muzaffer Tolga Özses skrev den 04-12-2012 09:10:
>>
>>> mydestination = localhost
>>
>> try using it as default, comment it in main.cf
>>
>> if it still loops then recipient domain is missing in mysql
>>
>> virtual_mailbox_domains
>>
>>> virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
>>> virtual_mailbox_domains =
>>> mysql:/etc/postfix/mysql_virtual_domains_maps.cf
>>
>> try postmap -q example.org
>> mysql:/etc/postfix/mysql_virtual_domains_maps.cf
>>
>> no output ?, then example.org is missing in sql data, make sure
>> mydestination domains exists here, if you want to change it to just
>> localhost in main.cf
>>
>> test with youŕ own domain to make sure it works
>>
>> mail.bilgisayarciniz.org
>>
>> are missing ?
>>
>> drupalizm.com
>>
>> works in postmap
>>
>>
> Hi again,
>
> I've resolved all but one of these bouncing issues. How do I silently
> discard e-mails sent to an unknown user, because they also bounce?


do not accept mail unless you deliver it.

now, if you have queued mail to remove, you can use
# postsuper -d $queueid

We relay email for our customers.  They had some accounts Phished.  I
wanted to hold email from those users so I could see the spam that was
going out and requeue the valid email.

In main.cf I have:

  smtpd_sender_restrictions =
         check_sender_access hash:$config_directory/sender_domains,
         reject

sender_domains has:

user@...      HOLD
domain.tld               OK

What user@... sends email I get:

Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: hold: RCPT
from clientserv[12.34.56.78]: <user@...>: Sender address
triggers HOLD action; from=<user@...> to=<recip@...>
proto=ESMTP helo=<clientserv>
Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: reject: RCPT
from clientserv[12.34.56.78]: 554 5.7.1 <user@...>: Sender
address rejected: Access denied; from=<user@...>
to=<recip@...> proto=ESMTP helo=<clientserv>

What am I doing wrong?

Thanks,

Dan

On 12/6/2012 4:29 PM, Dan Lists wrote:
> We relay email for our customers.  They had some accounts Phished.  I
> wanted to hold email from those users so I could see the spam that was
> going out and requeue the valid email.
>
> In main.cf I have:
>
>  smtpd_sender_restrictions =
>         check_sender_access hash:$config_directory/sender_domains,
>         reject
>
> sender_domains has:
>
> user@...      HOLD
> domain.tld               OK
>
> What user@... sends email I get:
>
> Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: hold: RCPT
> from clientserv[12.34.56.78]: <user@...>: Sender address
> triggers HOLD action; from=<user@...> to=<recip@...>
> proto=ESMTP helo=<clientserv>
> Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: reject: RCPT
> from clientserv[12.34.56.78]: 554 5.7.1 <user@...>: Sender
> address rejected: Access denied; from=<user@...>
> to=<recip@...> proto=ESMTP helo=<clientserv>
>
> What am I doing wrong?

Just a misconception...  HOLD does not immediately freeze the
message, nor does it instruct postfix to accept the message.
Processing continues and a later restriction can still reject the
message.

Probably the easiest solution here it to create your own HOLD_OK
action so it works as you expect.

# main.cf
smtpd_restriction_classes =
   HOLD_OK

HOLD_OK =
   reject_unauth_destination
   check_client_access static:hold
   permit


Then, in your sender_domain file,
user@...      HOLD_OK
domain.tld               OK


   -- Noel Jones

On Thu, Dec 6, 2012 at 5:09 PM, Noel Jones <njones@...> wrote:
> On 12/6/2012 4:29 PM, Dan Lists wrote:
>> We relay email for our customers.  They had some accounts Phished.  I
>> wanted to hold email from those users so I could see the spam that was
>> going out and requeue the valid email.
>>
>> In main.cf I have:
>>
>>  smtpd_sender_restrictions =
>>         check_sender_access hash:$config_directory/sender_domains,
>>         reject
>>
>> sender_domains has:
>>
>> user@...      HOLD
>> domain.tld               OK
>>
>> What user@... sends email I get:
>>
>> Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: hold: RCPT
>> from clientserv[12.34.56.78]: <user@...>: Sender address
>> triggers HOLD action; from=<user@...> to=<recip@...>
>> proto=ESMTP helo=<clientserv>
>> Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: reject: RCPT
>> from clientserv[12.34.56.78]: 554 5.7.1 <user@...>: Sender
>> address rejected: Access denied; from=<user@...>
>> to=<recip@...> proto=ESMTP helo=<clientserv>
>>
>> What am I doing wrong?
>
> Just a misconception...  HOLD does not immediately freeze the
> message, nor does it instruct postfix to accept the message.
> Processing continues and a later restriction can still reject the
> message.

Interesting.  It worked when I did something similar in
smtpd_client_restrictions.

smtpd_client_restrictions =
     check_client_access hash:$config_directory/client_access

client_access:
     12.34.56.78   HOLD

Is that because the smtpd_client_restrictions does not have reject listed?

> Probably the easiest solution here it to create your own HOLD_OK
> action so it works as you expect.
>
> # main.cf
> smtpd_restriction_classes =
>   HOLD_OK
>
> HOLD_OK =
>   reject_unauth_destination
>   check_client_access static:hold
>   permit

We are relaying for them, so I assume I would want to leave out
reject_unauth_destinaion.

>
> Then, in your sender_domain file,
> user@...      HOLD_OK
> domain.tld               OK
>
>
>   -- Noel Jones

On 12/6/2012 5:26 PM, Dan Lists wrote:
> On Thu, Dec 6, 2012 at 5:09 PM, Noel Jones <njones@...> wrote:
>> On 12/6/2012 4:29 PM, Dan Lists wrote:
>>> We relay email for our customers.  They had some accounts Phished.  I
>>> wanted to hold email from those users so I could see the spam that was
>>> going out and requeue the valid email.
>>>
>>> In main.cf I have:
>>>
>>>  smtpd_sender_restrictions =
>>>         check_sender_access hash:$config_directory/sender_domains,
>>>         reject
>>>
>>> sender_domains has:
>>>
>>> user@...      HOLD
>>> domain.tld               OK
>>>
>>> What user@... sends email I get:
>>>
>>> Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: hold: RCPT
>>> from clientserv[12.34.56.78]: <user@...>: Sender address
>>> triggers HOLD action; from=<user@...> to=<recip@...>
>>> proto=ESMTP helo=<clientserv>
>>> Dec  6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: reject: RCPT
>>> from clientserv[12.34.56.78]: 554 5.7.1 <user@...>: Sender
>>> address rejected: Access denied; from=<user@...>
>>> to=<recip@...> proto=ESMTP helo=<clientserv>
>>>
>>> What am I doing wrong?
>>
>> Just a misconception...  HOLD does not immediately freeze the
>> message, nor does it instruct postfix to accept the message.
>> Processing continues and a later restriction can still reject the
>> message.
>
> Interesting.  It worked when I did something similar in
> smtpd_client_restrictions.
>
> smtpd_client_restrictions =
>     check_client_access hash:$config_directory/client_access
>
> client_access:
>     12.34.56.78   HOLD
>
> Is that because the smtpd_client_restrictions does not have reject listed?

If the message was accepted and placed on hold, then it didn't hit
any reject rules in any of the smtpd_*_restrictions, nor in
header/body checks.


>
>> Probably the easiest solution here it to create your own HOLD_OK
>> action so it works as you expect.
>>
>> # main.cf
>> smtpd_restriction_classes =
>>   HOLD_OK
>>
>> HOLD_OK =
>>   reject_unauth_destination
>>   check_client_access static:hold
>>   permit
>
> We are relaying for them, so I assume I would want to leave out
> reject_unauth_destinaion.

Yes, I was assuming it was internal mail.




   -- Noel Jones



>
>>
>> Then, in your sender_domain file,
>> user@...      HOLD_OK
>> domain.tld               OK
>>
>>
>>   -- Noel Jones

I'm not entirely sure how to formulate this question best in English,
so please bear over with me.

In the past 6 months I've set up several Postfix 2.7.1 servers, which
uses Dovecot as LDA and as SASL auth. One of them runs this domain, but
they are still in testing.

My highest concern is to setup an open relay by accident, so in the
process I've used an online anti-spam tester several times:
http://www.antispam-ufrj.pads.ufrj.br/test-relay.html

It has always (and still does) reported the servers to reject
relaying.

I therefore thought it was only possible to relay mail through the
servers if a valid username (an active email-address) and a password
were given to the server (unless it's a systemuser logged in through
ssh). That is how I would like the servers to behave.

However, trying to learn a little I played around with telnet from my
computer today, and was able to relay mail through the servers from the
internet, without having to log in.

It appears though, that it's only possible to relay mail if the server
holds the address in the database, which suggest that the servers only
are open to some limited backscatter, since the recipient address has
to be known and given to Postfix. Some testing seems to support this.

Even so, I would like Postfix to deny relaying in this case also, if at
all possible.

A telnet session goes like this, on either the server containing
my_address or the backup MX:

$ telnet X.X.X.X 25
Trying X.X.X.X...
Connected to X.X.X.X.
Escape character is '^]'.
220 machinename.domain.tld ESMTP Postfix
EHLO fake-name.domain.tld
250-machinename.domain.tld
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
$ MAIL FROM:spam@...
250 2.1.0 Ok
$ RCPT TO:my_address@my_domain.tld
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Test something
.
250 2.0.0 Ok: queued as 3653E371BAA1
quit
221 2.0.0 Bye
Connection closed by foreign host.

Then grep'ing the query ID from the log gives 5 lines:

Dec  6 23:30:40 machinename postfix/smtpd[3184]: 3653E371BAA1:
client=unknown[my wan-IP]

Dec  6 23:30:51 machinename postfix/cleanup[3557]: 3653E371BAA1:
message-id=<>

Dec  6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1:
from=<SRS0=nFZn=KA=dont-exists.tld=spam@my_domin.tld>, size=379,
nrcpt=1 (queue active)

Dec  6 23:30:51 machinename postfix/pipe[3577]: 3653E371BAA1:
to=<my_address@my_domain.tld>, relay=dovecot, delay=56,
delays=56/0/0/0, dsn=2.0.0, status=sent (delivered via dovecot service)

Dec  6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1: removed


And the mail is indeed delivered. In master.cf the submission-part
looks like this:


submission inet n - - - - smtpd
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_sasl_type=dovecot
   -o smtpd_sasl_path=private/auth
   -o smtpd_sasl_security_options=noanonymous
   -o smtpd_sasl_local_domain=$myhostname
   -o smtpd_client_restrictions=
    permit_sasl_authenticated
    reject
   -o
smtpd_sender_login_maps=proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
    -o smtpd_sender_restrictions=reject_sender_login_mismatch
    -o smtpd_recipient_restrictions=
      reject_non_fqdn_recipient
      reject_unknown_recipient_domain
      permit_sasl_authenticated
      reject


And postconf -n on the server my_address gives:


alias_maps = hash:/etc/aliases

bounce_template_file = /etc/postfix/bounce.cf

broken_sasl_auth_clients = yes

config_directory = /etc/postfix

delay_warning_time = 4

disable_vrfy_command = yes

inet_interfaces = all

maximal_queue_lifetime = 15

myhostname = machinename.my_domain.tld

mynetworks = 127.0.0.0/8

recipient_canonical_classes = envelope_recipient

recipient_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
tcp:127.0.0.1:10002

sender_canonical_classes = envelope_sender

sender_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
tcp:127.0.0.1:10001

smtp_tls_security_level = may

smtp_tls_session_cache_database =
btree:$data_directory/smtp_tls_session_cache

smtpd_data_restrictions =
   reject_unauth_pipelining
   reject_multi_recipient_bounce
   permit

smtpd_helo_required = yes

smtpd_recipient_restrictions = permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    warn_if_reject reject_invalid_helo_hostname
    warn_if_reject reject_non_fqdn_helo_hostname
    warn_if_reject reject_non_fqdn_sender
    warn_if_reject reject_non_fqdn_recipient
    warn_if_reject reject_unknown_sender_domain
    warn_if_reject reject_unknown_recipient_domain
    warn_if_reject reject_rbl_client truncate.gbudb.net
    check_policy_service unix:private/spfcheck
    permit

smtpd_sasl_auth_enable = yes

smtpd_sasl_exceptions_networks = $mynetworks

smtpd_sasl_path = private/auth

smtpd_sasl_security_options = noanonymous

smtpd_sasl_type = dovecot

smtpd_tls_ask_ccert = yes

smtpd_tls_cert_file = /etc/ssl/self-signed/smtpd.crt

smtpd_tls_key_file = /etc/ssl/self-signed/smtpd.key

smtpd_tls_loglevel = 1

smtpd_tls_received_header = yes

smtpd_tls_security_level = may

smtpd_tls_session_cache_database =
btree:$data_directory/smtpd_tls_session_cache

tls_random_source = dev:/dev/urandom

transport_maps = hash:/etc/postfix/transport.cf

virtual_alias_maps =
proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf

virtual_gid_maps = static:5000

virtual_mailbox_base = /home/vmail

virtual_mailbox_domains =
proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf

virtual_mailbox_maps =
proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf

virtual_minimum_uid = 5000

virtual_transport = dovecot

virtual_uid_maps = static:5000

Any pointers / help will be greatly appreciated and thanks for reading.
Cheers, Titanus

Titanus Eramius:
> However, trying to learn a little I played around with telnet from my
> computer today, and was able to relay mail through the servers from the
> internet, without having to log in.

Most Postfix configurations use "permit_mynetworks" which
by default allows relaying from local networks.

	 Wietse

On Fri, Dec 07, 2012 at 01:23:21AM +0100, Titanus Eramius wrote:
> My highest concern is to setup an open relay by accident, so
> in the process I've used an online anti-spam tester several
> times: http://www.antispam-ufrj.pads.ufrj.br/test-relay.html

That need not be your highest concern.

> It has always (and still does) reported the servers to reject
> relaying.
>
> I therefore thought it was only possible to relay mail through the
> servers if a valid username (an active email-address) and a password
> were given to the server (unless it's a systemuser logged in through
> ssh). That is how I would like the servers to behave.

What about when your server is the final destination?

> However, trying to learn a little I played around with telnet from
> my computer today, and was able to relay mail through the servers
> from the internet, without having to log in.
>
> It appears though, that it's only possible to relay mail if the
> server holds the address in the database, which suggest that the
> servers only are open to some limited backscatter, since the
> recipient address has to be known and given to Postfix. Some
> testing seems to support this.
>
> Even so, I would like Postfix to deny relaying in this case also,
> if at all possible.
>
> A telnet session goes like this, on either the server containing
> my_address or the backup MX:
>
> $ telnet X.X.X.X 25
> Trying X.X.X.X...
> Connected to X.X.X.X.
> Escape character is '^]'.
> 220 machinename.domain.tld ESMTP Postfix
> EHLO fake-name.domain.tld
> 250-machinename.domain.tld
> 250-PIPELINING
> 250-SIZE 10240000
> 250-ETRN
> 250-STARTTLS
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> $ MAIL FROM:spam@...

See reject_unknown_sender_domain if you want to reject mail from
senders in nonexisting domains (a good idea.)

> 250 2.1.0 Ok
> $ RCPT TO:my_address@my_domain.tld

Your munging makes it hard to say for sure, but I'm going to go out
on a limb and venture a guess that you host "my_domain.tld" on this
Postfix.

That's not what "relaying" means. That's "accepting for delivery."
"Relaying" means taking mail for some OTHER site and sending it on
for the client.

What exactly are you trying to prevent here?

> 250 2.1.5 Ok
> DATA
> 354 End data with <CR><LF>.<CR><LF>
> Test something
> .
> 250 2.0.0 Ok: queued as 3653E371BAA1
> quit
> 221 2.0.0 Bye
> Connection closed by foreign host.
>
> Then grep'ing the query ID from the log gives 5 lines:
>
> Dec  6 23:30:40 machinename postfix/smtpd[3184]: 3653E371BAA1:
> client=unknown[my wan-IP]
> Dec  6 23:30:51 machinename postfix/cleanup[3557]: 3653E371BAA1:
> message-id=<>
> Dec  6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1:
> from=<SRS0=nFZn=KA=dont-exists.tld=spam@my_domin.tld>, size=379,

That's a different sender than you showed. If you're going to mung,
do be consistent!

> nrcpt=1 (queue active)
> Dec 6 23:30:51 machinename postfix/pipe[3577]: 3653E371BAA1:
> to=<my_address@my_domain.tld>, relay=dovecot, delay=56,
> delays=56/0/0/0, dsn=2.0.0, status=sent (delivered via dovecot
> service)

See, you accepted this for final delivery. You did not relay.

> Dec 6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1:
> removed
>
>
> And the mail is indeed delivered. In master.cf the
> submission-part looks like this:

So? Your telnet was to port 25.
--
   http://rob0.nodns4.us/ -- system administration and consulting
   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

> I would strongly suggest removing the "noplaintext" keyword during
> testing.

Thank you. It worked.

> There is no best, there is only what fits your needs.  I expect it's
> common to specify
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_tls_security_options = noanonymous

> and then after verifying that SASL works, adding
> smtpd_tls_auth_only = yes

Does it mean that my session will be encrypted using TLS, but there
won't be any encryption inside the tunnel?

I assume it's pretty secure for most cases. Could you confirm?

Anyway, I'll try to configure a non-plaintext mechanism.

On 12/6/2012 9:54 PM, jugree@... wrote:
>> common to specify
>> smtpd_sasl_security_options = noanonymous
>> smtpd_sasl_tls_security_options = noanonymous
>
>> and then after verifying that SASL works, adding
>> smtpd_tls_auth_only = yes
>
> Does it mean that my session will be encrypted using TLS, but there
> won't be any encryption inside the tunnel?


Right, postfix won't offer AUTH unless the session is TLS-encrypted,
and all credentials are protected by TLS.

Postfix (and the SASL backend) will still happily use any supported
mechanisms inside TLS, but now there's no particular advantage for
the non-plaintext mechanisms since everything is already encrypted
with TLS.


> I assume it's pretty secure for most cases. Could you confirm?

More secure, because with TLS the mail content is encrypted, not
just the credentials.


>
> Anyway, I'll try to configure a non-plaintext mechanism.
>

Many popular desktop clients only support PLAIN and LOGIN (both
considered plain-text equivalent), but it (most likely) won't hurt
to offer additional mechanisms.



   -- Noel Jones

On 12/6/2012 6:23 PM, Titanus Eramius wrote:
> My highest concern is to setup an open relay by accident, so in the

...

> A telnet session goes like this, on either the server containing
> my_address or the backup MX:
>
> $ telnet X.X.X.X 25
...
> $ MAIL FROM:spam@...
> 250 2.1.0 Ok
> $ RCPT TO:my_address@my_domain.tld

*** Sending TO YOUR OWN DOMAIN is NOT relaying ***

This is /exactly/ the same process any MTA, or mail client, or spam
bot will use to send mail to you.  Nothing special about telnet; you
could have used a command-line SMTP such as mini_sendmail, or spent
a few minutes setting up Thunderbird for testing.  Nothing of
interest here.



   -- Noel Jones

Hi Wietse,

On 06/12/12 12:52, Wietse Venema wrote:
> Pierre-Gilles RAYNAUD:
>> /etc/postfix$ grep iglobe.be *
>> client-blacklist:.iglobe.be REJECT 555 Spam not tolerated
> Why do you have a '.' before the domain?
> Where is this documented?
>
>  Wietse
Found on many posts explaining how to build blacklist or whitelist for
access restrictions (check_xxxx_access= hash:/yyyyy)
I don't think it was on postfix website but due to the number of blogs,
posts using this syntax notation to exclude a domain, I assume, wrongly
it seems, that statistically, it couldn't be wrong :(

Cheers
--
PGR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I have a border SMTP server that has some local mailbox and relays other
recipients to an internal Exchange server

Relay to Exchange is done via transport file with something like this:

exchange.acme.com relay:[10.10.10.10]



Old Exchange has been decommisioned and moved to a new host 10.10.10.11

I have updated transport file to reflact the new IP, but I still have some
mails in queue like this:

3YHHKX0CKSzB96g      14711 Thu Dec  6 14:12:32 xxx@...
(delivery temporarily suspended: connect to 10.10.10.10[10.10.10.10]:25:
Connection timed out)


Is there a way to redirect the queued emails to the new server using "local"
postfix tools instead of something like dual IP on Exchnge server?


Thank you in advance.



Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

If you see a man approaching you with the obvious intention of doing you good,
you should run for your life.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDBlt4ACgkQ3kWu7Tfl6ZT2lACgyMge5duB+ixumsuwR18TjKeC
wWcAnRx9V5PpTaQC0mwUFyV1zLAWY7Ex
=JSgu
-----END PGP SIGNATURE-----