Sending files
Share files up to 5 GB each with people outside the company, by expiring link.
A member sends confidential files to people outside the company by creating a transfer. Nothing reaches a recipient until every file has passed a malware scan and the company's data loss prevention (DLP) rules allow it.
Creating a transfer
In the web app or through the API, the member sets:
- Files: 1 to 50.
- Recipients: 1 to 50 email addresses. Listing the same address twice is rejected.
- Expiry: between 1 hour and 30 days, capped by the tenant's longest allowed expiry. The default is 7 days, or the tenant's maximum if that is shorter.
- Message: optional. It is encrypted at rest and never appears in an email.
- Download limit: optional, 1 to 100 downloads per recipient per file.
- First-download notice: optional. The member is emailed when the transfer is first downloaded.
Tenant policy can list allowed and blocked recipient domains. They are checked when the transfer is created and again when it is sent, so a policy change in between still applies.
Limits
| Limit | Value |
|---|---|
| Files per transfer | 1 to 50 |
| Size per file | 5 GB |
| Size per transfer | 20 GB |
| Recipients per transfer | 1 to 50 |
| Expiry | 1 hour to 30 days, capped by tenant policy |
| Download limit | 1 to 100 per recipient per file, or none |
Uploading
Files go straight from the browser to encrypted storage in parallel parts. The API never carries the bytes, but it decides every state change. After an interruption, the web app asks which parts already arrived and sends only the missing ones.
The service then assembles the file and checks its size against the declared size; a mismatch rejects it. Completion runs on the server and re-checks the transfer, so a transfer cancelled or revoked mid-upload never gains a new file.
What happens after upload
When the member presses send, the expiry clock starts. Each file is then scanned for malware and inspected for sensitive data in a single pass over its contents.
- Malware scan. Files up to 2 GB are scanned by ClamAV; larger files by GuardDuty Malware Protection for S3. An infected file is quarantined and can never be downloaded by anyone. A file the scanner can't look inside, such as a password-protected archive, is blocked unless tenant policy allows it. A scan that keeps failing leaves the file blocked and alerts an operator. See Malware scanning.
- DLP inspection. Built-in detectors look for data such as My Numbers, card numbers and cloud credentials, plus the tenant's own keywords and patterns. Counts add up across all of a transfer's files, so splitting data doesn't avoid a rule. See Data loss prevention.
- Decision. Once every file is shareable, the tenant's DLP policy decides. When several rules match, the strictest action wins.
| DLP outcome | What happens |
|---|---|
| Allow and record | The transfer is sent. |
| Warn | The sender sees each matched rule and the findings per file, then confirms, removes files or cancels. Only a person signed in to the web app can confirm; an API key can't. |
| Require approval | The sender requests approval with a business justification. A named approver who isn't the sender approves, or rejects with a comment. An approval request expires after the tenant's timeout (72 hours by default). |
| Block | The transfer is held. |
Findings show the detector, the count, where in the file (such as sheet and row) and a masked preview. They never hold the matched value.
When a transfer is held
If a file is blocked, or a DLP rule blocks the transfer, or an approver rejects it, the transfer is held. No recipient is notified. The member sees which file failed or which rule matched, and why. They can remove that file and send the rest, or cancel the transfer.
The email and what the recipient sees
Each recipient gets their own email with their own link, from a fixed template in English or Japanese. It names the tenant and the sender's verified address, with Reply-To set to the sender. It carries no file names, no message text and no sizes, and its only link points to the service's web app, so a mail server that reads it learns nothing about what is shared.
The recipient then:
- Opens the link. The page shows that verification is needed, and nothing about the files.
- Requests a one-time code, which goes only to the invited address.
- Enters the code. This opens a verified session in that browser.
- Sees the transfer's shareable files and the sender's message.
- Downloads the files one by one. There is no zip of several files. An interrupted download of a large file resumes without counting against the download limit.
If tenant policy allows unscannable files, anyone downloading one sees a warning first. A forwarded link or a forwarded download address gives the next person nothing. See Recipient verification.
Tracking and notifications
The member sees each recipient's status: whether the email went out (queued, sent, bounced or suppressed), whether they verified, and which files they downloaded and when.
The member is told when:
- a transfer is held, or needs their confirmation;
- an approval request expires without a decision, so they can ask again (up to 3 requests per transfer);
- a recipient is locked out after too many wrong codes;
- the transfer is first downloaded, if they asked for that notice.
The member can extend an active transfer's expiry, but never past 30 days, or the tenant's maximum, from when they pressed send. The member, or any tenant admin, can revoke it at any time. See Revocation and retention.
Source: PRD, Architecture, Data model, Abuse and rate limits