Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Wietse Venema]

Andreas Thienemann:
> Hi Wietse,
> 
> On Wed, 3 Apr 2019, Wietse Venema wrote:
> 
> > I am investigating this in my copious spare time. The channel from
> > cleanup to smtpd was originally designed for single-line responses
> > from header/body_checks. If that is the problem then I'll devise a
> > workaround for existing code, and a proper solution for Postfix 3,5
> > and onwards.
> 
> I was just writing a policyd to do a bit fancy greylisting with other 
> lookups and realized that it would be _very_ interesting if such multiline 
> messages could also be sent via the policy delegation protocol...

Enabling ASCII art in SMTP error messages? I have better things to do.

> Thanks again for the quick workaround for the current milter code.

That code was already implemented, I just forgot to update a safety check.

Wietsetsee

Re: Bug report: problem with smtp_mx_address_limit = 0

[Luc Pardon]

On 3/04/19 17:13, Viktor Dukhovni wrote:
> 
> 
> It seems you're in a sardonic mood, ... best to not go there.

If I gave that impression, I apologize.

All I was trying to say is that, because of the bug, you may be more
likely to run out of disk space by trying to send to bona fide domains
like postfix.org than because of overworked delivery agents, simply
because MX's with both A and  records are much more common (and
growing) than malicious ones.

Anyway, the most important thing is that the bug has been noted, and
will eventually be fixed, one way or another.

Thanks for that.

Luc

Re: MAILER DAEMON email address question

[Bill Cole]

On 3 Apr 2019, at 11:11, Giles Coochey wrote:


Yet further off-topic, I have

FEATURE(`accept_unresolvable_domains')

Configured  for sendmail - but suspect that sendmail still doesn't 
relay if the domain is unresolvable.


Yes, it will, if it will relay for (or deliver locally) the recipient 
domain. That's what accept_unresolvable_domains does. It's a generally 
bad idea.


However, even after you fix that you should also have 
reject_unknown_sender_domain in your smtpd_sender_restrictions list (or 
a later restriction list) in Postfix and set unknown_address_reject_code 
= 553. It is just as generally a bad idea to accept bogus senders in 
Postfix as it is in Sendmail.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Bug report: problem with smtp_mx_address_limit = 0

[Viktor Dukhovni]

> On Apr 3, 2019, at 7:02 AM, Luc Pardon  wrote:
> 
>> ... and watch their mail queues melt down.
> 
> ... because of all the mail that will get stuck in the queue with
> "server unavailable or unable to receive mail" for _any_ MX that has
> _both_ A and  records.

No, because failing deliveries to domains with tens to hundreds of
unavailable MX host IPs would DoS the queue by tying up delivery
agents for an unreasonably long time.

It seems you're in a sardonic mood, ... best to not go there.
Your bug report has been noted, and the solution will most
likely be to drop the interpretation of 0 == unlimited.  If
someone decides to set an explicit non-default limit, it will
be more obviously a potential resource issue than "I can't
think of what the limit should be, so just turn it off".

-- 
Viktor.

Re: MAILER DAEMON email address question

[Marco]

Il 03/04/2019 15:12, Matus UHLAR - fantomas ha scritto:

does "such" mean null recipient here?  does empty_address_recipient affect
both the address in From: of bounces and address for which mail is always
accepted?  Do I have to alias MAILER-DAEMON (or what 
empty_address_recipient

is set to) to direct mail to postmaster account?  And if I don't, will I
get double-bounce?


Interesting!

In my environment I verified that empty_address_recipient is not related 
to the MAILER-DAEMON recipient address behavior. The only always 
accepted recipient address still remains 
MAILER-DAEMON@, even if you change the 
empty_address_recipient.


As you suggest, I think I have to define some transport for 
MAILER-DAEMON recipient address. Otherwise I get double-bounce.


Warm Regards
Marco

Re: MAILER DAEMON email address question

[Giles Coochey]

On 03/04/2019 15:25, Wietse Venema wrote:

Giles Coochey:


I think I've checked that already:

# grep? reject_unknown_recipient_domain /etc/postfix/main.cf
#

OK, now try unknown_sender_domain.

Nothing there, but see below!

But perhaps one of these settings causes it?

Or you could end this guessing game, if you can give the full Postfix
logfile record. You may obfuscate domains, hosts, IP addresses, and
users, but not the text that describes the nature of the error.

The point is, out-of-the-box Postfix does not give a hoot about the
sender email address. You configured Postfix to reject the sender,
and you will configure Postfix to stop doing that.

Wietse


Ha! Turns out it is not a postfix problem at all, but looks to be issue 
with sendmail... so this is off-topic for this list - I only found this 
out when changing smtpd to -vvv in master.cf and found nothing in the 
logs on the postfix server when flushing the queues on the sendmail server.


Yet further off-topic, I have

FEATURE(`accept_unresolvable_domains')

Configured  for sendmail - but suspect that sendmail still doesn't relay 
if the domain is unresolvable. It accepts the message, and would 
probably deliver it to a local account, but not relay to another box.


So narrows it down, I last configured this box about 7 years ago, so 
wonder whether to replace it with postfix I'll take my problem 
elsewhere now!

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Andreas Thienemann]

