“However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”
이 댓글은 이메일을 통한 금전 이체 요청에 대한 의심이 제기될 때, 단순히 "이 이메일을 보냈느냐"고 묻는 것이 아니라, "정말로 이렇게 돈을 이체하길 원하는가"와 같이 구체적으로 물어봐야 한다는 점을 강조함. 이러한 대화를 통해 공격이 실패할 가능성이 높아질 것이라는 의견을 제시함. 또한, 기사에서 설명하는 공격 시나리오가 성공하기 위해선 매우 특정하고 좁은 상황이 필요하다고 지적하며, 이러한 복잡한 공격이 실제로 성공할 가능성에 의문을 표함.
The other day I was discussing the design for an "update" email that our designer was putting together...
이 댓글은 이메일 디자인에 대한 경험담을 공유함. 디자이너가 만든 이메일의 그래픽 헤더 때문에 제목을 보려면 스크롤을 내려야 하는 문제를 지적하고, 이메일이 포워딩될 때 모바일 버전에서 데스크톱 버전으로 변환되는 것에 대해 놀라움을 표현함. 이메일에 CSS가 사용되는 것 자체가 불필요하다고 비판하며, 마크다운과 같은 간단한 텍스트 마크업이 도입되지 않은 현 상황에 대해 불만을 표함.
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...
이 댓글은 이메일에서 HTML 대신 마크다운이나 비슷한 간단한 텍스트 마크업을 사용해야 한다고 주장함. 이렇게 하면 이메일 클라이언트가 리치 텍스트로 표시할지 일반 텍스트로 표시할지 결정하기 쉬워지며, 사용자가 필요로 하는 대부분의 포맷팅을 지원할 수 있다고 설명함. 마케팅 이메일에 사용되는 고급 HTML은 중요하지 않다는 의견을 제시함.
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...
이 댓글은 HTML 이메일을 생성하는 개발자가 아웃룩의 다른 렌더링 때문에 미쳐버릴 수 있다는 농담을 하며, 이메일을 통한 공격이 흥미롭다고 언급함.
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?
이 댓글은 이메일에서 스타일시트를 허용하지 않고 태그에 인라인 스타일 속성만 사용하는 것으로 문제를 해결할 수 있을지 제안함. 이메일 클라이언트가 스타일시트를 인라인 스타일로 자동 변환하는 단계를 포함시키면 사용성이 향상될 수 있다고 주장함.
HTML in email shouldn't be as big of a nightmare as it is.
이 댓글은 이메일에서 HTML이 큰 악몽이 되어서는 안 된다고 언급함. 모든 이메일 클라이언트가 텍스트 대 HTML을 확인하고 HTML일 경우 렌더링 엔진을 웹킷으로 전환하면 문제가 쉽게 해결될 수 있다고 주장함. 이에 대한 표준이 제안되었는지 궁금해함.
Some possible mitigations from the top of my head (maybe ineffective):
이 댓글은 이메일을 통한 공격을 완화할 수 있는 몇 가지 방법을 제시함. 숨겨진 요소에 대한 경고, 포워딩 시 메시지의 모습을 계산하여 크게 달라질 경우 확인을 요청하는 것 등이 그 예임.
When efail came out, I wrote a blogpost about the security risks of HTML mail.
이 댓글은 HTML 이메일의 보안 위험에 대해 블로그 포스트를 작성했다고 언급함. HTML 이메일 사양이 오래되었고 보안 고려 사항이 거의 없으며, 안전한 HTML 이메일은 HTML의 부분집합이어야 하지만 그 부분집합이 무엇인지 아무도 정의하지 않아 보안 결함이 끊임없이 발생한다고 지적함.
This is really clever!
이 댓글은 HTML 이메일에서 CSS를 사용하여 메시지가 포워딩된 후에만 특정 텍스트가 보이게 하는 것이 매우 영리하다고 칭찬함. 이로 인해 검증된 이메일의 신뢰성에 큰 위협이 될 수 있다고 언급함. 또한, 이메일 클라이언트가 이메일의 내용을 추가 HTML 태그로 감싸고 CSS 및 클래스 이름을 수정하는 것에 대해 궁금증을 표현함. 이메일 클라이언트가 HTML 이메일을 렌더링하기 위해 샌드박스된 iframe을 사용하지 않는 이유에 대해 의문을 제기함.
Hacker News 의견
The other day I was discussing the design for an "update" email that our designer was putting together...
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?
HTML in email shouldn't be as big of a nightmare as it is.
Some possible mitigations from the top of my head (maybe ineffective):
When efail came out, I wrote a blogpost about the security risks of HTML mail.
This is really clever!