Re: Message.framework
Re: Message.framework
- Subject: Re: Message.framework
- From: Graham J Lee <email@hidden>
- Date: Tue, 29 Nov 2005 17:18:20 +0000
On 29 Nov 2005, at 16:47, Uli Kusterer wrote:
Am 29.11.2005 um 15:34 schrieb Graham J Lee:
Thanks, these and other archive searches only showed that no-one
had got further than me; i.e. it appeared that the user needed to
have at least one account in Mail.app. I've found that they at
least don't need to be physically logged in at the console which
is something...however it would be nice if the application (or
some global config like a /Network/Library, /System/Library or /
Library setting) could provide a "if there's no per-user SMTP
configuration, stick this one in your pipe and smoke it" dictionary.
That's not supported for a good reason: A server that allowed this
would essentially be an open relay. And if you don't want to use an
open relay, you'd need a real e-mail account on some server that at
least supports SMTP (usually you get POP3 for free with those, but
you don't seem to need that).
Let the person who runs the mail server decide whether to relay the
mail or not. In this case, I know what my program's up to and I know
(being postmaster@) that the mail I want to send is legitimate.
However, I would like to do so from a minimal privileges account, and
don't really want to have to set up either a home directory for that
account or a new MTA on every system where that program might run,
even ones which use my "real" mailserver (not a Mac, BTW) as a
smarthost. Anyway, it's the case that even if you *are* using
Message.framework from a logged-in account (e.g. in Mail.app), you're
still relying on the remote mail server to decide whether the From:
and To: specified in the mail are acceptable. By wanting to use a
non-human user I'm not changing that requirement.
It currently seems like there's no reliable way to do email from
headless Cocoa without (i)enabling a local smtpd [seems like a bit
of overkill and a potential security risk] (ii)having a 'real'
user set up a Mail.app account for the desired uid [see note to
(i)] (iii)opening a socket to a remote mail server and sending
data thus [so much for "simple things simple"...].
No, there's now built-in SMTP client in MacOS X right now save for
Message.framework, and Apple seems to have not made any updates to
that since it was brought over from NeXT/Rhapsody. I don't know
what you want to do in particular that you need SMTP support?
Simple mail transport ;-)
Sometimes you can have a server-side CGI on your product home page
that then uses the SMTP server there (i.e. sendmail) to actually
send the message. But this is really only safe as long as it goes
to a fixed address, because otherwise someone would fish the
script's parameters out of your app and use it to send e-mails to
other people through your script (see "open relay" above).
What are you trying to do? Would a PHP script or so help?
Again, an obvious security risk and the work involved in ensuring
that the script doesn't allow malformed input or undesirable relaying
seems much too high given that we're "supposed" to have a mail
delivery framework in the OS to avoid all of that ;-). All I want to
do is to have a tool (not an app, a tool) which is able to reliably
send mail to an arbitrary address from one of a set of addresses,
given the following conditions:
[i] the tool is definitely not running on a system with an MTA, so
needs an SMTP client (such as NSMailDelivery)
[ii] the tool may not be running as a 'real' user; examples include
root, appserver etc.
[iii] the remote MTA permits relaying from any of the set of from
addresses, and to any address (probably not UUCP ones...), from any
of the hosts which the tool might be invoked on
[iv] the from address may not be the real from address of the
invoking user
given these requirements, Message.framework seems minimally complex
in terms of API requirements, it's just that I can't see whether it
is possible to use it in a situation where conditions [i]-[iv] are
true. Currently I think not.
This isn't a "product" in the sense you appeared to use it (as in
"product home page"), it's for internal consumption. We have a
database app, and every so often want to mine it for information (or
insert info into it) then email the appropriate people with a pretty
message telling them something about the state their user is now in.
There are real reasons for wanting to use a different From: address
(e.g. an email telling all of my students that they're assigned a
computing project ought to appear to come from the head of computing,
not from the sysadmin or root or whatever) and the reasons for
wanting to use a system user rather than a 'real' user are those of
minimal impact.
Cheers,
Graham.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden