DC> those are not mail protocols.
MR> True, but they are "other methods which a mobile user may use to send
MR> mail."
DC> no they are not.
DC>
DC> in some cases, they are other methods for running smtp, besides using a
DC> raw tcp/ip channel.
DC>
DC> but they ultimately either use smtp or they are not for email.
DC> please let's try not to introduce "let's invent new and special ways for
DC> individual sites to do special things." non-standardized methods do not
DC> scale to the rest of the Internet.
1. They solve the problem you raised, namely that mobile users may not be
able to reach port 25 on their organization's outbound mail servers
because of firewall or other restrictions. Or was that not your
objection?
2. They are neither special nor non-standard; using email through one's
internal network via VPN (to draw just one of the examples I provided)
is quite common on the Internet nowadays. I'm not sure what you mean
by "does not scale to the rest of the Internet".
We seem to be degenerating into semantics here. Yes, the connections are
SMTP (which is good and standard), or whatever else the sender wishes, and
they may be tunneled.
DC> you have not addressed the minor problem that failure to find an rmx
DC> record has ambiguous meaning. hence it is not at all clear what the
DC> benefit is when you DO find the entry.
Please see below.
SN> If the RMX matches the IP, it's a good bet the domain is not forged.
SN> If the RMX doesn't match, all bets are off.
MR> One more case here--if RMX is present and doesn't match, the message is
MR> definitely forged (or the system is misconfigured).
DC> You are quite wrong. When you do not find a matching rmx record, the
DC> only thing you know is that there is no rmx record. There are at least
DC> two different reasons possible. forgery is only one of them.
Ah, I think I see the confusion:
1. RMX record present + received IP address matches
--> email is not a forgery
2. RMX record present + received IP address does not match
--> email is a forgery
(or sender's mail system is misconfigured)
3. RMX record not present
--> email is either a forgery or not a forgery; no
information. This is the way all email works now.
4. Unable to contact the sender's nameserver
--> up to the recipient; possibly hold the message in
quarantine until the nameserver comes back online,
or forward it with a warning.
In every case, the RMX check provides information that can be passed on to
intelligent spam filters to help them make better decisions.
You may object that case (#3) does not really provide any information.
Right now, and that's true, but as RMX becomes more common, absence of an
RMX record will become a gradually stronger indicator of spam.
So far as I can tell, the system does perform its intended job, which is
to give senders a way to allow their recipients to distinguish between
forged and non-forged mail. Spammers could still send spam, but would be
unable to represent the spam as having come from an RMX-protected domain.
Is that clearer?
Best regards,
Mike
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg