আইনসম্মত কারণে এসএমটিপি "মেইল থেকে:" ডেটাতে "থেকে:" শিরোনামের সাথে মেলে না


18

মেলিং তালিকাগুলি ছাড়াও কোনও বার্তার ডেটা বিভাগে "থেকে:" ফিল্ডের সাথে এসএমটিপি "মেল থেকে:" ক্ষেত্রটি মেলে না এমন কি কোনও যুক্তিসঙ্গত কারণ আছে?

Https://stackoverflow.com/questions/1750194/smtp-why-does-email-needs-envelope- এবং- কি- does- the- en گمেফ থেকে শুরু করুন :

“তবে, আপনার শামুক মেইল ​​রূপকটি চালিয়ে যেতে, বেশিরভাগ পেশাদার অক্ষরে চিঠিতে প্রেরক এবং প্রাপকের ঠিকানা থাকবে। এই ঠিকানাগুলি পোস্টম্যানের জন্য প্রয়োজনীয় নয়, পরিবর্তে প্রাপকের কাছে সৌজন্যমূলক। সুতরাং এটি বোধগম্য যে ইমেলটি একইভাবে কাজ করবে। "

এই যুক্তিযুক্ত লাইনটির সমস্যা এখানে রয়েছে: "প্রাপকের প্রতি সৌজন্য"। এসএমটিপি এর মাধ্যমে একটি ইমেলটিতে "থেকে:" ঠিকানাটি অন্তর্ভুক্ত করা সৌজন্য নয়; যদি প্রাপক একটি উত্তর পাঠাতে সক্ষম হয় তবে এটি প্রয়োজনীয়।

থেকে: পোস্ট ফিক্সে মেইল ​​থেকে মেলানো থেকে হেডারকে কীভাবে সীমাবদ্ধ করবেন? :

"তবে আপনি যদি সত্যিই: এবং মেল থেকে मेलটি নিশ্চিত করতে চান তবে আপনাকে হেডার_চেকগুলি প্রয়োগ করতে হবে যাতে ফেরার পথ: এর থেকে মেলে:"

এটি করার প্রভাব কি? মেলিং তালিকাগুলি অবশ্যই সমস্যা হবে। "মেল থেকে:" এবং "থেকে:" শিরোনামের তথ্যের সাথে পৃথক হওয়ার অন্য কোনও বৈধ ব্যবহার রয়েছে কি?

উত্তর:


22

ঠিকানাগুলি থেকে শিরোলেখ এবং খামটি মেলে না যাওয়ার অনেক কারণ রয়েছে। সর্বাধিক উদ্বেগ মেল প্রেরণে স্বয়ংক্রিয় প্রক্রিয়াগুলি যেখানে ডেলিভারি সমস্যাগুলি এমন কোনও ঠিকানায় রিপোর্ট করা দরকার যা মেলটি কে প্রেরণ করেছে, বা কে এটির পক্ষ থেকে প্রেরিত হয়েছিল, বা কাকে উত্তর দেওয়া উচিত তার প্রতিনিধি নয়। আপনি যেভাবে মেইলিং তালিকাটি উল্লেখ করেছেন সেগুলি একটি ভাল উদাহরণ।

কোনও ব্যবহারকারীর মেইল ​​ক্লায়েন্টের কাছ থেকে পাঠানো বার্তা ঠিকানা থেকে আলাদা হতে পারে তার প্রধান কারণ ফরোয়ার্ড মেল। মেল সামগ্রীটি তখন মূলটির সাথে যুক্তিসঙ্গতভাবে বিশ্বস্ত হওয়া উচিত, তবে বিতরণ ত্রুটির ক্ষেত্রে সেগুলি ইমেলটি ফরোয়ার্ডকারীকে নয়, মূল প্রেরককে নয়।

এসএমটিপি শিরোনাম ছাড়াও, বিভিন্ন মিমি শিরোনাম রয়েছে যা বিভিন্ন প্রোগ্রামগুলি মূল প্রেরক এবং মধ্যবর্তী প্রেরক এবং / অথবা ত্রুটির প্রতিবেদন করার জন্য পছন্দসই ঠিকানাটির মধ্যে পার্থক্য করার চেষ্টা করে useএই উত্তর করুন, প্রেরক, মূল-থেকে , ত্রুটিগুলি, ইত্যাদি ইত্যাদি, প্রতিটি আলাদা শব্দার্থবিজ্ঞান সহ। এর মধ্যে কয়েকটিতে স্ট্যান্ডার্ড সাপোর্ট রয়েছে, যদিও আরও অনেকগুলি তা করে না, তবে যে কোনও উপায়ে ব্যবহার হতে পারে। বিভিন্ন মেল প্রোগ্রাম অনুশীলনে যেভাবে আচরণ করে তা যথেষ্ট পরিবর্তিত হয়।

