Re: Postscreen Feature Request

[Allen Coates]

On 03/09/17 00:43, Wietse Venema wrote:
> On 02/09/17 22:03, Wietse Venema wrote:
>> Surprise: I already solved that problem: postscreen would hand off
>> the _decrypted_ session to the tarpitting daemon :-)
> 
> Allen Coates:
>> How would you optionally hand off to the tarpit daemon, instead of to
>> postfix?
> 
> That requires new code for a config parameter that specifies the
> pathname of the tarpit service's UNIX-domain socket, and new code
> for making the Postfix library call to send the SMTP session's file
> descriptor to that socket.
> 
>   Wietse
> 
Thanks for that.  My spam defences are pretty well sorted - only eight
since march - and I am itching to take the fight to them.

Thanks for your time.

Allen

Re: Postscreen Feature Request

[Wietse Venema]

On 02/09/17 22:03, Wietse Venema wrote:
> Surprise: I already solved that problem: postscreen would hand off
> the _decrypted_ session to the tarpitting daemon :-)

Allen Coates:
> How would you optionally hand off to the tarpit daemon, instead of to
> postfix?

That requires new code for a config parameter that specifies the
pathname of the tarpit service's UNIX-domain socket, and new code
for making the Postfix library call to send the SMTP session's file
descriptor to that socket.

Wietse

Re: Postscreen Feature Request

[Allen Coates]

On 02/09/17 22:03, Wietse Venema wrote:
> 
> Surprise: I already solved that problem: postscreen would hand off
> the _decrypted_ session to the tarpitting daemon :-)
> 

How would you optionally hand off to the tarpit daemon, instead of to
postfix?

Allen C

Re: will master.cf inherit parameters from main.cf

[Wietse Venema]

xiedeacc:
> will master.cf inherit parameters from main.cf ? like
> smptd_recipient_restrictions, I found I cannot set
> smptd_recipient_restrictions=check_recipient_access
> hash:/etc/postfix/recipient_access, it complaint fatal:
> unexpected command-line argument: hash:/etc.
> 

master.cf works as documented:

man 5 master

http://.postfix.org/master.5.html

Look for the description of the '-o' option.

Wietse

Re: Postscreen Feature Request

[Wietse Venema]

Viktor Dukhovni:
> On Sat, Sep 02, 2017 at 09:01:21AM -0400, Wietse Venema wrote:
> > Allen Coates:
> > > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the
> > > decision to reject the message has already been made;
> > > It seems to me that this is an opportunity to tar-pit the (bad) remote
> > > host, diminishing spam throughput, and eroding the host's useful 
> > > life-span.
> > 
> > postscreen could hand off a connection to some other daemon.
> > 
> > Keeping connections open *inside* postscreen is definitely not an
> > option. That would limit postcreen's scalability. With a tarpit-only
> > daemon, failure in that daemon would not affect other connections.
> 
> This is of course only possible if TLS is not in use.  Since OpensSSL
> TLS state is not serializable for migration across processes, tarpitting
> TLS would cause congestion in tlsproxy.

Surprise: I already solved that problem: postscreen would hand off
the _decrypted_ session to the tarpitting daemon :-)

With postscreen, the tlsproxy daemon maintains the per-session TLS
state. Of course, tarpitting lots of TLS connections would be
expensive, and it may cause some tlsproxy processes to fail. But
that would not affect sessions that are already whitelisted.

Wietse

Re: majordomo postfix 2.10.1 No recipient addresses found in message header

[tslbai]

Hi,

i think, i found the reason for the majordomo-problem.
Problem is the Update from perl4 to perl5.

I find the "$* is no longer supported at"-Message in my debug-file
/var/tmp/majordomo.debug

https://www.claudiokuenzler.com/blog/62/$*_is_no_longer_supported_majordomo#.War3WDdLezc

http://henrysnotes.org/post_view.php?id=82

... but i'm further then ever from a solution.


Which perl are you using for the majordomo of this postfix-list?
Do you run a patched Version? Could you kindly make it availeable?

Thanks,
Florian


