Still badly connected, and again apologies for the delay...
I take the freedom to reorder the snippets of text below:
On Mon 26/Aug/2013 15:08:05 +0200 Jan Ingvoldstad wrote:
>
> I'll stop rambling now, because I think I'm way off topic.
Many Courier users are mailbox providers, hence discussing that role
should be on topic, even if it is not specifically about Courier
software. There are lists which are more specifically devoted to email
administration, e.g. Spammers.DontLike.Us (SDLU), but this subject may
appear to be overworked in such places. Discussing it here has the
potential to bring fresher perspectives.
> On Mon, Aug 26, 2013 at 2:43 PM, Alessandro Vesely <ves...@tana.it> wrote:
>> On Mon 26/Aug/2013 10:00:52 +0200 Jan Ingvoldstad wrote:
>>> It is also quite sensible that e-mail is handled as close to the point of
>>> origin as possible.
>>
>> According to what topology?
>
> The ISP would probably know their network topology, or be severely
> incompetent.
A network topology, in the sense of a set of nodes and edges, looks
different depending on the protocol: The route traced for IP packets
differs from the SMTP hops reported via "Received:" header fields.
Topological properties such as administrative boundaries vary accordingly.
I mentioned "horrible digressions" like TOR just to prove how such
differences can affect network usage. Botnets are another example.
>>> External SMTP services should preferably be used when roaming (in
>>> a broader sense than mobile phone roaming), since it has a pretty
>>> high risk of reducing reliability and performance.
>>
>> Yes. Some user just use occasional ISPs for setting up a VPN to
>> their office.
>
> And then, presumably, that office has either an internal SMTP server,
> or an SMTP server with the office's ISP, or the office's ISP provides
> a smarthost.
IMHO, each company, school, club, and large family would deserve to run
their own mail servers. Nowadays, however, too much insight is required
for doing so, possibly due to the fact that mail filtering is not a
fully understood, standardized task.
>>> Ideally, there would be decent mechanisms in place, but there are
>>> not, and things like SPF and DKIM regrettably do not matter at
>>> all in anti-spam measures – lots of the spam I see at work pass
>>> SPF and DKIM validation.
>>
>> True, more work is needed in order to use authentication
>> effectively.
>
> That is an understatement.
>
> Authentication works today by effectively ignoring the difference between
> authentication and authorization. A user is assumed to be authenticated and
> authorized by the same criteria.
No, a user is authenticated through SMTP AUTH. Individual relay
authorization can be determined after that. _Domain authentication_,
which is what SPF, DKIM, and even DNSWL can provide, is only meant to
identify who is responsible for relaying an authenticated message.
Now, that's the point where the difference between kinds of provider
enters the game. Without authentication, the IP address of the relay is
the only meaningful place to report abuse to. Authentication is not
(yet?) widespread enough to sustain an established practice of abuse
reporting, except for specific cases of feedback loops (FBL) between
huge mailbox providers and relevant mail service providers (a.k.a. gray
spammers, for some relatively light shade of gray.) Although it is
nearly a decade, perhaps email authentication is still too young.
Otherwise, it's dead already :-/
IP addresses used to be more reliable than domain names because it is
more difficult for a spammer to change the former than the latter. IPv6
seems to be going to alter that assumption. IME, I received a few
reports from FBLs (some tests and a couple of false positives) but never
got a complaint relayed by my upstream ISP.
> The ISP can selectively block services. For instance, Telenor would
> block most services except web and POP for users who have had
> severely compromised computers/networks, and also provide written
> notification about the block and reasons for it. Business customers
> may be handled differently, depending on the problem.
I agree that ISPs can be more effective than MBPs against compromised
computers, viruses, and similar threats. However, ISPs proved to be
unable to manage mail relay control so as to prevent abuse.
> And yes, for the cases where people hide behind NAT, that will effect
> the entire block.
>
> However, this is what I would consider an "incentive" for the one
> essentially providing hosting services to others, to get their house
> in order. When you choose to be an ISP middle man for other people,
> you must also be prepared to take the problems that come with it. If
> you hide your "customers" from your ISP by using NAT, this is not the
> ISP's problem. It is your own problem.
I'd imagine a mail domain MTA, rather than a NAT, for the role of "ISP
middle man": Many plug&play devices deploy NAT without requiring their
operators to be even aware of what is going on.
To get its house in order, a mailbox provider needs to know how many
messages its users send, how many are reported as spam, and how many
actually are spam, me think. In addition, since email addresses are the
most widely used means of identification, mailbox providers could
provide a tighter control than ISPs.
Transferring relay control from ISPs to MBPs, IMHO, is what email
authentication is all about. Despite the possible advantages it may
bring, it doesn't seem to be going to happen very soon, though.
> [...] and probably won't even after Microsoft has world domination.
^^^^^^^^^ You mean Google?
--
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