Hi Wietse,

On Wed, 3 Apr 2019, Wietse Venema wrote:


I do not know if skipping the printable() call does have any side-effects
though.


As a short-term fix it is probably OK, because the cleanup daemon
already filters the response. But smtpd should not rely on the
cleanup server doing that.


Right. That seems sensible.


A longer-term solution should enforce the single-line form (with
the existing printable(foo, ' ') call) by default, and allow
properly-formatted SMTP when SMTP is allowed. This way, proper
operation of the SMTP daemon won't be affected when the cleanup
daemon is borked. This is basic error containment.


3.5 then. :-) Right now I am still on 3.2 but this gives me a good reason 
to upgrade.


In the meantime, thank you for the workaround.

cheers,
 Anreas

Re: MAILER DAEMON email address question

[Wietse Venema]

Giles Coochey:
> 
> On 03/04/2019 14:58, Wietse Venema wrote:
> > Giles Coochey:
> >> I notice that some mails that pass the sendmail server get rejected by
> >> postfix, because the sender domain appears to be NXDOMAIN. I assume
> >> these are temporary 400 rejections (to cope with a failed DNS) -?
> >> Sendmail keeps these in the queue for a number of days and eventually my
> >> postmaster receives a NDR - the NDR can't be sent to the originator
> >> because the reply email is not valid anyway.
> > If you don't want Postfix to reject this mail then DO NOT SPECIFY
> > reject_unknown_recipient_domain.
> 
> I think I've checked that already:
> 
> # grep? reject_unknown_recipient_domain /etc/postfix/main.cf
> #

OK, now try unknown_sender_domain.

> But perhaps one of these settings causes it?

Or you could end this guessing game, if you can give the full Postfix
logfile record. You may obfuscate domains, hosts, IP addresses, and
users, but not the text that describes the nature of the error.

The point is, out-of-the-box Postfix does not give a hoot about the
sender email address. You configured Postfix to reject the sender,
and you will configure Postfix to stop doing that.

Wietse

Re: MAILER DAEMON email address question

[Giles Coochey]

On 03/04/2019 14:58, Wietse Venema wrote:

Giles Coochey:

I notice that some mails that pass the sendmail server get rejected by
postfix, because the sender domain appears to be NXDOMAIN. I assume
these are temporary 400 rejections (to cope with a failed DNS) -?
Sendmail keeps these in the queue for a number of days and eventually my
postmaster receives a NDR - the NDR can't be sent to the originator
because the reply email is not valid anyway.

If you don't want Postfix to reject this mail then DO NOT SPECIFY
reject_unknown_recipient_domain.


I think I've checked that already:

# grep  reject_unknown_recipient_domain /etc/postfix/main.cf
#

But perhaps one of these settings causes it?

# postconf | grep reject
access_map_reject_code = 554
invalid_hostname_reject_code = 501
maps_rbl_reject_code = 554
message_reject_characters =
multi_recipient_bounce_reject_code = 550
non_fqdn_reject_code = 504
plaintext_reject_code = 450
reject_code = 554
reject_tempfail_action = defer_if_permit
relay_domains_reject_code = 554
smtpd_delay_reject = yes
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
smtpd_reject_unlisted_recipient = yes
smtpd_reject_unlisted_sender = no
unknown_address_reject_code = 450
unknown_address_tempfail_action = $reject_tempfail_action
unknown_client_reject_code = 450
unknown_helo_hostname_tempfail_action = $reject_tempfail_action
unknown_hostname_reject_code = 450
unknown_local_recipient_reject_code = 550
unknown_relay_recipient_reject_code = 550
unknown_virtual_alias_reject_code = 550
unknown_virtual_mailbox_reject_code = 550
unverified_recipient_reject_code = 450
unverified_recipient_reject_reason =
unverified_recipient_tempfail_action = $reject_tempfail_action
unverified_sender_reject_code = 450
unverified_sender_reject_reason =
unverified_sender_tempfail_action = $reject_tempfail_action