On 9/1/2017 7:29 PM, tslbai wrote:
> Thanks for the hint!
> 
> Sorry, but i don't know, how to tell majordomo, to invoke sendmail in
> the correct way.
> 
> I grep'ed the majordomo scripts for "-t" Option. This is used several times:
> 
> # pwd
> /usr/local/majordomo-1.94.5
> # grep sendmail * | grep " \-t"
> archive2.pl:$bounce_mailer = $bounce_mailer || "$sendmail_command
> -f\$sender -t";
> config-test:print "$sendmail_command -f\\\$sender -t\n";
> config-test:print "/usr/lib/sendmail -f\\\$sender -t\n";
> config-test:$bounce_mailer = "$sendmail_command -f\$sender -t"
> digest:$bounce_mailer = "$sendmail_command -f\$sender -t"
> digest:$bounce_mailer = "$sendmail_command -fmajordomo-owner -t"
> majordomo:$bounce_mailer = "$sendmail_command -f\$sender -t"
> majordomo.cf:$bounce_mailer = "$sendmail_command -oi -oee -f\$sender -t";
> majordomo.pl:$mail_prog = "$sendmail_command -f\$sender -t";
> request-answer:$bounce_mailer = "$sendmail_command -f\$sender -t"
> resend:$bounce_mailer = $bounce_mailer || "$sendmail_command -f\$sender -t";
> resend:# check for the dreaded -t option to sendmail, which will cause
> resend: $mailcmd = "/usr/lib/sendmail -f$sender -t";
> sample.cf:$bounce_mailer = "$sendmail_command -oi -oee -f\$sender -t";
> #
> # pwd
> /usr/local/majordomo-1.94.5/Tools
> new-list:$bounce_mailer = "$sendmail_command -f\$sender -t"
> sequencer:  print MAIL ">>> /usr/lib/sendmail -f$sendmail_sender -t\n";
> sequencer:local(@mailer) = split(' ',"/usr/lib/sendmail
> -f$sendmail_sender -t");
> 
> I deleted some of the "-t"-Options, but my problem persists. :-(
> 
> I know, this is not a postfix-issue, but can you please advise me, how
> to treat majordomo?
> 
> Thanks,
> Florian
> --
> 
> On 9/1/2017 2:16 PM, Matus UHLAR - fantomas wrote:
>> On 01.09.17 12:18, tslbai wrote:
>>> i was running the latest Version of Majordomo (1.94.5) successful on
>>> CentOS 6.x with postfix 2.6 (2.6.6-8.el6.x86_64.rpm) for years.
>>>
>>> Since i installed CentOS 7.x with postfix 2.10 (2.10.1-6.el7.x86_64.rpm)
>>> majordomo isn't working any more (sendmail-error).
>>>
>>> "No recipient addresses found in message header"
>>
>> this question has been already asked and answered:
>>
>> http://postfix.1071664.n5.nabble.com/majordomo-postfix-combination-troubles-td79952.html>
>>
>>
>>> (I know that Majordomo ist very old and greatcircle isn't supporting ist
>>> since years and the majordomo-Mailing-list ended 2003.
>>
>> should be no issue since even this list runs on majordomo.
>>

Avoiding duplicate reply-to lines in header

[Just Ian]

I have an email address that sends to five people using a virtual-map line:

tinyl...@example.comm...@example.com, t...@example.com, (etc)

When tinylist receives email, header_checks uses the following test to
add a reply-to line to the header, so that replies go to 'tinylist'
rather than the original sender:

/^To: .*tinylist@example\.com/ PREPEND Reply-To: tinyl...@example.com

For mail from three of us, that works fine.

Two people's mail clients have already added a reply-to line in the
header, so two reply-to lines end up in the header:

(etc)
Delivered-To:  m...@example.com
Reply-To: t...@example.com
Subject: Re: Some stuff
Reply-To: tinyl...@example.com
To: tinyl...@example.com
(etc)

.. which is contrary to the relevant RFCs and, worse :), means that
everyone else's client only looks at the first one when deciding where
to send replies.

How can this be avoided while maintaining the simplicity?

Thanks,

Ian

Ironic interaction of greylistiing, backup MX hosts and DANE

[Viktor Dukhovni]

[ To be sent separately also to the dane-us...@sys4.de list. ]

I sent a "please fix your TLSA records" notice to "postmaster" and
"info" at a domain whose primary MX host certificate fails to match
its TLSA records:

postfix/pickup[62805]: 7672C1DD39: ...
postfix/cleanup[63835]: 7672C1DD39: message-id=<...>
postfix/qmgr[844]: 7672C1DD39: from=<...>, size=8815, nrcpt=2 (queue active)
postfix/smtp[63837]: 7672C1DD39: host mail.example.nl[192.0.2.1]
said: 450 4.2.0 ... Greylisted, ...
postfix/smtp[63837]: 7672C1DD39: to=,
relay=mail.example.nl[192.0.2.1]:25, delay=3.7, 
delays=0.03/0.01/1.5/2.2,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 119F07F861)
postfix/smtp[63837]: 7672C1DD39: to=,
relay=vps.example.nl[192.0.2.2]:25, delay=5.7, delays=0.03/0.01/5/0.61,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2FBDC2064A)

