2821 HELO/EHLO domain
2821 MAIL FROM
2822 From:
2822 Sender:
New structure/RR's in .arpa *
I will avoid the debate on whether these should be called 'identities',
I don't think that matters at all. We are simply discussing the use of
particular types of info that should be indicative of origin. To
go further is to get engaged in unnecessary debates on semiotics.
The issues raised have been discussed extensively in the philosophy
litterature, if anyone wants to consider these issues in 'greater
depth', 'consider the fundamental issues' etc I suggest they read
Habermass, Pierce and Sebok on the subject.
I believe that there are roles for each of these as follows:
First let us define the term 'consistent value' to mean that
the domain component of an address either has no corresponding
profile record or if one exists it is consistent with the profile
record.
2821 HELO/EHLO domain
Setting this to a consistent value is not difficult.
There is no reason that email senders should not be required
to always return a consistent value.
In many cases a mail server is configured to serve more than
one domain. This means that the resolution available
is less than would be required for some purposes.
The DNS address of the mail server is likely to be the the
address of the server rather than the message domain.
2821 MAIL FROM
This value is empty <> for bounce messages.
If this value is defined, it should be consistent for direct
sent mail.
If a mail forwarder uses the original From value, this
value will be inconsistent.
If a mail forwarder uses the Sender value a consistent value
can be provided.
There is no reason that email senders should not be required
to always return a consistent value.
I believe that we should consider these 'identities' as a pair. It
is not always possible to rely on FROM, the value returned in HELO
is tied to the server itself rather than the message.
2822 From:
This value is presented to the user by most MUAs, it is thus
the only value that is usefull to prevent impersonation
spam.
This value will not be consistent if the sender uses a direct
connection to the destination MTA to send the mail, this
is however a distinctly minority configuration which in
any case is problematic due to port 25 blocking.
This value will not be consistent if the mail has been forwarded,
but in this case Sender should be set.
2822 Sender:
The main importance of this field is that it tells you to
expect RFC 822 validation to fail.
The sender can be validated to assist anti-phishing
New structure/RR's in .arpa *
There is some work that can be done here, but it is NOT MTA
authorization, it is providing information to receivers but the
context is completely different, as are the configuration issues.
I would strongly recommend that any use of reverse DNS be
addressed in a separate document, there is no reason to join
the use of this identity to the other four.
We also ask that participants consider and list the following
ramifications regarding deployment issues:
1) Amount of change in software components (MDA, MTA, MUA,
DNS servers,
DNS resolvers).
2) Configuration complexity.
3) Current use cases that will no longer be viable.
4) Needed infrastructure changes.
5) Considerations for use in both IPv4 and IPv6.
All options may require MTAs to change. In general the biggest
changes are required by forwarders. This is hardly surprising.
Mail senders can and should be required to provide consistent
values for BOTH 2821 HELO and 2821 From.
Mail senders may in some cases want to retain the traditional
ability to send mail direct from a mail client. Allowing this
configuration significantly limits the types of authentication
that can be performed and it should be depricated. Even so
support for legacy configurations via a flag is desirable.
Mail forwarders should be given explicit instructions for a
configuration that allows the fact that forwarding has taken
place to be determined and to authenticate the forwarder.