Log in

No account? Create an account


LISTSERV crapness

« previous entry | next entry »
8th Apr 2009 | 13:08

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 |

Comments {8}

Dr Plokta

from: drplokta
date: 8th Apr 2009 13:30 (UTC)

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

Reply | Thread

Tony Finch

from: fanf
date: 8th Apr 2009 13:39 (UTC)

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 01:49 pm (UTC)

Reply | Parent | Thread

Dr Plokta

from: drplokta
date: 8th Apr 2009 13:51 (UTC)

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

The Bellinghman

from: bellinghman
date: 8th Apr 2009 15:09 (UTC)

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


Reply | Parent | Thread

Just a random swede

from: vatine
date: 8th Apr 2009 14:17 (UTC)

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.

Reply | Parent | Thread

Tony Finch

from: fanf
date: 8th Apr 2009 14:41 (UTC)

Exactly :-)

Reply | Parent | Thread

Error Messages and Resolutions

from: anonymous
date: 23rd Feb 2011 13:28 (UTC)

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.

Reply | Thread

Tony Finch

Re: Error Messages and Resolutions

from: fanf
date: 23rd Feb 2011 13:36 (UTC)

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.

Reply | Parent | Thread