LISTSERV crapness

[fanf]

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.

Comments

[drplokta]

SHOULD is not MUST. Null return paths are not forbidden, just disrecommended.

[fanf]

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.

[drplokta]

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.

[bellinghman.livejournal.com]

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

[vatine]

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 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.

[fanf]

Exactly :-)

Error Messages and Resolutions

[(Anonymous)]

I am looking for an updated list of the most common error messages and suggested resolutions to correct those while building email content. Our company uses the tool in our editor and we came across a new error message we had not seen before. Any help would be appreciated.

Re: Error Messages and Resolutions

[fanf]

There is an infinite variety of email error messages, since they aren't standardized in any useful manner, and most software makes it easy to customize them.

A good starting point is to look at Mailman's bounce message handling code.