Doctor it hurts when I hit my head with a hammer. Stop hitting your
head with a hammer!

Wuetse

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Wietse Venema]

Andreas Thienemann:
> Looks good to me. Patched, rebuilt, verified working.
> 
> Multiline responses from the milter are now correctly forwarded the smtpd 
> and the client does not timeout anymore waiting for data.
> 
> I do not know if skipping the printable() call does have any side-effects 
> though.

As a short-term fix it is probably OK, because the cleanup daemon
already filters the response. But smtpd should not rely on the
cleanup server doing that.

A longer-term solution should enforce the single-line form (with
the existing printable(foo, ' ') call) by default, and allow
properly-formatted SMTP when SMTP is allowed. This way, proper 
operation of the SMTP daemon won't be affected when the cleanup
daemon is borked. This is basic error containment.

Wietse

Re: MAILER DAEMON email address question

[Wietse Venema]

Giles Coochey:
> I notice that some mails that pass the sendmail server get rejected by 
> postfix, because the sender domain appears to be NXDOMAIN. I assume 
> these are temporary 400 rejections (to cope with a failed DNS) -? 
> Sendmail keeps these in the queue for a number of days and eventually my 
> postmaster receives a NDR - the NDR can't be sent to the originator 
> because the reply email is not valid anyway.

If you don't want Postfix to reject this mail then DO NOT SPECIFY
reject_unknown_recipient_domain.

Doctor it hurts when I hit my head with a hammer. Stop hitting your
head with a hammer!

Wuetse

Re: Rewriting recipient before routing the email

[Bill Cole]

On 3 Apr 2019, at 2:38, André Rodier wrote:

> Maybe I can do this with recipient delimiter, but can I have more than
> one character recipient delimiter in postfix?

Yes. See the man page for postconf(5)



-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Andreas Thienemann]

Hi Wietse,

On Wed, 3 Apr 2019, Wietse Venema wrote:


Try this:

*** ./src/smtpd/smtpd.c-2019-03-30 08:05:29.0 -0400
--- ./src/smtpd/smtpd.c 2019-04-03 08:26:07.0 -0400
***
*** 3598,3604 
if (state->err == 0) {
why = vstring_alloc(10);
state->err = mail_stream_finish(state->dest, why);
!   printable(STR(why), ' ');
} else
mail_stream_cleanup(state->dest);
state->dest = 0;
--- 3598,3604 
if (state->err == 0) {
why = vstring_alloc(10);
state->err = mail_stream_finish(state->dest, why);
!   // printable(STR(why), ' ');
} else
mail_stream_cleanup(state->dest);
state->dest = 0;


Looks good to me. Patched, rebuilt, verified working.

Multiline responses from the milter are now correctly forwarded the smtpd 
and the client does not timeout anymore waiting for data.


I do not know if skipping the printable() call does have any side-effects 
though.


Swaks output with the patch applied:

$ swaks --server localhost --from '<>' --to t...@bawue.de -d '.'
=== Trying localhost:25...
=== Connected to localhost.
<-  220 mailin01.mx.bawue.net ESMTP Postfix
 -> EHLO mailin01.mx.bawue.net
<-  250-mailin01.mx.bawue.net
<-  250-PIPELINING
<-  250-SIZE 41943040
<-  250-VRFY
<-  250-ETRN
<-  250-STARTTLS
<-  250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN DESTADDR DESTPORT
<-  250-ENHANCEDSTATUSCODES
<-  250-8BITMIME
<-  250 DSN
 -> MAIL FROM:<>
<-  250 2.1.0 Ok
 -> RCPT TO:
<-  250 2.1.5 Ok
 -> DATA
<-  354 End data with .
 ->
 -> .
<** 450-4.7.1 Test Milter rejection Reason
<** 450-4.7.1 Test Milter rejection Reason 01
<** 450 4.7.1 Test Milter rejection Reason 02
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with remote host.


cheers,
 Andreas

