ietf-mta-filters
[Top] [All Lists]

Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)

2006-07-18 09:23:09

On Thu, 2006-07-13 at 22:52 +0200, Kjetil Torgrim Homme wrote:

but you don't answer my question, what is gained by doing reject?

If, as you claim, spammers don't wash their lists based on SMTP
rejections (really!?) then perhaps what's needed, for those looking at
this as a portion of an overall anti-spam policy, is a hook to some
lower-level defense measures, such as OpenBSD's spamd proxy, which
monkeys with protocol timings to muck up the spammer's outbound system. 

But this is a reaction to a truly hostile Internet, not the happy go
lucky friendly Internet that email was first designed for :-\

I would never make mail logs available to an end
user -- they are there for the system administrator to monitor the
health of the system, for compliance with company policy (e.g. the
company prohibits excessive personal use of its email system) and laws
(e.g. US federal requirements that banks log all email).

in many (most?) European countries, the user is entitled to seeing _any_
logs and database entries pertaining to him/her.
[snip]

I am not aware of such laws in the US. (hmm. grumble.)

If it can't be used to deter spammers, such is life.

so the reject is useless?

I thought that quite a few good reasons for reject were already given.
Is this even a topic that's still at-issue?

RFC 2821, section 4.2.5:

   When an SMTP server returns a permanent error status (5yz) code after
   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
   any subsequent attempt to deliver that message. 

I don't think that's open to interpretation.

The spec was written for a less hostile environment. In the case of the
US federal law above, even spam would probably have to be logged.

according to Norwegian law, official contact addresses in the public
service can NOT be filtered automatically, every inquiry must be judged
on its own merits by a human.  however, our mail system doesn't lie and
say that it was rejected.  it would be a bizarre if the applicant got a
rejection message and his missive still ended up in the archive for
posterity.  such archival without his knowledge could very well be in
breach of the transparancy laws.

Interesting.

I
could easily see an issue coming to course and requiring some evidence
that an email was not received because it was caught by a spam filter.
So even an email rejected with a 5yz code would still need to be logged.
Is that a form of delivery?

it's a delivery if the message itself is stored.

Fair enough; there'd be an SMTP log that a message of some kind was
rejected, though not the text of the message itself. So it covers half
of the base that I'm positing -- maybe well enough not to worry.

It is different if the system does it vs.
the user doing it? Does this script undermine email in some evil way:

    fileinto "Rejected Mail";
    reject "I think not.";

it might.  did you never see a fetchmail going bananas?  this is just
the sort of thing which can confuse such software -- and it's entitled
to.

I dunno. But have you ever seen/heard ESR himself going bananas? ;-)

Aaron

<Prev in Thread] Current Thread [Next in Thread>