Bagaimana cara menentukan batas ukuran lampiran yang masuk akal?


13

Saya akan akui ini adalah area di mana saya akan memberikannya 10-20mb dan membuang "email tidak ditujukan untuk transfer file" setiap kali pengguna mengeluh harus menggunakan FTP.

Tapi mengkilap mail server baru layak pendekatan rasional ... jadi apa adalah metode non-voodoo untuk menentukan batas yang sesuai untuk ukuran lampiran?

(Ragu-ragu apakah ini adalah wiki, atau jika ada metode yang Just That Good.)

Saya pikir akan ada beberapa pedoman yang baik yang tidak tergantung pada lingkungan, tetapi spesifik diperlukan - jadi 50 kotak surat, tukar 2007, AD, perangkat keras adalah TBD. Klien adalah campuran 2007/2003, saya pikir saya akan mengatur dikirim / diterima untuk mencocokkan, hanya untuk menjaga hal-hal sederhana.



Doh! Terima kasih untuk tautannya. Keterampilan pencarian saya mengecewakan saya di sana.
Kara Marfia

Nol sepertinya batas yang sangat masuk akal bagi saya.
Tom O'Connor

Jawaban:


18

"Email tidak dimaksudkan untuk transfer file!"

Dalam semua keseriusan, saya menetapkan milik saya di 10MB, lebih tinggi dan Anda mungkin mendapatkan penolakan dari server SMTP jauh. Jika perusahaan / klien Anda menggunakan banyak file yang lebih besar, saya mungkin yakin untuk mengaturnya pada 15 atau 20MB tetapi tidak lebih tinggi dari itu.

Saya menginstruksikan klien untuk menggunakan layanan seperti Dropbox jika mengirim file yang lebih besar. [Pengungkapan, itulah tautan referensi saya!]


Poin baiknya, saya tidak memikirkan fakta bahwa peningkatan batas meningkatkan bounceback yang akan mereka dapatkan dari server mail lain.
Kara Marfia

1
+1 Untuk "Email tidak dimaksudkan untuk transfer file!".
Lankymart

9

Batas itu sendiri agak kurang penting daripada menyediakan alternatif yang konsisten, aman dan mudah digunakan bagi pengguna yang perlu mengirim dan menerima file yang lebih besar.


2

Ini secara langsung tergantung pada bisnis Anda.

Saya memiliki pengguna yang secara rutin mendapatkan file dalam kisaran 40MB, dan kadang-kadang jauh di atas itu. Saya pada dasarnya menetapkan ukuran tidak terbatas untuk alasan itu.

Lihatlah lampiran sah Anda, ambil ukuran rata-rata dan gandakan, lalu lihat lampiran sah terbesar yang Anda terima. Jika lebih besar dari dua kali lipat rata-rata, maka buatlah 50% lebih besar dari yang terbesar sejauh ini.


3
Tentu, dan saya memiliki pengguna yang secara teratur mencoba mendapatkan lampiran yang sah 300MB. Konten tersebut sah? Tetapi ukurannya tidak sah untuk transfer email.
d -_- b

2

Perusahaan 10 MB! Kecuali untuk eksekutif yang terbuka lebar. Kami bosan dikutuk!


Sedih tapi benar! Pembatasan kotak masuk juga keluar jendela di sana.
Kara Marfia

1

Saya di kamp "10 MB dan itu milik Anda". Bukan hanya apa yang dapat Anda kirim tetapi juga apa yang dapat diterima oleh orang yang Anda kirim. Kecuali jika bisnis Anda beroperasi di daerah di mana mengirim binari yang sangat besar melalui email adalah norma maka mengapa lebih tinggi?

Selain itu, Anda perlu memastikan Anda menawarkan alternatif bagi orang-orang yang benar-benar perlu mengirim file yang lebih besar, apakah itu seperti Dropbox, server FTP kuno yang baik, atau yang lainnya pintar (Kami memiliki server dan kapasitas bandwidth untuk menawarkan layanan kami sendiri mirip dengan dropbox kepada pengguna kami, seperti yang terjadi).


1

Saya cenderung sedikit lebih tinggi, dan merangkak naik di 30MB. Ini akan bervariasi dari bisnis ke bisnis. Sebagai alternatif untuk lampiran file, coba senduit .


Hei, antarmuka itu sangat sederhana, bahkan pelanggan kami tidak dapat mengacaukannya ...
Kara Marfia

1

Apa pun ukurannya, pastikan untuk menjaga batas masuk melebihi batas keluar . Server dapat dan akan memantulkan email Anda dengan mengirimkannya kembali (semuanya) jika ada kesalahan terkait-ukuran (salah alamat atau lebih), dan bahkan jika itu hanya akan menambahkan beberapa byte Anda tidak ingin menolak surat itu berdasarkan ukuran.

Juga beberapa "klien email" (Saya menggunakan istilah ini dengan hati-hati) membuat balasan ke email dengan lampiran dengan menambahkan lampiran yang sama. Anda juga tidak ingin memantulkan email-email itu, sebodoh perilaku ini.