The  "postmaster" account copy was accepted by the primary MX, but
the "info" address was greylisted: *only* by the primary MX.

However, the secondary MX accepts email *without* greylisting!
This has the effect of delivering all mail via the secondary, with
the primary never seeing any retries that cause greylisting to
pass.

What happened next was interesting and ironic.  I got a "delay"
notification from the secondary:

Your message could not be delivered for more than 3 hour(s).
It will be retried until it is 5 day(s) old.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: Server certificate not trusted

The secondary is configured to verify DANE TLSA when relaying mail
to the primary, so the problem report to "info", and indeed pretty
much all mail to the system in question is queueing on the secondary
MX host, waiting for the primary MX TLSA records to be fixed!

Only "postmaster" email gets through to its destination (if the
sending system does not validate TLSA records, which is naturally
the case for my outbound "please fix your TLSA records" notices).

The main lesson here is not implement Greylisting on only a subset
of your MX hosts.  Don't do that!  

1. When greylisting, make sure that all MX hosts with equal
   or worse (higher) MX preference also greylist.

2. It is harmless (though less effective) to greylist only on
   (all) backup MX hosts, and skip greylisting on the primary.
   It is not a good idea to greylist on the primary, and not
   on the backups.

3. Monitor your DANE TLSA records, in such a way that notices
   of problems get through even when the TLSA records are
   stale.

4. Handle certificate rotation correctly.

https://dane.sys4.de/common_mistakes#3

http://tools.ietf.org/html/rfc7671#section-8.1
http://tools.ietf.org/html/rfc7671#section-8.4

https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

With "3 1 1" + "2 1 1" TLSA records, the rollover process
can be substantially simplified:

https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

Happy greylisting and TLSA record publishing to you all...

-- 
Viktor.

Re: Postscreen Feature Request

[Viktor Dukhovni]

On Sat, Sep 02, 2017 at 09:01:21AM -0400, Wietse Venema wrote:
> Allen Coates:
> > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the
> > decision to reject the message has already been made;
> > It seems to me that this is an opportunity to tar-pit the (bad) remote
> > host, diminishing spam throughput, and eroding the host's useful life-span.
> 
> postscreen could hand off a connection to some other daemon.
> 
> Keeping connections open *inside* postscreen is definitely not an
> option. That would limit postcreen's scalability. With a tarpit-only
> daemon, failure in that daemon would not affect other connections.

This is of course only possible if TLS is not in use.  Since OpensSSL
TLS state is not serializable for migration across processes, tarpitting
TLS would cause congestion in tlsproxy.

-- 
Viktor

Re: reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

[Viktor Dukhovni]

On Sat, Sep 02, 2017 at 06:34:35AM -0700, xiedeacc wrote:


Note the below reformatting of the text you sent to show one logical
restrictin per line.  When asking for help it is polite to make it
easier for others to help you.  Try to not send a jumble of text
that others have to tease apart.

I've also numbered the restrictions to make it easier to make the
point below.

> smtpd_recipient_restrictions =
> 1.check_recipient_access hash:/etc/postfix/recipient_access,
> 2.permit_auth_destination,
> 3.reject_unauth_pipelining
> 4.permit_mynetworks,
> 5.permit_sasl_authenticated,
> 6.reject_non_fqdn_recipient,
> 7.reject_unknown_recipient_domain,
> 8.reject_unauth_destination,
> 9.check_policy_service unix:/var/spool/postfix/var/run/postgrey/socket,
> 10.   reject

