Re: Submission identifiers
2009-01-26 21:54:11
On Jan 26, 2009, at 6:25 PM, David MacQuigg wrote:
At 09:50 AM 1/26/2009 +0000, Paul Smith wrote:
I have a 'common' situation in mind. Whether you like it or not, it
is
common enough.
There is a small business who has bought Microsoft SBS. They are
running
Microsoft Exchange with the POP3 connector over a dynamic IP ADSL.
They
have Exchange set up for direct sending, with fallback to their ISP's
smarthost. They don't want to change to always use their ISP's
smarthost
because that has long delays in sending.
What are they supposed to use for the EHLO parameter if it is
important
enough to mean the difference between delivery or not?
This is a good case. I think we can include Steve's example as a
sub-case, since he has a static IP address from his ISP.
The solutions in this case include the three suggested for the
roaming laptop, plus another option. Get a static IP address from
your ISP. In my office I have a small network behind a NAT with one
external address. My ISP charges $10 per month for the static IP.
Last I checked, the phone company price was the same.
By the way, I don't use my static IP for sending mail. For reliable
delivery, I relay my outgoing mail through a Giant Provider, not
because of authentication problems, but simply that my domain is too
small to have any clout with receivers. I spent several hours
negotiating with just one Giant Provider to get on their whitelist.
The change I am suggesting will make it easier for small companies
to establish their identity, build a good reputation, and operate
their own transmitters. That may be one reason we haven't seen a
solution to the identity fraud problem. The Giant Providers like
the status quo.
I guess this discussion has about run its course, so I'll
summarize. We've narrowed the question to just whether SMTP should
drop the requirement that receivers MUST NOT reject apparently
forged helonames. The suggested language for a change was:
An SMTP server MAY reject a mail session if a domain name argument in
the EHLO command does not actually correspond to the IP address of
the
client. Clients that are unable to establish this correspondence
MUST
NOT provide an invalid domain name argument.
The claimed benefit was that a currently useless and frequently
abused parameter, the heloname, could then become useful in
rejecting forgeries, and that would motivate legitimate senders to
take it seriously. This in turn could lead to large numbers of
receivers making good use of the heloname, whitelisting legitimate
domains, etc. Eventually almost all legitimate mail would go this
route, and only a small fraction would have to go through a spam
filter, reducing losses, and improving the reliability of email
communications.
I'm coming in a little late, so feel free to ignore the next three
paragraphs if they've already been covered.
If the requirement for mail to bypass restrictions is that the HELO
matches (by some metric) the reverse DNS of the IP address, and the
only value of enforcing this rule is so that you can gather reputation
based on this string, why not just use reputation based on the reverse
DNS of the SMTP peer?
If the hope is that bad email will be sent from source addresses where
the HELO string and IP don't match and good email will be sent from
sources where the HELO string and IP do match that shows an awful lot
of optimism about legitimate senders and a big underestimate of non
legitimate senders.
Even SPF seems to have a more compelling value proposition.
The claimed reason for not making this change was that it would be
too hard on some small fraction of legitimate senders. Three cases
were presented.
1) The small office with a dynamically-assigned IP address.
2) The roaming laptop.
3) The digital camera.
4) MTAs that are smarthosts for a number of domains, and which use
(for reasons that their vendors and users consider quite important)
the domain name of the authenticated sender or the SMTP FROM as the
HELO string. (That I think this behavior is... silly... doesn't mean
it's not desired behavior by the users.)
The solutions considered too difficult were:
1) Get a static IP address for the transmitter in the small office.
2) Relay through a transmitter with an established identity and
reputation.
3) Authorize the entire block of addresses that might be dynamically
assigned to the transmitter.
4) Use an address literal, meaning - please accept this session
without a HELO ID.
Cheers,
Steve
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: RFC 5321bis / 2821ter, (continued)
- Re: RFC 5321bis / 2821ter, John C Klensin
- Re: RFC 5321bis / 2821ter, Mark Andrews
- Re: Submission identifiers, David MacQuigg
- Re: Submission identifiers,
Steve Atkins <=
- Re: Submission identifiers, John C Klensin
- Re: Submission identifiers, Paul Smith
- Re: Submission identifiers, John Leslie
- Submission identifiers (was: Re: RFC 5321bis / 2821ter), John C Klensin
- Re: Submission identifiers, Alessandro Vesely
- Re: Submission identifiers, John C Klensin
- Re: Submission identifiers, David MacQuigg
- Re: Submission identifiers, SM
- Re: Submission identifiers, Arnt Gulbrandsen
- Re: Submission identifiers, Alessandro Vesely
|
|
|