On Wed, 2006-07-12 at 14:54 -0700, Aaron Stone wrote:
On Tue, 2006-07-11 at 15:59 +0200, Kjetil Torgrim Homme wrote:
On Tue, 2006-07-11 at 13:59 +0100, Nigel Swinson wrote:
Well our implementation doesn't provide any end user accesible
operational logs, so using fileinto seems like an excellent low cost
implementation.
what do you gain by doing reject? no spammer ever washes their lists
based on response codes, anyway. (*perhaps* after negative response to
RCPT TO, for DATA, no way.)
I'm with Nigel on this.
but you don't answer my question, what is gained by doing reject?
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. in practice, when a
user makes such a request, a lot of manual work must be done to collect
all the log excerpts, but this is mostly due to such requests being rare
(we get perhaps one or two per year here at the University of Oslo), so
it's not worth the effort to automate it.
but all this is very much beside the point.
If it can't be used to deter spammers, such is life.
so the reject is useless?
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.
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.
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.
--
Kjetil T.