Re: [9fans] my previous note on vf

Re: [9fans] my previous note on vf

[geoff]

We relay lots of mail here, but our configuration is customised
somewhat relative to what's on sources.

I've just pushed out changes to vf and validateattachment that should
prevent the problem Ron encountered and give better error messages if
something similar does happen.

[9fans] my previous note on vf

[ron minnich]

Well, all my unhappiness with vf still applies but is now x2.

So, the real problem with the failed mail w/pictures is this from what
I can now tell:

error+ failed with error 'error creating temporary file:
'/tmp/vf.00000037245' permission denied
error+ rc: note: mail refused: we don't accept executable attachments
error+ '.
error+ The mailer `/mail/lib/qmail 'mbgokhale.org!maya' 'net!$smtp''
returned error status 72.
error+
error+

The path is this (do a src vf):
/*
 * Run the external checker to do content-based checks.
 */
static int
runchecker(Part *p)
{
	int pid;
	char *name;
	Waitmsg *w;

	if(access("/mail/lib/validateattachment", AEXEC) < 0)
		return 0;

	name = savetmp(p);
	fprint(2, "run checker %s\n",
.
.
.

savetmp does this:
static char*
savetmp(Part *p)
{
	char buf[40], *name;
	int fd;

	strcpy(buf, "/tmp/vf.XXXXXXXXXXX");
	name = mktemp(buf);
	if((fd = create(name, OWRITE|OEXCL, 0666)) < 0){
		fprint(2, "error creating temporary file: %r\n");
		refuse();
	}

note the failure path, which is refuse, which does this:
void
refuse(void)
{
	postnote(PNGROUP, getpid(), "mail refused: we don't accept executable
attachments");
	exits("mail refused: we don't accept executable attachments");
}

In other words, the return error in this case is pretty seriously
bogus. A tmp file create fails, which translates to a 'we don't take
that attachment type'. To say the least, this leaves the poor Mac user
in the dark.

It seems the temporary file create really does fail, but the error
returned is utterly wrong: it has nothing to do with executable
attachments.

Now it seems that I've hit something I had not had to think about before.
Listen is started up in /rc/bin/cpurc. It does a becomenone(). So
where can listen
open a /tmp file? Does /usr/bootes/tmp need to be 777?
In other words, how can this script,

#!/bin/rc
#smtp serv net incalldir user

user=`{cat /dev/user}
exec upas/smtpd -n $3

running as user 'none', ever spawn a process which can open a tmp
file? Where is /tmp for none anyway?

Thanks

ron

Re: [9fans] my previous note on vf

[geoff]

/mail/tmp needs to be world-writable and setting the temp bit would be
a good idea too:

	chmod +trwx /mail/tmp

It isn't this way on sources to avoid having world-writable files in
the distribution.

The error messages about attachments that Ron saw are misleading, but
vf is being conservative and defaulting to not letting mail through
when something goes wrong.  Note too that the first error message
was right on the money:

	error+ failed with error 'error creating temporary file: '/tmp/vf.00000037245' permission denied

Since errors tend to cascade, it's usually best to fix the first
problem reported and try again.

Re: [9fans] my previous note on vf

[ron minnich]

On 6/2/07, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com> wrote:
> Note too that the first error message
> was right on the money:
>
>         error+ failed with error 'error creating temporary file: '/tmp/vf.00000037245' permission denied

but the second message was utterly misleading, and in fact contradicts
the first. I think it should not call refuse() in those cases where
the mail is not being refused, but there is an internal error.

Also, note this:
cpu% ls -ld /mail/tmp
d-rwxrwxrwx M 72110 upas upas 0 Jun  2 16:12 /mail/tmp
cpu%

So, what could be going on here? I'm still puzzled.

Comment from the user: "I think nobody really uses Plan 9 as a mail
relay and that's why we're the only ones who see this". is she wrong?
These errors I hit seem so basic, it's hard to believe nobody else
sees them *assuming other people use plan 9 as a mail relay*. But I am
sure we are not alone. Our setup at mbgokhale.org is that all mail, in
and out, is handled by Plan 9. We've seen problems that are
surprising, to say the least.

thanks

ron

Re: [9fans] my previous note on vf

[W B Hacker]

ron minnich wrote:
*snip*

> So, what could be going on here? I'm still puzzled.
>
> Comment from the user: "I think nobody really uses Plan 9 as a mail
> relay and that's why we're the only ones who see this". is she wrong?
> These errors I hit seem so basic, it's hard to believe nobody else
> sees them *assuming other people use plan 9 as a mail relay*. But I am
> sure we are not alone. Our setup at mbgokhale.org is that all mail, in
> and out, is handled by Plan 9. We've seen problems that are
> surprising, to say the least.
>
> thanks
>
> ron
>

Details my longer post, but Plan9 is not being any *more* 'obtuse' than legions
of other MTA.

Just obtuse with different semantics.  Ones not seen as often.

;-)

Bill

Re: [9fans] my previous note on vf

[Douglas A. Gwyn]

W B Hacker wrote:
> Just obtuse with different semantics.  Ones not seen as often.

No, it is an actual bug.  Instead of refuse(), a different form
of termination should be used, one that generates an accurate
diagnostic.  Or, refuse should accept an argument for the
reason: refuse("can't create temp file");
Followup-To:
Distribution:
Organization: University of Bath Computing Services, UK
Keywords:
Cc:


--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis@bath.ac.uk

Re: [9fans] my previous note on vf

[W B Hacker]

Douglas A. Gwyn wrote:
> W B Hacker wrote:
>> Just obtuse with different semantics.  Ones not seen as often.
>
> No, it is an actual bug.  Instead of refuse(), a different form
> of termination should be used, one that generates an accurate
> diagnostic.  Or, refuse should accept an argument for the
> reason: refuse("can't create temp file");
> Followup-To:
> Distribution:
> Organization: University of Bath Computing Services, UK
> Keywords:
> Cc:
>
>

The *cause* may very well be a bug. Not my area of expertise.

But quite separately, the form of presentation of the response is an smtp RFC
violation.

While the specific text is flexible, the code numbers at beginning of each line
are standard for each type of situation, not optional.

Decently laid-out listing here:

http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html

The cited RFC's spell out the 'MAY', 'SHOULD', and 'MUST' rules applicable.

Nothing prevents inventing/defining some other way of messaging - smtp is far
from the only way in use.

But that 'other way' would NOT be 'smtp', nor should a proper smtp server be
expected to interoperate with a non-standard set of codes, or absence therof.

Whatever 'fixing' is to be done should take that into account as well as sorting
the proximal cause of this specific error situation.

Bill

Re: [9fans] my previous note on vf

[erik quanstrom]

> Comment from the user: "I think nobody really uses Plan 9 as a mail
> relay and that's why we're the only ones who see this". is she wrong?
> These errors I hit seem so basic, it's hard to believe nobody else
> sees them *assuming other people use plan 9 as a mail relay*.

we use plan 9 as a mail relay.

- erik

Re: [9fans] my previous note on vf

[Steve Simon]

> Comment from the user: "I think nobody really uses Plan 9 as a mail
> relay and that's why we're the only ones who see this".

I use plan9 as an smtp relay on two servers - at home and at work.

I do disable vf however - I used it for a while (and never had the same problem
as you had) but I disabled it as when it wraps files it thought where suspicious
it tended to confuse my collegues.

I just renamed /mail/lib/validateattachment to /mail/lib/validateattachment.disabled
as I only relay messages for my self and a few trusted machines.

-Steve