일반적으로 이메일은 @ 오른쪽에 도메인 이름이 있으므로 조직이나 회사를 식별 할 수 있습니다. 이 도메인은 실제로 이름 서버에 의해 확인되는 IP 주소의 “이름”또는 “별칭”이외의 다른 것입니다.
POST와 GET에 비해 “다 대일”또는 “일대 다”와 같이 더 많은 가능성이 있기 때문에 이것이 사물 인터넷에 사용될 수 있다고 생각합니다.
예를 들어 user@xxx.xxx.xx.xxx와 같이 IP 주소와 직접 이메일을주고받을 수있는 방법이 있습니까?
답변
전자 메일의 경우 도메인은 단순히 IP 주소의 별칭 또는 사람이 읽을 수있는 형식이 아닙니다. 메일 교환기 MX 레코드는받는 사람의 도메인을 대신하여 전자 메일 메시지를 수락하는 메일 서버를 지정하기 위해 존재합니다. 도메인의 메일을 수락하는 서버가 여러 대있을 수 있으며 반드시 A도메인 레코드 에있는 동일한 IP에있는 것은 아닙니다 . 메일 시스템에는 여러 서버가있을 수 있습니다. 수신 서버는 발신 서버 및 메일 스토리지 서버 등으로부터 분리 될 수 있습니다. A레코드는 MX호스트 이름에 지정된 레코드 가 없을 때만 사용됩니다 .
그러나 전자 메일 주소 형식에는 전자 메일을 직접 <user@hostname.example.com>또는 직접 보낼 수없는 (기타 <user@[198.51.100.10]>괄호가있는 IP ) 제한이 없습니다 . 일반 호스트 이름 또는 IP 주소를 사용하여 전자 메일을 수락하는 메일 서버가있는 경우 그렇게합니다. 그러나 당신이 제안하는 것은 실제로 전 세계적으로 작동하지 않습니다.
- 대부분의 전자 메일 시스템에는 여러 도메인이 있으며 전자 메일을 모두 별도로 처리해야합니다. 사용자 이름 자체가
<user@example.com>다른 사람 일 수 있으므로 실제 사서함에 바인딩되지 않았을 수 있습니다.<user@example.net> - 이것이 수십 년 전에 일반적인 일 이었지만 스팸과의 싸움으로 인해 문제가 더욱 복잡해졌으며 전자 메일을받는 데에는 제한이있었습니다.
- SMTP 포트 사용은
25남용 (스팸봇)으로 인해 소비자 등급 인터넷 연결에서 매우 제한됩니다. IoT 장치에 실제로 SMTP를 많이 사용하지는 않습니다.
답변
많은 SMTP 서버 (예 : sendmail)는 user@[aaa.bbb.ccc.ddd]이메일 주소를 처리 하지만
- 일부 SMTP 서버는 해당 서버를 처리 / 인식하지 못합니다.
발신자 주소 수락을 거부하거나 해당 주소로 전송할 수 없습니다. - 이러한 주소는 일부 스팸 방지 소프트웨어에 문제를 일으킬 수 있습니다
… 또한, 상기 도메인 @ [192.168.2.1을 이러한 jsmith와 같은 대괄호 []로 둘러싸인 IP 주소 리터럴이거나 jsmith에있다 @ [IPv6를 2001 : DB8 : 1] 이 거의 제외 보이지 않지만 이메일 스팸 . …
답변
모든 관련 당사자가 실제로 최신 소프트웨어를 사용하는 경우 작동합니다.
SMTP는 TCP에서 계층이 잘 작동하지만 TCP / IP의 프로토콜 BASED가 아닌 최소한 원래 형식입니다. 원래 RFC 821을 보면 부록에 “TCP 전송”이 정의되어 있습니다.
RFC 2821 (1989 년부터)은 숫자 주소 “감지 된”사용을 고려합니다.
훨씬 더 현대적인 사양의 사양은 RFC5321에서 철학을 어느 정도까지 유지합니다. “SMTP는 특정 전송 서브 시스템과 독립적이며 신뢰할 수있는 순서화 된 데이터 스트림 채널 만 필요합니다.이 문서에서는 TCP를 통한 전송에 대해 구체적으로 설명하지만 다른 전송도 가능합니다. RFC 821 부록 [1]에 그 중 일부가 설명되어 있습니다. “
그러나 2008 년부터 실제로 매우 새로운 RFC는 “주소 리터럴”을 “허용됨”으로 사용하도록 제재합니다 ( “이 장벽을 우회하기 위해 도메인의 대안으로 주소의 특수한 리터럴 형식이 허용됩니다” 섹션 4.1.3의 “이름.”)에도 불구하고 2.1.4의 “SHOULD NOT”으로 권장하지 않습니다.
“주소 리터럴”을 “호스트”로 사용할 수있는 경우 SMTP와 그 주위에 구축 된 많은 소프트웨어 에서 “주소”가 아닌 ip 주소가 아닌 호스트를 사용 합니다 . 그리고 SMTP 기반 시스템과 함께 오래된 전자 메일 에코 시스템에서 사용 된 (대부분 낡은) 비 SMTP 프로토콜 (예 : UUCP 메일)도 마찬가지입니다.
2008 년 표준을 완전히 준수하는 모든 관련 시스템에 의존하는 것이 생각보다 위험 할 수 있습니다.