fetchmail-friends
[Top] [All Lists]

Re: [fetchmail] [PATCH] unexpected behaviour with undeliverable mail

2002-09-09 03:15:13
Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com> writes:

Quoting from Matthias Andree's mail on Wed, Sep 04, 2002 at 09:44:49PM +0200:
Multidrop with wildcard can of course yield this 550 condition even
without configuration error (at least on Postfix), and some MTAs use
indeed 550 for content filter rejects as well as "no such user", so it
might be needed to add some parsing the reply message here, I'm thinking
of RFC-1893 (those codes used in Delivery Status Notifications), and/or
regexp matching (what is spam, what is not), for example.

Other possibility is to have an antispam per smtp command. For
example, 550 to MAIL FROM: should be in antispam, 550 to RCPT TO:
should not be, 550 to DATA should be.

DATA must not yield 550, but only 354, 451, 503, 554. (See
RFC-2821). After the CRLF.CRLF that follows up on the "DATA" "354" chat,
the only valid reply codes are 250, 451, 452, 552, 554. (Again, see
RFC-2821). In real life, at least Postfix will return 550 after
CRLF.CRLF if body_checks or header_checks trigger.

http://www.faqs.org/rfcs/rfc2821.html

Other possibility is to not do any antispam checks on RCPT TO:
command. I think the current antispam spam option is only meant for
response to the MAIL FROM: and DATA commands.

That won't work, because some MTAs will always and some will depending
on configuration defer ANY 4XX or 5XX reply until after RCPT TO.

The sane approach is to empty the default antispam list. Before 6.0.0 is
a good time, because people expect major changes on a 5.X -> 6.0 upgrade.

See my other mail on the versioning subject.

-- 
Matthias Andree