Re: MAILER DAEMON email address question

[Matus UHLAR - fantomas]

>Marco:
>> The only exception is the recipient "mailer-dae...@example.com", where
>> let suppose example.com is a local domain.

On 03.04.19 07:16, Wietse Venema wrote:
>MAILER-DAEMON is special. Postfix sends mail mail from <> as
>MAILER-DAEMON@$myorigin and accepts mail for MAILER-DAEMON (or
>whatever empty_address_recipient says).


I apparently misunderstood the empty_address_recipient docs:

 The recipient of mail addressed to the null address.  Postfix does not
 accept such addresses in SMTP commands, but they may still be created
 locally as the result of configuration or software error.

does "such" mean null recipient here?  does empty_address_recipient affect
both the address in From: of bounces and address for which mail is always
accepted?  Do I have to alias MAILER-DAEMON (or what empty_address_recipient
is set to) to direct mail to postmaster account?  And if I don't, will I
get double-bounce?


Matus UHLAR - fantomas:

is there a reason to accept replies to DSNs, which should not be replied to?


On 03.04.19 08:45, Wietse Venema wrote:

So as not to make a bad situation worse. This may be an unnatuural
approach for some people.


... says my experience with people notorically responding to bounces.


When the shit hits the fan, don't throw
it back, just get rid of it.


I'd say that rejecting double bounces is getting rid of it.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]

Re: MAILER DAEMON email address question

[Giles Coochey]

On 03/04/2019 13:45, Wietse Venema wrote:

Matus UHLAR - fantomas:

Marco:

The only exception is the recipient "mailer-dae...@example.com", where
let suppose example.com is a local domain.

On 03.04.19 07:16, Wietse Venema wrote:

MAILER-DAEMON is special. Postfix sends mail mail from <> as
MAILER-DAEMON@$myorigin and accepts mail for MAILER-DAEMON (or
whatever empty_address_recipient says).

is there a reason to accept replies to DSNs, which should not be replied to?

So as not to make a bad situation worse. This may be an unnatuural
approach for some people. When the shit hits the fan, don't throw
it back, just get rid of it.

Wietse


This leads me to a question I have.

In my environment I have external SMTP servers (sendmail), these servers 
accept email from external sources outside of my environment, runs 
Anti-Virus and Spam protection and if these pass they forwards the mail 
onto an internal SMTP server (postfix) which handles the local mailboxes 
(for dovecot IMAP). If the external servers result in a reject 50x error 
(because of spam or virus), I don't have to care whether someone gets a 
MAILER-DAEMON reply, because my servers didn't send it we just rejected 
it during the SMTP session.


I notice that some mails that pass the sendmail server get rejected by 
postfix, because the sender domain appears to be NXDOMAIN. I assume 
these are temporary 400 rejections (to cope with a failed DNS) -  
Sendmail keeps these in the queue for a number of days and eventually my 
postmaster receives a NDR - the NDR can't be sent to the originator 
because the reply email is not valid anyway.


The email that result in NXDOMAIN are usually mis-configured 
mailing-lists, and my users would probably want to receive these email, 
they're because the mailing-list sender has made a mistake (i.e. they've 
used no-re...@churchhouseinnmarldon.co.uk, instead of their actual 
domain churchhouseinnmarldon.com). Incidentally 
postmas...@churchhouseinnmarldon.com doesn't exist either, and whois 
information leads to an anonymous web form which doesn't appear to be 
monitored.


What postfix configuration can I perform to allow postfix to ignore this 
mis-configuration on the remote sender part, or what sendmail 
configuration can I put in to reject with 50x error when it is talking 
with the mailing-list software, which I would assume then that the 
mailing-list operator might discover their error...

Re: MAILER DAEMON email address question

[Wietse Venema]

Matus UHLAR - fantomas:
> >Marco:
> >> The only exception is the recipient "mailer-dae...@example.com", where
> >> let suppose example.com is a local domain.
> 
> On 03.04.19 07:16, Wietse Venema wrote:
> >MAILER-DAEMON is special. Postfix sends mail mail from <> as
> >MAILER-DAEMON@$myorigin and accepts mail for MAILER-DAEMON (or
> >whatever empty_address_recipient says).
> 
> is there a reason to accept replies to DSNs, which should not be replied to?

So as not to make a bad situation worse. This may be an unnatuural
approach for some people. When the shit hits the fan, don't throw
it back, just get rid of it.

