Evgeniy Berdnikov <b...@protva.ru> (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 f...@example.com
        <-- 250 OK f...@example.com 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 ------------ -

Attachment: signature.asc
Description: Digital signature

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to