Re: [Asrg] Re: draft-hall-inline-dsn-01

On 2007-01-28 21:24:33 +0100, Frank Ellermann wrote:
> Peter J. Holzer wrote:
> > David Nicols' DATAFIRST proposal.
> [...]
> > > Could "DATA-first mail" (DF) work ?
>  
> > It could but in reality quite a lot of mail is rejected before
> > it even hits the DATA stage (either because none of the recipients
> > exists or because of checks which don't need the content (DNSBL,
> > greylisting, ...).
> Some of the checks (incl. DNSBL and SPF) are possible before RCPT,
But rejecting because the recipient doesn't exist, isn't possible before
the recipient is known, and that is the most common cause for permanent
failures.

> unless you intend to apply them selectively per receiver.
In fact I do. SBL-XBL is currently used for all addresses except
postmaster, and I plan to enable PBL for a few addresses to test it. I
don't check SPF currently (doesn't seem worth it), but if I did I
certainly would only do it on a per-recipient basis. Greylisting needs
the recipient, and while having a part of the data (especially the
message-id) would help, I don't think it would offset the increase in
traffic caused by transferring the same message several times and
getting a temporary failure each time until the greylisting period is
over.


> If you want to get RCPT before DATA it's simple, just don't offer
> "DATAFIRST".
But I want both. I want the ability to reject on a per-recipient basis
before I receive the data, and I want the ability to selectively apply
content filters for different recipients.


> > With DATAFIRST all this mail will have to be transferred only to
> > be rejected. I suspect that this will sharply increase the bandwidth
> > requirements.
> It should be visible in the log files of major site.  If they check 
> more than only the size between DATA and dot,
We are not a major site, but we are running spamassassin between DATA
and dot, so we do have a reason to return different responses for
different recipients. We are using an ugly hack at the moment
(http://www.hjp.at/projekte/qpsmtpd/cf_wrapper/), but I would like
something cleaner. (I am fully aware of course that I would need to keep
the hack for many years, until INLINE-DSN (or DEFERRAL, or however it is
going to be called) is implemented by most of our neighbours)

> otherwise they can't be interested to get "DATAFIRST" anyway.
I'm not interested in DATAFIRST. I'm interested in returning
per-recipient results to DATA.

> What I didn't like in draft-hall-inline-dsn was the sequence of
> per recipient responses after DATA matching the sequence of RCPT
> before DATA.
That's what the proposal is about. It allows several return codes for
DATA. The exact mechanism might be different (for example, there could
be a multiline-response instead of multiple single-line responses, or
the return codes can be matched by address instead of order), but these
are minor changes.

> It would be more plausible if it implies PIPELINING.
The proposal suggests that a implementation offering INLINE-DSN also
offers PIPELINING, but frankly, I fail to see the connection.

        hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Sam in "Freefall"

signature.asc
Description: Digital signature

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg