도메인 대신 IP 주소에서 이메일을주고받을 수 있습니까?

일반적으로 이메일은 @ 오른쪽에 도메인 이름이 있으므로 조직이나 회사를 식별 할 수 있습니다. 이 도메인은 실제로 이름 서버에 의해 확인되는 IP 주소의 "이름"또는 "별칭"이외의 다른 것입니다.

POST와 GET에 비해 "다 대일"또는 "일대 다"와 같이 더 많은 가능성이 있기 때문에 이것이 사물 인터넷에 사용될 수 있다고 생각합니다.

예를 들어 user@xxx.xxx.xx.xxx와 같이 IP 주소와 직접 이메일을주고받을 수있는 방법이 있습니까?

email smtp email-server

— 피터 모텐슨
소스

따로 : HTTP가 IoT에 너무 제한적이라고 생각되면 MQTT 또는 XMPP를 살펴보십시오.

— Roger Lipscombe

도메인은 'IP 주소의 이름'이상입니다. 도메인은 메일 서비스에 대한 (DNS 항목을 통해) 훨씬 더 많은 정보를 게시 할 수 있으며, 여기에는 여러 메일 서버의 여러 IP 주소가 포함될 수 있습니다 (예 :로드 밸런싱 또는 폴백 목적).

— jjmontes

전자 메일은 일대일이 아니고 일대일이며 서버가 메시지를 여러 사람에게 전파 할 수 있습니다. 서버에 http 게시물을 작성한 다음 많은 클라이언트가 이메일과 동일한 모델로 해당 서버를 읽도록 할 수 있습니다.

— djsmiley2k-CoW

네트워크 고고학을 정기적으로 수행해야하는 사람은 IP를 하드 코딩하지 마십시오. DNS는 어렵지 않으며 dnsmasq 와 같은 DNS 서버 는 가벼우면서 호스트 재정의를 허용합니다. 인터넷 IP는 시간이 지남에 따라 변경됩니다.

— Criggie

도메인은 IP 주소의 별칭이 아닙니다. 특히 이메일에는 도메인 이름이 우선 순위와 호스트 이름 (이메일이 전달 될)을 모두 포함하는 하나 이상의 튜플에 매핑되는 MX 레코드가 있습니다. 이름 지정 (보낸 사람)과 주소 지정 (보낼 곳)의 두 가지 개념을 혼합하고 있습니다.

— Patrick Mevzek

답변:

전자 메일의 경우 도메인은 단순히 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를 많이 사용하지는 않습니다.

— 에사 조키 넨
소스

그러나 도메인 (또는 IP) 메일에 대한 MX dns 레코드가없는 경우 전자 메일 주소 (호스트 이름 또는 IP 주소)의 도메인 부분이 배달되거나 배달을 시도합니다. 그리고 수신 서버는 해당 호스트 이름 / IP 주소의 메일을 처리하도록 구성되어야합니다.

— ivanivan

그것은 수있는 호스트의 메일을 처리합니다. 전 세계의 모든 서버가 메일을 전혀 처리하지는 않습니다. 대부분의 유닉스 / 리눅스 기반 서버에는 내부 메일 (크론 등)을 처리 할 수있는 SMTP 서버가 있지만 그 기능 없이도 제대로 작동 할 수 있습니다.

— Esa Jokinen

Esa-MX 레코드를 내 접미사 서버로 지정하면 SMTP 연결이 설정되지만 내 서버가 도메인의 메일을 어떤 모양이나 형태로도 처리하도록 구성되지 않아서 반송됩니다. 그러나 내 서버는 여러 특정 도메인 및 사용자에 대해 설정되며 모두 mysql 서버에서 제공됩니다. 1) 메일 서버가 실제로 메일을 보내는 IP에서 실행되고 있고 2) 메일 서버가 해당 IP 또는 특정 도메인 / 도메인 또는 임의의 도메인을 대상으로하는 메일을 수락하도록 구성되어 있습니까? 주소의 사용자 부분과 일치)

— ivanivan

많은 SMTP 서버 (예 : sendmail)는 user@[aaa.bbb.ccc.ddd]이메일 주소를 처리 하지만

일부 SMTP 서버는 해당 서버를 처리 / 인식하지 못합니다.
발신자 주소 수락을 거부하거나 해당 주소로 전송할 수 없습니다.
이러한 주소는 일부 스팸 방지 소프트웨어에 문제를 일으킬 수 있습니다

RFC-5322 : 3.4.1. 가산기 사양

Wikipedia : 이메일 주소-도메인 부분

... 또한, 상기 도메인 @ [192.168.2.1을 이러한 jsmith와 같은 대괄호 []로 둘러싸인 IP 주소 리터럴이거나 jsmith에있다 @ [IPv6를 2001 : DB8 : 1] 이 거의 제외 보이지 않지만 이메일 스팸 . …

— AnFi
소스

user@[aaa.bbb.ccc.ddd]사양에 따라 이메일 주소 가 정확하고 처리가 올바르게 정의되어 있으므로이를 처리하지 않는 서버는 기술적으로 "파손"되어 있습니다.

— Ferrybig

@Ferrybig : 거부도 기술적으로 처리되므로 사실입니다.

— Esa Jokinen

"이메일은 호스트가 아닌 특정 IP 주소로 전송되었습니다"는 "아마도 스팸"레드 플래그 범주에서 상당히 높은 순위에 있으며 많은 AVAS 소프트웨어가 자동으로 폐기하기로 결정할 수 있습니다.

— Shadur

모든 관련 당사자가 실제로 최신 소프트웨어를 사용하는 경우 작동합니다.

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 년 표준을 완전히 준수하는 모든 관련 시스템에 의존하는 것이 생각보다 위험 할 수 있습니다.

— rackandboneman
소스

RFC 5321 # 2.1.4 는 주소 리터럴을 사용하여 제재하지 않습니다. NOT NOT이라고 표시 한 다음 잘못된 섹션으로 연결해야합니다. RFC 2821은 그다지 오래되지 않았습니다. 2001 년이었습니다.

— Rup

내가 들으이 내 선 포인트 : .. 사이가 "마이크로 제재"에 대해 설명을 통합 증명 말할 것

— rackandboneman