কোনও মেইল ​​সম্বোধন করার পরামর্শ দেওয়া উচিত কিনা আপনি যেমন জিজ্ঞাসা করেছেন এটি "বৈধ" কিনা তা থেকে আলাদা বিষয়। আপনি যদি এখানে বৈধতার জন্য সম্ভাব্য স্প্যাম পরিচালনা করার মতো নীতি সম্পর্কিত কিছু বিবেচনা করছেন, তবে না, আমি মনে করি না আপনি এইভাবে কোনও সাধারণ পার্থক্য করতে সক্ষম হবেন।

ইমেল স্বাক্ষর করার বিষয়ে ডি কেআইএম এবং ইমেল ডোমেনগুলির জন্য মেল সার্ভারের এসপিএফ অনুমোদনের বিষয়ে চিন্তাভাবনা করুন। আপনি যদি অনেক বেশি মেল প্রেরণ করেন তবে এই পদ্ধতিতে আপনার মেলটি প্রমাণীকরণে সক্ষম হওয়া জরুরী হতে পারে এবং এতে শিরোনাম থেকে মেইল ​​ঠিকানা দেওয়ার ক্ষেত্রেও জড়িত থাকতে পারে, যেহেতু আপনি কেবলমাত্র এমন ডোমেন সম্পর্কিত মেলকে অনুমোদন করতে পারেন যার জন্য আপনার কর্তৃত্ব রয়েছে ।

-

অনুরোধে প্রসারিত:

একটি মাইম 'রিপ্লাই-টু' শিরোনাম একটি এমইউএকে নির্দেশ দেয় (মেল ব্যবহারকারী এজেন্ট, সাধারণত কোনও ব্যক্তির মেল ক্লায়েন্ট) মাইম 'থেকে' ঠিকানার পরিবর্তে আলাদা ঠিকানায় উত্তরগুলি প্রেরণ করে। এটি এমটিএ (মেল ট্রান্সপোর্ট এজেন্ট) ত্রুটির মতো জিনিসের জন্য ব্যবহার করে না।

সাধারণত কোনও এমটিএ ত্রুটি প্রেরণের জন্য এসএমটিপি খামটি 'মেল থেকে' ঠিকানা ব্যবহার করে would এটি একটি এমআইএমএম 'ত্রুটি-টু' শিরোনামের সাহায্যে ওভাররাইড করা যেতে পারে, যা একটি এমটিএ নির্দেশিকা। সমস্ত এমটিএগুলি এটি সম্মান করবে না, সুতরাং এটি এসএমটিপি খামের ঠিকানা নির্ধারণের জন্য একটি নিকৃষ্ট প্রক্রিয়া, তবে এমন অনেকগুলি পরিস্থিতি রয়েছে যেখানে ম্যাসেজে এমআইএমআই হেডারগুলি সেট করা সম্ভব হতে পারে তবে এসএমটিপি খাম থেকে ঠিকানাটি নয়। যেমন ভাগ করা হোস্টিংয়ের পরিবেশে চলমান সফ্টওয়্যার নিজেকে এই পরিস্থিতিতে দেখতে পারে।

সফটওয়্যার এজেন্টদের নির্দেশ হিসাবে 'প্রেরক' অনেকটা অস্পষ্ট, তবে কে বা কী ইমেলটি পাঠিয়েছে যেখানে সেই ঠিকানাটি থেকে আলাদা যেখানে এটি মেইলটি কার পক্ষে প্রেরণ করা হয়েছিল তার চেয়ে বেশি। যেমন আপনি যখন কোনও অন-লাইন মেইল-আপনার রাজনীতিবিদ ফর্মটি পূরণ করেন, ফলস্বরূপ ইমেলটি আপনার মেইলটি ফ্রি হেডারটিতে ব্যবহার করা খুব উপযুক্ত হবে তবে ফর্মটি সেটআপকারী সংস্থার সাথে প্রেরকের ঠিকানা থাকতে হবে।

'ওরিজিনালি-ফ্রম' মেল ফরোয়ার্ড করার সময় কিছু এমইউ সফটওয়্যার দ্বারা ব্যবহৃত হয়, ফরোয়ার্ডারের ঠিকানাটি 'থেকে' শিরোলেখের জন্য ব্যবহৃত হয়। অন্যান্য এমইউএগুলি থেকে ঠিকানাটি একা ছেড়ে যাবে এবং একটি 'রিসেণ্ট-ফ্রি' শিরোনাম ব্যবহার করবে। এমইউএগুলি এই বিভিন্ন শিরোনামের ইমেলগুলি উদ্ধার করে কিনা শিরোনামকে দরকারীভাবে ব্যাখ্যা করে, বা এমনকি প্রদর্শন করে তা যথেষ্ট পরিবর্তনশীল Whether আপনার কাছে ফরোয়ার্ড করা মেলটির জবাব দেওয়ার সময়, উত্তরটি ডিফল্টর কাছে কার কাছে যাওয়া উচিত? 'রিপ্লাই-টু' শিরোনামটি সেট করা ভাল?

