On Sat, Sep 04, 2021 at 05:14:22PM -0400, Viktor Dukhovni via Exim-users wrote:
> As mentioned above, it should be rather rare for a legitimate MTA as a
> client to see such responses. Users of postscreen(8) should be cautious
> to not make it too aggressive in its policies. The intent is to redu
--On Saturday, September 4, 2021 17:14 -0400 Viktor Dukhovni via
Exim-users wrote:
>...
>> From that particular perspective and purpose, as soon as
>> someone says "for my specific application or bright idea, it
>> does not matter what the standard says", I sort of lose
>> interest.
>
> FWIW,
On Sat, Sep 04, 2021 at 04:51:29PM -0400, John C Klensin wrote:
> As I assume you may have guessed given that you follow
> EMAILCORE, my main interest in this right now is to think about
> what changes, if any, are needed in 5431bis. Watch for a note
> on that list and some changes in -04 that re
On 4 Sep 2021, at 3:00 pm, Andrew C Aitchison wrote:
> > The greet pause test is *specifically* designed to detect botnet spam
> > engines that don't wait for the complete multi-line response, and start
> > talking as soon as they detect the first line of the response. That's
> > why the pause i
(Note two responses combined below)
--On Saturday, September 4, 2021 14:07 -0400 Viktor Dukhovni via
Exim-users wrote:
>...
> The status code on the last line of a multi-line response is
> and will be taken as authoritative, regardless of any other
> status codes on prior lines of the response.
On Sat, 4 Sep 2021, Viktor Dukhovni via Exim-users wrote:
On Sat, Sep 04, 2021 at 01:18:17PM -0400, John C Klensin wrote:
Absent a time-machine, and given that the ultimate decision is
made after the initial banner and greet pause, and that
refusing SMTP service (521 banner) is supposed to onl
On Sat, Sep 04, 2021 at 01:18:17PM -0400, John C Klensin wrote:
> > Absent a time-machine, and given that the ultimate decision is
> > made after the initial banner and greet pause, and that
> > refusing SMTP service (521 banner) is supposed to only happen
> > to botnet and similar clients, the po
On Sat, Sep 04, 2021 at 08:28:29PM +0300, Evgeniy Berdnikov via Exim-users
wrote:
> IMHO, this discussion should be a motive for Exim and Postfix developers
> to add checks for consistency of SMTP status codes in multiline answers.
>
> Inconsistent protocol messages are indicators of software bug
On Sat, Sep 04, 2021 at 11:23:02AM -0400, Viktor Dukhovni via Exim-users wrote:
> FWIW, Postfix has always taken the SMTP status code from the last line
> of a multi-line server response, but as you noted there is no RFC
> requirement to do so, and the code is expected to not vary from line to
> li
--On Saturday, September 4, 2021 16:25 +0100 Sabahattin
Gucukoglu via Exim-users wrote:
>> If postscreen is doing it so wrongly, it is the thing that
>> needs fixing.
>
> I agree, it is, but Exim should be robust, all the same.
> Deferring mail when not needed is obviously undesirable.
Not so o
On 4 Sep 2021, at 15:42, Jeremy Harris via Exim-users
wrote:
> On 04/09/2021 15:03, Sabahattin Gucukoglu via Exim-users wrote:
>> perhaps Exim should consider the last line of a response instead of the
>> first for purposes of evaluation?
>
> I don't see a coherent argument for either direction
On Sat, Sep 04, 2021 at 03:42:39PM +0100, Jeremy Harris via Exim-users wrote:
> On 04/09/2021 15:03, Sabahattin Gucukoglu via Exim-users wrote:
> > perhaps Exim should consider the last line of a response instead of the
> > first for purposes of evaluation?
>
> I don't see a coherent argument for
On 04/09/2021 15:03, Sabahattin Gucukoglu via Exim-users wrote:
perhaps Exim should consider the last line of a response instead of the first
for purposes of evaluation?
I don't see a coherent argument for either direction,
when they differ.
If postscreen is doing it so wrongly, it is the thi
On 2 Sep 2021, at 23:24, Jeremy Harris via Exim-users
wrote:
> On 02/09/2021 20:25, krzf83--- via Exim-users wrote:
>> # nc mx.poczta.onet.pl 25
>> 220-mx.poczta.onet.pl ESMTP
>> 521 5.7.1 Service unavailable; client [144.76.50.172] blocked using
>> postscreenbl.opbl.onet.pl.local
>
> That is no
Hello.
On Thu, Sep 02, 2021 at 09:25:20PM +0200, krzf83--- via Exim-users wrote:
> Then exim should return message to sender immeadetly but it does not.
> Instead exim remembers that that remote mx is "failing for long time" and
> does not even try to deliver new mails! If exim for some reason
On 02/09/2021 20:25, krzf83--- via Exim-users wrote:
Large email provider in my country uses 521 response at their MX for
some kind of delaying. They don't care that its against rfc1846
rfc1846 says:" A host which sends a 521 greeting message MUST NOT be
listed as an MX record for any domain"
#
>
> 5xx means: permanent failure. Period.
Then exim should return message to sender immeadetly but it does not.
Instead exim remembers that that remote mx is "failing for long time" and
does not even try to deliver new mails! If exim for some reason does retry
then it logs "Remote host closed con
Hi,
krzf83--- via Exim-users (Fr 27 Aug 2021 13:10:01 CEST):
> Large email provider in my country uses 521 response at their MX for
> some kind of delaying. They don't care that its against rfc1846
>
> rfc1846 says:" A host which sends a 521 greeting message MUST NOT be
> listed as an MX record
Large email provider in my country uses 521 response at their MX for
some kind of delaying. They don't care that its against rfc1846
rfc1846 says:" A host which sends a 521 greeting message MUST NOT be
listed as an MX record for any domain"
# nc mx.poczta.onet.pl 25
220-mx.poczta.onet.pl ESMTP
52
19 matches
Mail list logo
