Re: [exim] gotcha: chunking and predata

Pàgina inicial
Delete this message
Reply to this message
Autor: Heiko Schlittermann
Data:  
A: exim-users
Assumpte: Re: [exim] gotcha: chunking and predata
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 ------------ -