Re: [9fans] vf is a neat idea but

[W B Hacker <wbh@conducive.org>]

ron minnich wrote:
> Image you are on a mac os system which uses a plan 9 machine -- e.g.
> mine -- as a mailer. You attach some pictures to the mail message you
> are writing using the macos mailer and send the message out from the
> mac mailer.

Having access to a similar setup, I cannot begin to fathom why I would involve a
Plan9 machine in an smtp transaction when the OS X box has such a wide selection
of MUA (and MTA if need be...)

...but let's take a look at 'why so...'

>
> In return, you get back this message (I am not making this up)(names
> removed to protect innocent):
> error+  from 'xxx@xxx.org'
> error+ to 'abc@gmail.com'
> 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 'x!y 'net!$smtp'' returned error
> status 72.
> error+
> error+
>

OK.  Coming not from a Plan9 viewpoint, but rather smtp in general, most
recently Exim in particular...

The 'responding' Plan9 box that composed that bounce is not even remotely smtp
compliant 'de jure', though it may be 100% smtp functional 'de facto'.

The giveaway is that the mandated numerical codes are missing, i.e. 'error' in
the case above should be, for example '550 - <some optional text string>'

>
> OK, this does indeed beg some questions for an average person, who has
> just received this  bounce. As in , uh, w.t.f is all this. So I
> translate what I can.
>
> This is not from gmail.com. This is from the Plan 9 machine.
> The failure to create the tmp file does not mean that you are out of
> space, or that there is some other file system error. It means that
> some piece of software does not like you.

OK - *even if* the mandated codes appeared, they only specify, for example,
temporary or permanent failure. The least one should see folloing the number
code is in the nature of 'Administrative Prohibition' (an Exim default message).

Any more specific detail is entirely up to the configuration of the 'rejecting'
MTA, and even then only IF they choose to be specific.

Many do not, hoping to give spammers less to go on in seeking ways around
restrictions. Said MTA may or may not even log more fine-grain details for its
own use.

Extracts from one of those our servers generate, for example:

# DATA_12_SCAN_2B: IF MIME containers hold 'definite' wormish file extensions,
# THEN deny.
#
discard
     message = Dangerous Win-Crobe carrier ".$found_extension" attachment.
     demime  = bat:btm:cmd:com:cpl:dll:exe:jsp:prf:scr:vbs:wmf
     log_message = D12S2B Denied for unwanted file extent ".$found_extension"

NB: The list of extensions has been cut by half for illustration.

Exim will insert a '550 -' prior to the above 'message = ' text string, ex:

550 - Dangerous Win-Crobe carrier .exe attachment.

> rc is not refusing the mail.
> It is a 4 attachment note, but we're not about to tell you which
> attachment failed; that's your problem buddy!

ACK - and it will remain so, unless you have access to the MTA's logs.
Note the '.$found_extension' which will be logged.

EVEN SO - only the first extension, which 'triggers' the acl to reject will make
it into the log. Any others - good before or bad after - are 'no longer care'.

Further analysis would require deferring the actual rejection until EACH
attachment had been compared, meanwhile concatenating a string to eventually
write to the log AND a 'demerit score' to make a final pass/fail call.

We do both of those for some other things - but not for this purpose.

> And no, we're not going to tell you which particular attachment *type*
> we decided was executable -- again, in spite of the fact that you may
> not be able to see that at your end,

MTA 'capabilities' quite aside - that is quite standard.

Think 'why help a spammer find a hole?', eg: some MTA will say as part of the
rejection to go away and return with the file(s) as '.zip' attachments.

We do that too - but only if the sender is another corporate branch office of
the recipient, as we may not pass a .zip *either* unless from a trusted source.

> you're just going to have to bring another rock.
> And, in spite of the fact that we are Plan 9, and we have errstr,
> we're going to return error 72. Good luck.
>

Well, don't blame Plan9. This one is 'environmental'.

> So, I am going to start digging at this vf thing, because (at least to
> me) this is poor etiquette.
>
> Anyone who is faster than me at figuring this stuff out (which seems
> to be most of you :-) let me know when you fix it.
>
> thanks
>
> ron
>

Dunno if I am 'faster'.  But do have a very long 'head start'.

;-)


By and large, because of the open warfare w/r spam, you don't (fix it).

Closest you can come is to inquire of whomever controls configuration and logs
of the rejecting MTA - Plan9 or otherwise.

Anticipating the next point - there is almost certainly NO Plan9 MTA
implementation 'in use' even remotely as detailed or configurable as
out-of-the-box Exim w/r granularity of choices, logging, messages.

Same again w/r MUA choices. These just have not been primary focus for Plan9.

Not that there could not be.
Anyone wanting to invest the time can make Plan9 'tell all', I am sure.

There just doesn't seem to be a need to make that investment.

Less effort to utilize Exim, Postfix, or Courier-MTA, partly because at *some*
point you will probably have to traffic with their ilk anyway - so why re0invent
  that wheel?

I am not, for example 'happy' with being advised to VNC to a non Plan9 box to
use (GUI tool of choice). Bit like hiring a taxi when you own several cars.

But am *quite* happy to leave all smtp processing to a non Plan9 box, just as I
buy my tires from Michelin.


YMMV,

Bill Hacker