After restriction (2), all of your inbound domains are allowed,
and only outbound mail to remote domains is subject to further
checks.

After restriction (8), all remote domains are rejected.  And so
if this arrangement is intentional, and not a temporary attempt
to avoid rejecting email, then (9) can never be reached.

And likely adding (10) makes little sense after a greylisting policy
at (9), because I'd expect (9) to only ever "DEFER" or "DUNNO",
which means that nothing can get past (9) + (10).  I'd surprised
to find that "postgrey" returns "OK" and not "DUNNO" when greylisting
passes.

-- 
Viktor.

will master.cf inherit parameters from main.cf

[xiedeacc]

will master.cf inherit parameters from main.cf ? like
smptd_recipient_restrictions, I found I cannot set
smptd_recipient_restrictions=check_recipient_access
hash:/etc/postfix/recipient_access, it complaint fatal:
unexpected command-line argument: hash:/etc.



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

[xiedeacc]

thanks, I have read all those docs, and I find fix it, but after do some
tries, I find out config 
 wrong smtpd_relay_restrictions parameters , and ask another question, will
master.cf inherit parameters from main.cf like smptd_recipient_restrictions?



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

[Wietse Venema]

xiedeacc:
> Hi, all
> my postfix now can send/recive mail from my own domain, and can send out
> mail to external mail server like gmail, but cannot recive mail from
> external mail server, mail.log said reject: RCTP from xxx 554 5.7.1
> Recipient addressd: Access denied
> 
> smtpd_recipient_restrictions = check_recipient_access
> hash:/etc/postfix/recipient_access, permit_auth_destination,
> reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated,
> reject_non_fqdn_recipient, reject_unknown_recipient_domain,
> reject_unauth_destination, check_policy_service
> unix:/var/spool/postfix/var/run/postgrey/socket, reject
> 
> even I changed smtpd_recipient_restrictions to smtpd_recipient_restrictions
> = permit, it still didn't work

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

reject: RCTP from xxx 554 5.7.1 Recipient addressd: Access denied

[xiedeacc]

Hi, all
my postfix now can send/recive mail from my own domain, and can send out
mail to external mail server like gmail, but cannot recive mail from
external mail server, mail.log said reject: RCTP from xxx 554 5.7.1
Recipient addressd: Access denied

smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/recipient_access, permit_auth_destination,
reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
reject_unauth_destination, check_policy_service
unix:/var/spool/postfix/var/run/postgrey/socket, reject

even I changed smtpd_recipient_restrictions to smtpd_recipient_restrictions
= permit, it still didn't work



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: Postscreen Feature Request

[Wietse Venema]

Allen Coates:
> GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the
> decision to reject the message has already been made;
> It seems to me that this is an opportunity to tar-pit the (bad) remote
> host, diminishing spam throughput, and eroding the host's useful life-span.

postscreen could hand off a connection to some other daemon.

Keeping connections open *inside* postscreen is definitely not an
option. That would limit postcreen's scalability. With a tarpit-only
daemon, failure in that daemon would not affect other connections.

Wietse

Re: sasl auth LOGIN / PLAIN

[mj]

On 09/02/2017 01:16 PM, Patrick Ben Koetter wrote:

Mandatory STARTTLS*and*  disallowing any shared-secret mechanism (CRAM-MD5,
DIGEST-MD5, NTLM) is a clever move.

This way you protect the identity while it is transported from the client to
the server and you are able to store the passwords crypted.


Thank you, Patrick!

Re: sasl auth LOGIN / PLAIN

[Patrick Ben Koetter]

* mj :
> Hi,
> 
> Ok, so disallowing LOGIN is not a clever move :-)

Mandatory STARTTLS *and* disallowing any shared-secret mechanism (CRAM-MD5,
DIGEST-MD5, NTLM) is a clever move.

This way you protect the identity while it is transported from the client to
the server and you are able to store the passwords crypted.

p@rick




