On Wed, Apr 17, 2002 at 11:18:00PM +0100, Matthew Byng-Maddick wrote:
> On Wed, Apr 17, 2002 at 08:50:01PM +0100, Sean Rima wrote:
> > On Wed, 17 Apr 2002, Matthew Byng-Maddick spake thusly:
> > >> > http://marc.merlins.org/linux/exim/local_scan.c
> > >> How does this tie in with Exiscan, as it would be excellent to have both
> > >> tied in at once :)
> > > And if you get duplicate mail, don't blame anyone but yourselves.
> > Not having looked at linking both, I am curious how you feel there would
> > be duplicate mails.
>
> RFC2821 S6.1:
> [...]
> | To avoid receiving duplicate messages as the result of timeouts, a
> | receiver-SMTP MUST seek to minimize the time required to respond to
> | the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [28] for
> | a discussion of this problem.
>
> I think that's pretty explicit.
>
> If you don't see why, S4.5.3.2 "DATA Termination" has a bit more discussion.
You are correct.
Running SA at SMTP time shoould be ok since I've never seen it take more
than 5 sec (maybe 10) on my systems.
Sure, RFC 1047 says:
RFC-821 (on page 22) states that unless the receiving mailer is
completely unable to process a message it should accept the message
and acknowledge any errors in processing in a separate message or
messages sent back to the originator of the message. As a result,
receiving mailers should be able to acknowledge the final dot as soon
as the message has been safely put in a non-volatile (e.g., disk)
queue for further processing. Fast acceptance of a message does not
violate RFC-821.
but this was in days were we weren't getting all the crap we get nowadays.
Is there an RFC that says that you MUST or SHOULD acknowledge DATA within
X seconds?
That RFC says:
Finally, some mailers allow remote mailers only a minute or two to
acknowledge the final dot before timing out and trying again. Given the
increasing round-trip times on the Internet, and that some processing after
the final dot is required, the timeout for reply to the final dot should
probably be at least 5 minutes and a timeout of 10 minutes would not be
unreasonable.
I know I'm way below one minute, so this doesn't worry me.
As for virus checking, I don't think it really belows in local_scan, this
can be very lenghty.
Checking later and bouncing it if necessary is acceptable I think
With spam, those ***holes now fake the envelope from too and set it to
stupid values like me, or some other innocent, so I *really* do not want to
have to accept the mail in the first place if I can avoid it at all.
Also, thanks to Philip adding a timeout option for local_scan, you can help
keep a runaway local_scan in check.
As for the suggestion of putting the spamc code in local_scan, I decided
against it (as explained in my comment in the code):
- the spamc/spamd protocol can change, I'd have to track it
- forking spamc takes milliseconds, running the spamd checks takes several
seconds. It seemed obvious that trying to save on the fork by making
lcoal_scan significantly more complex didn't seem worth it.
Marc
--
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page:
http://marc.merlins.org/ | Finger marc_f@??? for PGP key
