Log in

No account? Create an account


Deathless prose

« previous entry | next entry »
25th Oct 2005 | 16:13

I'm preparing a document that gives advice on sending email from within Cambridge University. The aim is to correct some confusion about the difference between our message submission server and our smart host, which has not mattered much in the past but will when we disable unauthenticated access to the former. I'm also documenting the forthcoming rate limiting restrictions.

Any comments or questions are welcomed. It'll be announced properly in due course...


| Leave a comment |

Comments {13}

from: stephdairy
date: 25th Oct 2005 16:36 (UTC)

Will readers of this document necessarily know what the CUDN is?


Reply | Thread

from: mouse262
date: 25th Oct 2005 16:38 (UTC)

Nitpicking here - as gmail have changed to googlemail in the UK (at least for new users of the service) and we are in the UK should you have smtp.googlemail.com instead of smtp.gmail.com?

http://mail.google.com/support/bin/answer.py?answer=13285 - shows that they recommend this (at least for thunderbird, I haven't checked other clients).


What level of user is your document aimed at?

Reply | Thread

from: hsenag
date: 25th Oct 2005 16:49 (UTC)

Who is it aimed at? It strikes me as too long and technical for your average end-user, for example.

Reply | Thread


from: cartesiandaemon
date: 25th Oct 2005 17:00 (UTC)

I read that as "The aim is to cause some confusion about the difference between our message submission server and our smart host" :)

Perhaps include a description of what our/a smart host does, for people who don't know?

Reply | Thread

from: techiebloke
date: 25th Oct 2005 17:10 (UTC)

I concur about the style; I understood (most of) it, but my sister wouldn't.

For extra foul-and-perversity points:

ipfw add fwd message-submission-server,80 log tcp from any to message-submission-on-every-port 80 setup keep-state
ipfw add fwd message-submission-server,25 log tcp from any to message-submission-on-every-port setup keep-state

& have a small applet on the web server that probes to see which ports are visable (and with which you can starttls and get the right certificate). You could then say "roaming users should go to http://message-submission-on-every-port.camacuk/whatports.html and do what it tells them."

(I use this trick to my sshd from behind random firewalls)

Finally, a pedant point:

--- sending-from-cudn.txt.orig  2005-10-25 17:13:48.000000000 +0100
+++ sending-from-cudn.txt       2005-10-25 17:57:11.000000000 +0100
@@ -45,7 +45,7 @@
 not enforced, but we intend that insecure access will be withdrawn by
 Summer 2006. http://www.cam.ac.uk/cs/email/securehermes.html
 Hermes ensures that the authenticated sender is clearly identified in
-the message header.
+a message header.

 Users of college or department email systems

Reply | Thread


from: ewx
date: 25th Oct 2005 17:52 (UTC)

In 822-speak there is one header that consists of several header fields...

Reply | Parent | Thread

from: techiebloke
date: 25th Oct 2005 19:55 (UTC)

I think you mean 2822-speak; rfc 822 talks about "the headers".

What can I say? I'm old fashioned.

Reply | Parent | Thread


from: ewx
date: 26th Oct 2005 08:38 (UTC)

Look closer. You'll find loads of references to header fields in 822.

Reply | Parent | Thread

from: anonymous
date: 26th Oct 2005 10:04 (UTC)

RFC 822 does not speak about one header with many header fields. It always uses the term "header field" as the singular and either "header fields" or "headers" as the plural. I can find no reference to "the header" of a message, and many to the "the headers" of a message.

See, for example, the opening paragraph of section 3.1.

For the record, I think this is an amusing discussion that is irrelevant to Tony's document: "a header" rather than "the header" is a friendlier term for a document aimed at non-pedants; but if the document is aimed at those with an eye for detail then 2822 makes your position unassailable.

Reply | Parent | Thread

Tony Finch

from: fanf
date: 26th Oct 2005 20:23 (UTC)

I think your foul perversity is more effort than our users (and support staff) would be happy with. The ideal is to be able to configure the MUA once (or let it configure itself!) and have it work anywhere. Though some networks will have to be beaten over the head with best practices documents.

Regarding your pedant point, it is incorrect regardless of any 2822/822 terminological controversy. My servers record the authenticated user in two places in the message header: in the Sender: field in the usual way, and in a Received: field as a pair of the SASL mechanism and user name.

Reply | Parent | Thread

from: anonymous
date: 25th Oct 2005 17:12 (UTC)

Most people don't need to understand the difference between a message submission host and a smart host. The document should start with a page on how to configure your machine to use the submission host, and a list, with links, of the cases when this is not appropriate - bulk mailers and mail servers if I understand correctly*. The trick is to alert the people who need to care, without requring everyone to read the technical stuff in order to decide that they don't need to know.

*although I can imagine some of my users' college unix machines running enough compute and cron jobs that they might hit 60 messages in an hour
if they are unlucky.

Reply | Thread

Helen Lynn

from: claerwen
date: 25th Oct 2005 20:42 (UTC)

I would be quite happy working from that, and I understand email not much at all. It's very clear. I'm assuming it's aimed at COs; obviously most users need a different document.

Reply | Thread

Ben Harris

from: bjh21
date: 26th Oct 2005 10:15 (UTC)

However, note that because of the CUDN port 25 block, you must configure
your software to use the Internet standard message submission port
587, or the non-standard port 465 if you use Microsoft software.
I doubt that "if you use Microsoft software" is really what you mean, unless my occasional use of Solaris makes me ineligible to use port 587. Maybe "if you are using a Microsoft MUA"?

Reply | Thread