MUAs এর আচরণ পরিবর্তনশীল, এবং খারাপভাবে সংজ্ঞায়িত করা হয়েছে, যদিও এটি সময়ের সাথে উন্নতি হতে পারে বলে মনে হয়। বিপরীতে, খামের শব্দার্থবিজ্ঞান অনেক বেশি সংজ্ঞায়িত হয়। সাধারণত একটি দৃ position় অবস্থান ছিল যে এমটিএগুলিকে কখনই এমআইএমআই হেডারের সাথে নিজেকে উদ্বেগ করা উচিত নয়, তবে এমটিএগুলিকে ক্রমবর্ধমান মেল সামগ্রীর জন্য দায়ী করা হয় (যেমন এসপিএফ এবং উদীয়মান ডিএমআরসি মানদণ্ড দেখুন), সেই অবস্থানটির স্বচ্ছতা হ্রাস করার চাপ রয়েছে। ত্রুটি-টু-র মতো দীর্ঘস্থায়ী প্রক্রিয়াগুলি এমটিএগুলিকে শিরোলেখের বিষয়বস্তু না দেখানোর ধারণার সাথেও দ্বন্দ্ব পোষণ করে which এই প্রক্রিয়াটি কেন সবসময় বেমানানভাবে প্রয়োগ করা হয়েছিল তারই একটি অংশ। সফ্টওয়্যার লেখকদের দর্শন পৃথক হয়।

আপনি http://tools.ietf.org/html/rfc4021#section-2 সন্ধান করতে দরকারী হতে পারেন , তবে মনে রাখবেন যে মেল সফ্টওয়্যারের প্রচুর সংখ্যার আসল অনুশীলনগুলি বিভিন্নভাবে পরিবর্তিত হয় যা অগত্যা মানকীয় নয়।

আপনার মেলটি কীভাবে ব্যবহার করা উচিত সে সম্পর্কে একটি স্পষ্ট দর্শন নিয়ে আসার চেষ্টা করার পক্ষে এটি ঠিক আছে, তবে আশা করবেন না যে আপনারা কীভাবে ভাবেন সেগুলি প্রত্যেকেরই কাজ করবে।


আমার এই অনুগ্রহটি পুরষ্কার দেওয়ার এখনও সময় আছে এবং অতিরিক্ত পরিস্থিতিগুলির মধ্যে আগ্রহী যেমন শিরোনামগুলির ব্যবহারের প্রয়োজন হবে: ly উত্তর দিন, প্রেরণকারী, মূল-থেকে, ত্রুটি-টু
গুডগুইস_অ্যাক্টিভেট

সংযোজনের জন্য আপনাকে ধন্যবাদ। আমি আশা করছি যে এমটিএ প্রত্যাশিত আচরণগুলি কী কী সেগুলি কীভাবে বাস্তবায়ন করা হয় তার একটি পরিষ্কার বোঝার প্রত্যাশা করছি। এছাড়াও, আপনি এই প্রশ্নটির প্রতি আগ্রহী হতে পারেন: আমি স্রেস্ট.স্ট্যাকএক্সচেঞ্জে ইমেল শ্বেত তালিকা (বিএটিভি সদৃশ) সুরক্ষা
396

1
+1, কেন কেবল 4 ভোট?
পেসারিয়ার

11

স্বয়ংক্রিয় প্রক্রিয়াজাতকরণ একটি বড় কারণ। আপনি আলাদাভাবে প্রক্রিয়াজাতকরণের জন্য যে কোনও বাউন্স / অটোরপ্লাই / ত্রুটিগুলি প্রেরণ করতে সক্ষম হতে চান, অন্যথায় এই বার্তাগুলি অদৃশ্য হয়ে যায় বা অগ্রাহ্য হয়, বা কিছু দুর্বল সেপগুলি সেগুলির মধ্য দিয়ে যেতে হয়। হ্যাঁ, প্রক্রিয়াকরণের জন্য একটি এক্স-শিরোলেখ যোগ করা সম্ভব তবে অনেক সময় বাউন্স / ইত্যাদি। আসল ইমেল বা এটির একটি ম্যাংল্ড অংশ অন্তর্ভুক্ত করবে না এবং আপনি উত্সটি পেতে সক্ষম হবেন না।

