Tony Finch - LISTSERV crapness

dotat[info]fanf wrote
on 8th April 2009 at 13:08
Previous Entry Add to Memories Tell a Friend Next Entry

LISTSERV crapness

LISTSERV uses a null return path (RFC821 MAIL FROM:<>) on its administrative mail, and some mail hosts reject this. I discard message with a null return path that do not match a few simple heuristics, so I lose things like subscription confirmations from services like JISCfail. This makes me cross.

L-Soft claim that LISTSERV is following the specifications, and they cite a couple of paragraphs from RFC 821 (published in 1982) and RFC 1123 (1989). However they fail to cite text from RFC 2821 (2001) which explicitly forbids what they are doing.

There are several types of notification messages which are required by existing and proposed standards to be sent with a null reverse path, namely non-delivery notifications, other kinds of Delivery Status Notifications (DSNs), and also Message Disposition Notifications (MDNs). [...]

All other types of messages (i.e., any message which is not required by a standards-track RFC to have a null reverse-path) SHOULD be sent with with a valid, non-null reverse-path.

The only other permitted use of null return paths that I know of is vacation notifications, described in RFC 3834 (published in 2004).

L-Soft needs to get a grip, read some RFCS, and fix their software.

(Leave a comment)
From:[info]drplokta
Date:2009-04-08 13:30 (UTC)
(Link)
SHOULD is not MUST. Null return paths are not forbidden, just disrecommended.
(Reply) (Thread)
From:[info]fanf
Date:2009-04-08 13:39 (UTC)
(Link)
SHOULD is much stronger than that, in particular it is a warning that violating the requirement is likely to cause interoperability problems and thus eliminating many of the benefits of following the specification. In this particular case, the problem of their messages being rejected or lost is exactly caused by them failing to adhere to this requirement: it is their fault not the filter's fault.

Edited at 2009-04-08 13:49 (UTC)
(Reply) (Parent) (Thread)
From:[info]drplokta
Date:2009-04-08 13:51 (UTC)
(Link)
I wouldn't argue with that, but you still can't tell L-Soft that the RFC forbids it, merely that it warns that it may cause problems.
(Reply) (Parent) (Thread)
From:[info]bellinghman
Date:2009-04-08 15:09 (UTC)
(Link)
Dear L-Soft

My mail server rejects messages that don't fully comply with RFC821, but your software generates such messages.

I'm not receiving my messages.

Your software is faulty.

No love

Me
(Reply) (Parent) (Thread)
From:[info]vatine
Date:2009-04-08 14:17 (UTC)
(Link)
From RFC 2119:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.


I think that indicates (as [info]fanf writes) that it's not just "not recommended" but "don't do that, then" (as in 'when I whack my head with a mallet, it hurts'). Referencing RFC 821 and saying "but it says it's OK" is bordering on clining to obsolete standards.
(Reply) (Parent) (Thread)
From:[info]fanf
Date:2009-04-08 14:41 (UTC)
(Link)
Exactly :-)
(Reply) (Parent) (Thread)
(Leave a comment)
Powered by LiveJournal.com