> 
> Thanks for your answers!
> 
> MJ
> 
> On 09/02/2017 08:32 AM, Patrick Ben Koetter wrote:
> > * postfix :
> > > On 09/01/2017 04:25 PM, mj wrote:
> > > > Just a small question: we currently use posfix with sasl authentication,
> > > > and folowing many docs, we have enabled PLAIN and LOGIN authentication.
> > > > 
> > > > However, googling leads me to believe that LOGIN is mostly used by
> > > > Outlook Express, and that most (or all?) modern clients support the
> > > > PLAIN mechanism.
> > > > 
> > > > I also noticed that most failed authentication attempts are done using
> > > > LOGIN.
> > > > 
> > > > Now, assuming that most of these failed authentications are simply
> > > > username/password guessing... how many problems would I expect, if I
> > > > simply only offer PLAIN mechanism?
> > > > 
> > > > It's hard to find info on what clients use what auth type. So, are
> > > > all/most modern clients capable of doing PLAIN? (thunderbird, outlook
> > > > 2010/2013) so could I simply disallow LOGIN?
> > 
> > Thunderbird:
> >  PLAIN, DIGEST-MD5
> > Outlook 20**:
> >  LOGIN, NTLM
> > 
> > > As far as I know, outlook does only LOGIN, even: because of outlook the
> > > LOGIN mechanism was introduced.
> > 
> > That is correct.
> > 
> > p@rick
> > 

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 

Postscreen Feature Request

[Allen Coates]

GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the
decision to reject the message has already been made;
It seems to me that this is an opportunity to tar-pit the (bad) remote
host, diminishing spam throughput, and eroding the host's useful life-span.

I SUGGEST, therefore, that an additional "TAR-PIT" option be added to
the list of available postscreen_mumble_action's.   I envisage this as
being the same as "ENFORCE", but with an added delay.

It would be very nice if the tar-pit action could be invoked from within
the Postscreen access control lists, but I appreciate that this could
disrupt stable and well-tested code.

I would be interested to hear what others make of this idea.

Allen C

Re: sasl auth LOGIN / PLAIN

[mj]

Hi,

Ok, so disallowing LOGIN is not a clever move :-)

Thanks for your answers!

MJ

On 09/02/2017 08:32 AM, Patrick Ben Koetter wrote:

* postfix :

On 09/01/2017 04:25 PM, mj wrote:

Just a small question: we currently use posfix with sasl authentication,
and folowing many docs, we have enabled PLAIN and LOGIN authentication.

However, googling leads me to believe that LOGIN is mostly used by
Outlook Express, and that most (or all?) modern clients support the
PLAIN mechanism.

I also noticed that most failed authentication attempts are done using
LOGIN.

Now, assuming that most of these failed authentications are simply
username/password guessing... how many problems would I expect, if I
simply only offer PLAIN mechanism?

It's hard to find info on what clients use what auth type. So, are
all/most modern clients capable of doing PLAIN? (thunderbird, outlook
2010/2013) so could I simply disallow LOGIN?


Thunderbird:
 PLAIN, DIGEST-MD5
Outlook 20**:
 LOGIN, NTLM


As far as I know, outlook does only LOGIN, even: because of outlook the
LOGIN mechanism was introduced.


That is correct.

p@rick

Re: sasl auth LOGIN / PLAIN

[Patrick Ben Koetter]

* postfix :
> On 09/01/2017 04:25 PM, mj wrote:
> > Just a small question: we currently use posfix with sasl authentication,
> > and folowing many docs, we have enabled PLAIN and LOGIN authentication.
> > 
> > However, googling leads me to believe that LOGIN is mostly used by
> > Outlook Express, and that most (or all?) modern clients support the
> > PLAIN mechanism.
> > 
> > I also noticed that most failed authentication attempts are done using
> > LOGIN.
> > 
> > Now, assuming that most of these failed authentications are simply
> > username/password guessing... how many problems would I expect, if I
> > simply only offer PLAIN mechanism?
> > 
> > It's hard to find info on what clients use what auth type. So, are
> > all/most modern clients capable of doing PLAIN? (thunderbird, outlook
> > 2010/2013) so could I simply disallow LOGIN?

Thunderbird:
PLAIN, DIGEST-MD5
Outlook 20**:
LOGIN, NTLM

> As far as I know, outlook does only LOGIN, even: because of outlook the
> LOGIN mechanism was introduced.

That is correct.

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein