Skip to main content
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

SMTP and email are very old Internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb; it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.

SMTP and email are very old Internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb; it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.

SMTP and email are very old Internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb; it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.

Copy edited.
Source Link
Peter Mortensen
  • 12.2k
  • 23
  • 72
  • 90

SMTP and email are very old internetInternet services from an era when security and authentication were taken much less seriously (DNS is another example). TheThe design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. TheThe SMTP protocol is relatively dumb,dumb; it provides a facility to transmit plaintext to an email address and very little more. TheThe structure of this plaintext is defined by RFC 5322RFC 5322. TheThe general idea is that the email text has metadata called a header, and the actual text body of the message. ThisThis email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. DiggingDigging deeper, you would find that this scam email has no DKIM signature.

SMTP and email are very old internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb, it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.

SMTP and email are very old Internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb; it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.

Source Link

SMTP and email are very old internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb, it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.