Evgeniy Berdnikov <bd4@???> (Mi 18 Jan 2017 21:56:49 CET):
…
> > - 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.
Ah. Got it. Thank you.
Side note: we should have:
--> MAIL FROM:<>
<-- 250 OK
--> VRFY foo@???
<-- 250 OK foo@??? accepts mail from <>
--> QUIT
This would avoid all that clumsy sender-verification-de-impact
hacks.
> > 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
….
> 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).
Both can probably be combined, send the illegal 4xx response after the first BDAT
chunk AND drop the connection *if* the client continues sending or
shutdown gracefully if the client handles the illegal 4xx and sends a
QUIT
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
