On Wed, Jan 18, 2017 at 03:32:44PM +0000, Jeremy Harris wrote:
> On 18/01/17 14:50, Evgeniy Berdnikov wrote:
> > On Wed, Jan 18, 2017 at 04:07:01PM +0200, Lena@??? wrote:
> >>> From: Heiko Schlittermann
> >>
> >>> Just of curiosity: What use case do you have for your pre-data ACL?
...
> > Greylisting of messages from <> should be done on this stage.
> > It's good to combine it with check for number of recipients.
>
> Raises an interesting point with regard to CHUNKING. Why in
> predata specifically?
>
> - I'll start with: you don't want it at RCPT or earlier
> because that will impact sender-verify callbacks.
Exactly. Session with "MAIL FROM: <>" may be a sender verification
callback, so in this case we want to send clear 2xx responses to RCPTs
as client expects, suppressing 4xx codes from greylisting engine.
That's why greylisting is postponed until DATA command received.
> And you'd prefer before all the data is transmitted
> because that's a waste of bits and cpu.
Right.
> Any more?
>
> What should be preferred practice
> when CHUNKING is used?
With BDAT syntax we have to mix "pre-data" and "post-data" approaches.
Unfortunately, this way conflicts with RFC3030 which states:
A 250 response MUST be sent to each successful BDAT data block within
a mail transaction. If a failure occurs after a BDAT command is
received, the receiver-SMTP MUST accept and discard the associated
message data before sending the appropriate 5XX or 4XX code. If a
5XX or 4XX code is received by the sender-SMTP in response to a BDAT
chunk, the transaction should be considered failed and the sender-
SMTP MUST NOT send any additional BDAT segments. If the receiver-
SMTP has declared support for command pipelining [PIPE], the receiver
SMTP MUST be prepared to accept and discard additional BDAT chunks
already in the pipeline after the failed BDAT.
So the "legal" way is to postpone 4xx response until the completion of
data stream. The protocol design is nasty. To overcome it one can violate
RFC3030 and send 4xx response to the first BDAT. However, there is more
efficient way: server can close socket on the receipt of BDAT, client
should get EOF and process such transmission error as receipt of 4xx. :)
Sounds funny, yes, but can be implemented in Exim as conditional "drop"
in acl_smtp_bdat (to be executed on first BDAT command).
--
Eugene Berdnikov