Wietse

Re: MAILER DAEMON email address question

[Matus UHLAR - fantomas]

Marco:

The only exception is the recipient "mailer-dae...@example.com", where
let suppose example.com is a local domain.


On 03.04.19 07:16, Wietse Venema wrote:

MAILER-DAEMON is special. Postfix sends mail mail from <> as
MAILER-DAEMON@$myorigin and accepts mail for MAILER-DAEMON (or
whatever empty_address_recipient says).


is there a reason to accept replies to DSNs, which should not be replied to?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Wietse Venema]

Try this:

*** ./src/smtpd/smtpd.c-2019-03-30 08:05:29.0 -0400
--- ./src/smtpd/smtpd.c 2019-04-03 08:26:07.0 -0400
***
*** 3598,3604 
if (state->err == 0) {
why = vstring_alloc(10);
state->err = mail_stream_finish(state->dest, why);
!   printable(STR(why), ' ');
} else
mail_stream_cleanup(state->dest);
state->dest = 0;
--- 3598,3604 
if (state->err == 0) {
why = vstring_alloc(10);
state->err = mail_stream_finish(state->dest, why);
!   // printable(STR(why), ' ');
} else
mail_stream_cleanup(state->dest);
state->dest = 0;

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Andreas Thienemann]

Hi Wietse,

On Wed, 3 Apr 2019, Wietse Venema wrote:


I am investigating this in my copious spare time. The channel from
cleanup to smtpd was originally designed for single-line responses
from header/body_checks. If that is the problem then I'll devise a
workaround for existing code, and a proper solution for Postfix 3,5
and onwards.


Hahaha, thank you very much. I appreciate it. Especially as we all know 
about that copious spare time.


If it helps, the sample milter I used is at 
https://gist.github.com/ixs/70ec5ba23c8da0c9ee3c682eeb8fe452


cheers,
 Andreas

Re: MAILER DAEMON email address question

[Wietse Venema]

Marco:
> The only exception is the recipient "mailer-dae...@example.com", where 
> let suppose example.com is a local domain.

MAILER-DAEMON is special. Postfix sends mail mail from <> as
MAILER-DAEMON@$myorigin and accepts mail for MAILER-DAEMON (or
whatever empty_address_recipient says).

Wietse

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Wietse Venema]

John Fawcett:
> The output you sent shows what the smtpd server replies to the client
> and shows a different behaviour between sendmail and postfix when the
> milter uses? smfi_setmlreply(). It does not show that postfix is
> receiving multiple reply lines from the milter and folding them, though
> of course you may be right about it.
> 
> If you want to investigate this further you could turn on verbose
> logging on the smtpd and cleanup processes and you will see a bit more
> info about what is happening. If I'm reading this correctly the end of
> message milter is being evaluated in the cleanup process
> in?cleanup_milter_apply for event SMFIC_BODYEOB. The cleanup process
> then sends the reject reason to the smtpd process.

I am investigating this in my copious spare time. The channel from
cleanup to smtpd was originally designed for single-line responses
from header/body_checks. If that is the problem then I'll devise a
workaround for existing code, and a proper solution for Postfix 3,5
and onwards.

Wietse

Re: Bug report: problem with smtp_mx_address_limit = 0

[Luc Pardon]

On 3/04/19 01:16, Wietse Venema wrote:

> I prefer to remove the ability to disable safety mechanisms. 

And in your initial response, you also wrote:

> Probably better to not allow a limit-less smtp_mx_address_limit,
> as it makes Postfix vulnerable to resource exhaustion attack.

Both responses seem to translate to "I prefer to remove the ability to
set smtp_mx_address_limit to zero".

As I said, that's fine with me.


My only comment is that this won't bring you much.

As you indicate yourself, people would still have the ability to
effectively disable the safety mechanism (by setting
smtp_mx_address_limit to one bazillion or so).

The only difference is that, if they really want to get rid of the
limit, they would (have to) disable it in an undocumented way.

So, given that you can't prevent people from shooting themselves in the
foot anyway, it seems more logical to let them do it in the (currently)
documented way.


This being said, I personally don't really care whether the ability to
set smtp_mx_address_limit to zero is fixed or removed, but something has
to be done.

As it stands now, people can still set it to zero ...

>
> ... and watch their mail queues melt down.
>