Untungnya ada MTA yang bagus (bukan Exchange, tetapi sebagai contoh postfix adalah satu) yang memungkinkan Anda untuk membatasi bouncing ke ukuran yang jauh lebih rendah daripada surat asli. Sehingga kasus pertama mungkin menurun karena fitur ini akan diadopsi bahkan oleh MTA braindead.

Lagi pula, pilihan ukuran sangat tergantung pada siapa Anda sebagian besar berkomunikasi dengan dan apa batas mereka. Dalam bisnis grafis, ukuran maksimum megabita tiga digit bukanlah hal yang tidak pernah terdengar, di bisnis lain (saya ingin mengatakan akademisi, tetapi zaman telah berubah, sayangnya) Anda bahkan bisa pergi dengan memberi tahu orang-orang bahwa lampiran adalah praktik yang buruk untuk memulai. Saya tahu saya melakukannya, tapi itu sepuluh tahun yang lalu :(


1

10MB di sini juga. Tampaknya menjadi standar yang diterima. Saya memiliki pelanggan yang mengeluh tentang hal itu (khususnya sekelompok arsitek yang secara konsisten menggunakan "gambar CAD besar" sebagai alasan untuk mengesampingkan kuota atau batas apa pun) tetapi yang diperlukan hanyalah menunjukkan kepada mereka bahwa (1) email dibagikan layanan, dan karena itu kegiatan mereka mungkin berdampak pada ketersediaan untuk orang lain, dan (2) mereka harus bermain baik dengan penerima.

Untuk apa pun yang melebihi batas itu, ada banyak pengaturan alternatif yang tersedia, sehingga semua orang bisa tetap bahagia.


1

Kami menetapkan batas kami untuk apa pun batas Gmail. Kami terkenal tuli terhadap permohonan para ilmuwan tertentu di tengah-tengah kami yang ingin mengirim email set data besar bolak-balik dengan sesama peneliti. Inilah sebabnya mengapa kami masih memiliki server surat departemen, dan server Exchange yang mendukung 4000-pengguna aneh dan toko surat di bawah 1TB.


1

Pada tingkat PC individu, semua peningkatan luar biasa dalam kecepatan dan kapasitas perangkat keras telah memberi orang perasaan yang menyimpang dari apa yang masuk akal. PC dan laptop cepat dengan hard drive 500GB + membuat berurusan dengan foto 5MB dari kamera digital, film, dokumen dengan banyak gambar yang dimasukkan, dll., Tidak masalah.

Kemudian mereka ingin mengirim mereka melalui kabel ... Ya, itu berfungsi banyak waktu untuk mengirim 20MB, 50MB, bahkan lampiran yang lebih besar. Tetapi ketika terjadi kesalahan, itu mengacaukan segalanya dengan cara yang jauh lebih besar. Ada file yang lebih besar dalam antrian, mungkin biaya bandwidth Anda naik, kira-kira seperti itu.

Bagaimanapun, itu semua merupakan awal dari apa yang kami lakukan: menarik 20MB dari udara dan berkata "itu saja." Cukup besar sehingga kita bisa menghubungkannya dengan koneksi 100MBPS kami dan mencoba memberi mereka gambaran tentang apa yang akan terjadi jika 50 orang mencoba mengirim file ukuran yang sama sekaligus.


1

Untuk memenuhi batas 5 MB atau 10 yang ditentukan pada beberapa server Perpesanan pribadi (Exchange, Qmail ...), ada solusi profesional yang mengatasi ukuran dan jenis file yang ingin Anda kirim. Solusinya juga memberikan penelusuran dan keamanan yang kuat yang tidak menawarkan FTP (kata sandi dan nama pengguna dengan jelas ...). Juga tersedia di lingkungan seluler (iPhone, Windows phone 7 / mobile, Blackberry, ...)

2 teknologi tersedia:

Solusi mode platform:

http://www.edipoles.com/index.php?id_page=36&openPanel=1

Solusi dalam plugin Outlook:

http://www.edipoles.com/index.php?id_page=30&openPanel=1


0

Berapa banyak pengguna? IMAP? POP3?

Saya tidak peduli dengan apa pun di atas 10, seperti yang Anda katakan, ini bukan layanan transfer file.


0

Mengirim atau menerima lampiran email? Apakah organisasi Anda menggunakan MS Exchange / MS Office Outlook / Active Directory / SharePoint? Jika demikian, versi apa? Ini topik yang rumit.



0

Ketika dunia berkembang, demikian juga kebijakan. Dengan peningkatan terbaru kami ke Exchange 2010, kami telah meningkatkan batas kirim / terima hingga 25 MB (batas Gmail). Dengan perluasan layanan email yang dihosting Gmail Anda hanya akan mengalami masalah dengan batas bawah. Jika ruang penyimpanan bukan masalah (mengingat disk lebih kecil, lebih cepat, dan lebih murah) daripada mengapa tidak?

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.