উদাহরণস্বরূপ, বলুন যে কেউ আপনার ওয়েবসাইটে সাইন আপ করে এবং আপনি সাইন আপ করার জন্য ধন্যবাদ জানিয়ে তাদের একটি ইমেল প্রেরণ করেন। আপনার মাইলফ্রোম এবং এর থেকে হতে পারে:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

এইভাবে, ব্যবহারকারী মেল ক্লায়েন্টে "বন্ধুত্বপূর্ণ" থেকে দেখেন। তবে ব্যবহারকারীর অস্তিত্ব না থাকলে তাদের এমটিএ বাউন্স বার্তা প্রেরণ করবে:

user-signup-123123123@bounces.example.com

এবং একটি স্বয়ংক্রিয় প্রক্রিয়া সহজেই ইউজারিড (123123123 অংশ) এবং সিস্টেমের সেই অংশটি টানতে পারে যা শিরোনাম থেকে বাউন্স (-সাইনআপ-অংশ) তৈরি করে এবং সহজেই সেই ব্যবহারকারীকে অক্ষম হিসাবে চিহ্নিত / চিহ্নিত করতে পারে।


8

থেকে প্রাপ্ত মেল: এসএমটিপি কথোপকথনে সেই জায়গাটি তৈরি করা হয়েছে যেখানে বাউন্সগুলি যেখান থেকে যাবে: বার্তাটির শিরোনামের শিরোনামটি প্রাপকের কাছে প্রদর্শিত হবে এবং উত্তর-হিসাবে: উত্তরটি শিরোনামটি সেট না করা থাকলে address

ইমেলগুলি যা কোনও বাউন্স তৈরি করে না সেগুলি খামে খালি প্রেরক সেট করা উচিত, উদাহরণস্বরূপ একটি রিটার্নের প্রাপ্তি সাধারণত থাকে: mail from:<>এতে থেকে: হেডারটিতে ব্যবহারকারীর নাম থাকে।

আর একটি পরিস্থিতি হ'ল কোনও মেল সার্ভার নকল বাউন্সগুলি প্রত্যাখ্যান করতে BATV ব্যবহার করছে। থেকে প্রাপ্ত মেলটি prvs=tag-value=mailbox@example.com আকারে থাকবে।


আমি মনে করি রিটার্ন এবং এনডিআরগুলির জন্য একটি এক্স-শিরোনাম দেখেছি। আপনি কখন জানেন এবং কখন এটি ব্যবহার করা হয়?
গুডগুইস_অ্যাক্টিভেট

এক্স-শিরোলেখগুলি প্রথমে কাস্টম মেটাডেটা স্থাপনের জন্য এমইউএ এবং / অথবা এমটিএগুলির একটি মাধ্যম হিসাবে যুক্ত হয়েছিল এবং কোনও মানগুলিতে নির্দিষ্ট করা হয় না, যদিও কিছু ডিফেক্টো স্ট্যান্ডার্ড হয়ে যায়। আপনি আরএফসি 6522 এ সংজ্ঞায়িত মাল্টিপার্ট / রিপোর্ট মাইম টাইপের কথা ভাবছেন যা স্বয়ংক্রিয়ভাবে বাউন্স হওয়া বার্তাগুলিকে শ্রেণিবদ্ধকরণে সহায়তা করার জন্য সংজ্ঞায়িত হয়েছিল। এগুলি মেল থেকে একটি খালি খামের সাথে এখনও পাঠানো হবে:
রিচার্ড সল্টস

1

আমি যদি আমার শিরোনাম বা প্রশ্নটি সঠিকভাবে না পড়ি তবে আমার ব্ল্যাকবেরি থেকে ইমেলগুলি ব্ল্যাকবেরি সার্ভার থেকে প্রেরণ করা হয় এবং মূলত কোনও ফিল্ডের সাথে মেলে না। ব্যবহারকারীদের ছোট শতাংশ, আমি বুঝতে পারি। আমি সম্প্রতি আমার মেল সার্ভারটি মূল্যায়নের দিকে এটি দেখছি। নীচে আমার ব্ল্যাকবেরি থেকে আমার জিমেইল অ্যাকাউন্টে একটি অনামী ইমেল প্রেরণ করা হয়েছে:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

এর একটি দুর্দান্ত কারণ রয়েছে - এসপিএফ পুনর্নির্মাণ । ব্ল্যাকবেরি যদি এটি না করে থাকে তবে আপনি আপনার ডিভাইস থেকে প্রেরণে অনেক বেশি এসপিএফ ব্যর্থতা পাবেন।
মিকিবিবি

সত্য, তবে এটি কারণ যে ব্ল্যাকবেরি আমার সার্ভারটি প্রেরণের জন্য ব্যবহার করে না।
পল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.