... because of all the mail that will get stuck in the queue with
"server unavailable or unable to receive mail" for _any_ MX that has
_both_ A and  records.

One of each is enough to trigger the bug, even if they would all respond
if Postfix bothered to try. But it doesn't. It simply defers the mail
until it eventually expires and bounces.



Anyway, I have reported the issue and am happy to leave it at that.

Luc

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[Andreas Thienemann]

Hi John,

On Wed, 3 Apr 2019, John Fawcett wrote:


 The output you sent shows what the smtpd server replies to the client
 and shows a different behaviour between sendmail and postfix when the
 milter uses  smfi_setmlreply(). It does not show that postfix is
 receiving multiple reply lines from the milter and folding them, though
 of course you may be right about it.


True. But considering that Net::Milter also does the right thing, it seems like 
a good conclusion that Postfix was doing line folding.


But you are right, it is good to verify. I did a quick tcpdump and having a 
look at the communication between Postfix and milter shows that the milter is 
sending the data 0x0d 0x0a separated:


   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..E.
0010   00 b6 da 43 40 00 40 06 61 fc 7f 00 00 01 7f 00   ...C@.@.a...
0020   00 01 27 24 c2 b2 07 a2 e1 25 76 c2 cd 87 80 18   ..'$.%v.
0030   01 6f fe aa 00 00 01 01 08 0a ca b4 3c f9 ca b4   .o..<...
0040   3c f9 00 00 00 7e 79 34 35 30 2d 34 2e 37 2e 31   <~y450-4.7.1
0050   20 54 65 73 74 20 4d 69 6c 74 65 72 20 72 65 6aTest Milter rej
0060   65 63 74 69 6f 6e 20 52 65 61 73 6f 6e 0d 0a 34   ection Reason..4
0070   35 30 2d 34 2e 37 2e 31 20 54 65 73 74 20 4d 69   50-4.7.1 Test Mi
0080   6c 74 65 72 20 72 65 6a 65 63 74 69 6f 6e 20 52   lter rejection R
0090   65 61 73 6f 6e 20 30 31 0d 0a 34 35 30 20 34 2e   eason 01..450 4.
00a0   37 2e 31 20 54 65 73 74 20 4d 69 6c 74 65 72 20   7.1 Test Milter
00b0   72 65 6a 65 63 74 69 6f 6e 20 52 65 61 73 6f 6e   rejection Reason
00c0   20 30 32 0002.

TCP Data starts at 0x0042.

You can see the letter y which translates to SMFIR_REPLYCODE followed by the 
multiline response as a string.




 If you want to investigate this further you could turn on verbose
 logging on the smtpd and cleanup processes and you will see a bit more
 info about what is happening. If I'm reading this correctly the end of
 message milter is being evaluated in the cleanup process
 in cleanup_milter_apply for event SMFIC_BODYEOB. The cleanup process
 then sends the reject reason to the smtpd process.


The verbose logging does not really help a lot as the log does only show the 
reply in a mangled form.


Apr  3 10:14:20 mailin01 postfix/cleanup[32144]: 6FB7F84ECE6: 
message-id=<20190403101419.032...@mailin01.mx.bawue.net>
Apr  3 10:14:20 mailin01 postfix/cleanup[32144]: 6FB7F84ECE6: milter-reject: 
END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Test Milter rejection 
Reason??450-4.7.1 Test Milter rejection Reason 01??450 4.7.1 Test Milter 
rejection Reason 02; from= 
to=<20021025122631.ga4...@lemmies.lb.bawue.de> proto=ESMTP 
helo=
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: vstream_buf_get_ready: fd 24 got 
144
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: public/cleanup socket: wanted 
attribute: status

Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: input attribute name: status
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: input attribute value: 256
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: public/cleanup socket: wanted 
attribute: reason

Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: input attribute name: reason
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: input attribute value: 450-4.7.1 
Test Milter rejection Reason??450-4.7.1 Test Milter rejection Reason 01??450 
4.7.1 Test Milter rejection Reason 02
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: public/cleanup socket: wanted 
attribute: (list terminator)

Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: input attribute name: (end)
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: > localhost[127.0.0.1]: 
450-4.7.1 Test Milter rejection Reason  450-4.7.1 Test Milter rejection Reason 
01  450 4.7.1 Test Milter rejection Reason 02

Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: abort all milters
Apr  3 10:14:20 mailin01 postfix/smtpd[32126]: milter8_abort: abort milter 
inet:localhost:10020


If I look at this, it seems like smtpd is getting the data in the right form 
(signified by the ?? which probably indicate the \n and \r chars) and then 
sends it out replaced by spaces three lines below.


I had a quick look at the smtpd_chat functions but I am not seeing anything 
obvious there that replaces control characters with spaces.
There is a function called printable() that would do the trick but as far as I 
can see that is only used to format log messages. On the other hand, this seems 
to be the source for the ?? replacement in the log message.


cheers,
  Andreas

Re: Authentication attempts for x...@com.au addresses

[Matus UHLAR - fantomas]

On 03.04.19 14:14, James Brown wrote:

Thanks all for your replies. Increasing both Ban time and Find time are good 
and I’ll do that. Looking through the logs I can see some repeated IPs for IMAP 
failures, but over long times (eg maybe once or twice a day max).

We have Stunnel receive the traffic on port 465 and 587 and forward on to
127.0.0.1 on port 25.


time to change this.

1. different ports are for different access rules, ports 465 and 587 should
NOT accept unauthenticated mail.
2. port 587 is plaintest, should be required STARTTLS, afaik stunnel does
not support this

3. postfix can do those much better than stunnel.


 So that is why I can’t write a Fail2ban rule for
this log line:

auth-worker(42777): Info: sql(cont...@com.au 
,127.0.0.1): unknown user (given password: Password123)

as it would ban localhost, not the original IP that Stunnel received.


4. postfix would not try to ban localhost.

just remove that stunnel.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]

MAILER DAEMON email address question

[Marco]

Hello,

 I have configured postfix with local domains

mydestination = ldap:/etc/postfix/ldap-localdomain.cf

and to check local recipients:

local_recipient_maps = ldap:/etc/postfix/ldap-localrecipient.cf

smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination

smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unlisted_recipient,
permit

There are no aliases:
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases

and "aliases" is an empty file. There are no canonical or masquerade 
domains.


Postfix works as I like for all recipients: existing recipients are 
accepted and non existing recipients (no results in 
ldap-localrecipient.cf) are rejected.


The only exception is the recipient "mailer-dae...@example.com", where 
let suppose example.com is a local domain.


For instance:

telnet mail.example.com 25
Trying 10.10.40.50...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP MAIL Welcome
ehlo example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10485760
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from:
250 2.1.0 Ok
rcpt to:
250 2.1.5 Ok
rcpt to:
550 5.1.1 : Recipient address rejected: User 
unknown in local recipient table

quit


# postmap -q mailer-dae...@example.com 
ldap:/etc/postfix/ldap-localrecipient.cf


has no result, like dsfsd...@example.com. But mailer-dae...@example.com 
is accepted. Could you help me to understand why?


It seems that the recipients "MAILER-DAEMON@" are 
always accepted. I would like to know if there is some specification to 
always accept these recipients, or if I made some mistakes in my conf.


mail_version = 3.3.2

Thank you very much
Marco

Re: Postfix and smfi_setmlreply() milter command resulting in SMTP protocol breakage.

[John Fawcett]

On 02/04/2019 10:48, Andreas Thienemann wrote:
> Hi,
>
> I have a locally developed milter using the python-milter bindings
> which seems to trigger a Postfix bug.
>
> The milter in question uses the smfi_setmlreply() command to set a
> multiline response as defined in rfc5321.
>
> Multiline replies should result in the smtpd replying with something
> like the following to e.g. a rejected DATA command:
>
> 450-4.7.1 Line 1
> 450-4.7.1 Line 2
> 450 4.7.1 Line 3
>
> Postfix however seems to fold the reply into a single line:
>
> 450-4.7.1 Line 1  450-4.7.1 Line 2  450 4.7.1 Line 3

The output you sent shows what the smtpd server replies to the client
and shows a different behaviour between sendmail and postfix when the
milter uses  smfi_setmlreply(). It does not show that postfix is
receiving multiple reply lines from the milter and folding them, though
of course you may be right about it.

If you want to investigate this further you could turn on verbose
logging on the smtpd and cleanup processes and you will see a bit more
info about what is happening. If I'm reading this correctly the end of
message milter is being evaluated in the cleanup process
in cleanup_milter_apply for event SMFIC_BODYEOB. The cleanup process
then sends the reject reason to the smtpd process.

John