On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote:
On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote:
You're forgetting that 587 *is authenticated, always*.
I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place.
Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST.
Oops.
Does anyone bother to run an MSA on 587 and *not* require authentication?
Raises hand. Why would the requirements for authentication be different depending on the port used to connect to the MTA? No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy: - local delivery originating from a non-blacklisted or "internal/customer" address does not require authentication; - relay from "internal/customer" IP Addresses does not require authentication; - any connection from a blacklisted IP requires authentication or no mail will be accepted; - relay from "external/non-customer" IP Addresses requires authentication; Is there a valid reason why a different configuration is justified? As an aside, outbound port 25 traffic is also blocked except from the MTA.
On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote:
On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote:
You're forgetting that 587 *is authenticated, always*.
I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place.
Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST.
Oops.
Does anyone bother to run an MSA on 587 and *not* require authentication?
Raises hand.
Why would the requirements for authentication be different depending on the port used to connect to the MTA?
No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy:
- local delivery originating from a non-blacklisted or "internal/customer" address does not require authentication;
- relay from "internal/customer" IP Addresses does not require authentication;
- any connection from a blacklisted IP requires authentication or no mail will be accepted;
- relay from "external/non-customer" IP Addresses requires authentication;
Is there a valid reason why a different configuration is justified?
As an aside, outbound port 25 traffic is also blocked except from the MTA.
I'm glad someone finally posted the above. When I came 'up through the ranks' the policy could be explained simply, by separating POP3 and SMTP. The following is the users-perspective explanation I used to offer: - Mail from World to Client is checked via user/password check (POP3 in your mail client). Because its authenticated, it can be done from anywhere - subject to your ISPs policies on the subject. - Mail from Client to World is not authenticated (generally speaking) but what is checked is where you are. The rules: - Mail from ISP-IP to ISP-SMTP-SERVER is accepted regardless of destination. - Mail from anywhere else to ISP-SMTP-SERVER is accepted only if the destination is 'local' to the ISP. - There's no reason to do anything else as a general rule. Privately managed outbound mail solutions (such as a colo, or a corporate network, which subjects you to some other sort of validation before accepting your message) should be 'accountable' and in order to circumvent Port 25 blocking, should be found on other ports anyway. Port 25 traffic should be subject to the above. (I realise this doesnt account for SMTP-Auth. The reality today is that ISPs are blocking Port 25 to reduce spam from drones and that people should be prepared to work around this.) So in terms of the OP, I don't see why joe-user on a dynamic-IP home connection should need the ability to use port 25 to talk to anywhere but their local ISP SMTP server on a normal basis[1]. Theyre not doing MX lookups so theyre not going direct to remote MTAs[2]. Regardless of where they got the mail _from_, the outbound mail should be via SMTP to their local SMTP server.[3] If you separate inbound (pop3) and outbound (smtp) mail delivery in your thinking you can start to make sense of things (from a users perspective). This is always the tack i've taken when trying to educate users about why their email outbound doesn't work when theyre moving from ISP to ISP. (At which point you offer them your authenticated-another-way service, such as 587 with SMTP auth). [1] Customers with a specific need to do so should have the means to opt-out. I believe most of the ISPs in NZ who block 25-outbound from clients also offer this option. [2] Customers doing MX lookups are either drones or people with mail servers at home. The former are obviously the target of the block. The latter are likely going to be any one of: - Blocked by SORBS or similar as a dynamic IP - Running a mail server in breach of AUP - On a fixed IP and (theoretically) capable of securing their system and not being a drone or open mail relay (and being traceable via their ISP). [3] Note also [2]. Outbound mail is associated with your ISP and their SMTP service. Has nothing to do with inbound mail. Nothing. Nada. Zip. Or doesn't the rest of the world think like this? Mark. PS: It occurs to me that SPF has an influence here, if you're aggressively using it then you should also be offering alternatives to Port 25 SMTP. IMHO.
On Thu, Sep 04, 2008 at 02:01:48PM +1200, Mark Foster wrote:
So in terms of the OP, I don't see why joe-user on a dynamic-IP home connection should need the ability to use port 25 to talk to anywhere but their local ISP SMTP server on a normal basis[1].
Whats a normal basis? My Home ISP won't let me send to more than 200 (or so) email addresses per day. If I used my ISP's email system I would constantly be losing my email service due to hitting the limit. I do the field scheduling for my local town soccer league. [Never volunteer! :-) ] So when I send a few announcements out to coaches, referees and administrators, I hit that limit and get my email shutoff for two days or so. I eventually switched to MailHop at DynDNS (smtp auth) I would have used port 25 but our ISP has begun blocking outbound port 25 nationwide, due to large amount of outbound spam from their customers. :-)
Theyre not doing MX lookups so theyre not going direct to remote MTAs[2]. Regardless of where they got the mail _from_, the outbound mail should be via SMTP to their local SMTP server.[3]
If you separate inbound (pop3) and outbound (smtp) mail delivery in your thinking you can start to make sense of things (from a users perspective). This is always the tack i've taken when trying to educate users about why their email outbound doesn't work when theyre moving from ISP to ISP. (At which point you offer them your authenticated-another-way service, such as 587 with SMTP auth).
[1] Customers with a specific need to do so should have the means to opt-out. I believe most of the ISPs in NZ who block 25-outbound from clients also offer this option.
[2] Customers doing MX lookups are either drones or people with mail servers at home. The former are obviously the target of the block. The latter are likely going to be any one of:
- Blocked by SORBS or similar as a dynamic IP - Running a mail server in breach of AUP - On a fixed IP and (theoretically) capable of securing their system and not being a drone or open mail relay (and being traceable via their ISP).
[3] Note also [2]. Outbound mail is associated with your ISP and their SMTP service. Has nothing to do with inbound mail. Nothing. Nada. Zip.
Or doesn't the rest of the world think like this?
Mark.
PS: It occurs to me that SPF has an influence here, if you're aggressively using it then you should also be offering alternatives to Port 25 SMTP. IMHO.
--
On Thu, Sep 04, 2008 at 02:01:48PM +1200, Mark Foster wrote:
So in terms of the OP, I don't see why joe-user on a dynamic-IP home connection should need the ability to use port 25 to talk to anywhere but their local ISP SMTP server on a normal basis[1].
Whats a normal basis?
My Home ISP won't let me send to more than 200 (or so) email addresses per day. If I used my ISP's email system I would constantly be losing my email service due to hitting the limit.
I do the field scheduling for my local town soccer league. [Never volunteer! :-) ]
So when I send a few announcements out to coaches, referees and administrators, I hit that limit and get my email shutoff for two days or so. I eventually switched to MailHop at DynDNS (smtp auth)
I would have used port 25 but our ISP has begun blocking outbound port 25 nationwide, due to large amount of outbound spam from their customers. :-)
*rest snipped* Is the above described limitation a common occurrance in the world-at-large? I've not heard of ISPs doing number-of-recipients-per-day limitations. I've heard of them doing number-of-recipients-per-email limitations (thus limiting large cc/bcc lists) but not total number of emails. Who's to say that there arent legitimate reasons to email a large number of people - perhaps your customers?? Certainly if my own ISP did something like that, you're quite right, i'd have to find an alternative. (Or perhaps, an alternative ISP. ) (who set the limit at 200? Can you opt-out of the limit or have it upped?) Mark.
On Fri, Sep 05, 2008 at 11:33:54AM +1200, Mark Foster wrote:
Summary: Perceived limit of 200 email addresses delivered to per day *rest snipped*
Is the above described limitation a common occurrance in the world-at-large?
I've not heard of ISPs doing number-of-recipients-per-day limitations. I've heard of them doing number-of-recipients-per-email limitations (thus limiting large cc/bcc lists) but not total number of emails.
An excellent question. I was unable, as a customer, to get a direct answer to any of my queries as to what was or wasn't allowed at all, despite multiple attempts each time it happened. After the 3rd cut-off, I cut out, so to speak. :-) All my email still travels over their network, it just doesn't get routed through their SMTP servers.
Who's to say that there arent legitimate reasons to email a large number of people - perhaps your customers??
Certainly if my own ISP did something like that, you're quite right, i'd have to find an alternative. (Or perhaps, an alternative ISP. )
(who set the limit at 200? Can you opt-out of the limit or have it upped?)
Never found any way to, but that may only mean I didn't find the right magic combination. At least now I know my monthly gross transfer is limited to 250 GB (except in February when its only 228 GB... :-) ) Jeff Kinz. --
On Friday 05 September 2008 00:33:54 Mark Foster wrote:
*rest snipped*
Is the above described limitation a common occurrance in the world-at-large?
If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. Otherwise if they send all email from their users, all they've done is take the spam, and mix it in with the legitimate email, making spam filtering harder. Locally one of the big ISP insists you register all sender addresses with them, so all the spam from them has legitimate sender credentials. The problem is that by blocking port 25, you are basically then switching users to arbitrary per ISP rules for how to send email. This is probably good for ISPs (provides some sort of lock-in) but bad for their users. Whilst the antispam folk think it is a godsend because their block lists are smaller, it is relatively easy to block spewing IP addresses, and hard to filter when good and bad email is combined. Which is why they hate Google hiding the source IP address. This will continue until the real issue is addressed, which is the security of end user systems.
On Fri, 5 Sep 2008, Simon Waters wrote:
If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits.
MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits. We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, 5 Sep 2008, Mikael Abrahamsson wrote:
On Fri, 5 Sep 2008, Simon Waters wrote:
If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits.
MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits.
We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same.
Probably fair enough, if you as an ISP can get away with enforcing this sort of policy then so much the better. However relaying through your own ISPs 25/tcp should surely then make it relatively easy for noise to be tracked down and nailed at the source - by ISPs? (Do abuse@ desks investigate spam these days?)
Mark Foster <blakjak@blakjak.net> writes:
On Fri, 5 Sep 2008, Mikael Abrahamsson wrote:
We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same.
Probably fair enough, if you as an ISP can get away with enforcing this sort of policy then so much the better.
However relaying through your own ISPs 25/tcp should surely then make it relatively easy for noise to be tracked down and nailed at the source - by ISPs? (Do abuse@ desks investigate spam these days?)
As others have noted, intercepting 25 breaks SPF. It also gratuitously creates weird anomalous behaviour that is much harder for a reasonably clued person to debug than a simple blocked port, so it's more likely to buy you a help desk call (with a subtle problem that your level 1 folks probably can't get sorted anyway). Perhaps you aren't in a position where you have to care about the balance sheets, but keeping the load off the help desk is a wonderful thing to do in terms of cost control. Doing traffic analysis looking for noise is just extra work for your abuse people - when I was setting policy for this sort of thing we put a cap at 1000 discrete destinations per day per authenticated user (with a daily report of who'd busted it, and most days the report was 0) and only once ran into a problem where someone was legitimately trying to send mail to a bajillion people and called the help desk. -r
On Fri, Sep 05, 2008 at 10:35:15AM +0200, Mikael Abrahamsson wrote:
On Fri, 5 Sep 2008, Simon Waters wrote:
If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits.
MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits.
Just FYI- the ISP has the same 220 email address limit even when I send thru port 587, authenticated. (its comcast)
We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same.
-- Mikael Abrahamsson email: swmike@swm.pp.se
--
If you leave port 587 un-authenticated then spammers just need to move their spambots to try port 587 *and* you're never sure who sent the message. If you're going to have the customer click a few extra buttons to get to port 587, might as well get them to authenticate. Authenticating port 587 is not the silver bullet, but it buys you a little bit. Frank -----Original Message----- From: Keith Medcalf [mailto:kmedcalf@dessus.com] Sent: Wednesday, September 03, 2008 7:34 PM To: nanog@nanog.org Subject: ingress SMTP
On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote:
On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote:
You're forgetting that 587 *is authenticated, always*.
I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place.
Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST.
Oops.
Does anyone bother to run an MSA on 587 and *not* require authentication?
Raises hand. Why would the requirements for authentication be different depending on the port used to connect to the MTA? No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy: - local delivery originating from a non-blacklisted or "internal/customer" address does not require authentication; - relay from "internal/customer" IP Addresses does not require authentication; - any connection from a blacklisted IP requires authentication or no mail will be accepted; - relay from "external/non-customer" IP Addresses requires authentication; Is there a valid reason why a different configuration is justified? As an aside, outbound port 25 traffic is also blocked except from the MTA.
On Wed, 3 Sep 2008, Keith Medcalf wrote:
Why would the requirements for authentication be different depending on the port used to connect to the MTA?
It's easier to configure the MTA if you make a distinction between server-to-server traffic and client-to-server traffic. In fact my systems distinguish three classes of traffic: MX, message submission, and smarthost. The MX service has lots of anti-spam features. You want to separate it from the others so that techniques like teergrubing don't make message submission painfully slow. You can also avoid interoperability problems with server-to-server TLS. You can limit the number of connections used by the MX service to that when it is being hammered by spammers, you can reserve some capacity so that message submission and outgoing relay still work. Having a message submission service that always requires TLS and authentication makes it easier for users to check their configuration. A mistake such as not turning on AUTH can be hidden when they test on their home network, only to be discovered later when they are roaming far from tech support. Separating your smarthost (outgoing relay service) from your MX can avoid some strange problems. Back in the dim and distant past before remote AUTHed message submission and before separate MX and smarthost, our roaming users who failed to change their smarthost setting would have working email when contacting colleagues but not anyone else, with a mysterious "relaying is not permitted" error instead of something clear and helpful. There's also some advantage to making it harder for spammers to work out the name of your smarthost: we once (years ago) had a problem with an open web proxy that spammers used as the first half of a two-stage open relay, the second half of which was the MX of the proxy's parent domain. We separate these functions by having separate names and IP addresses for each one. They are all just facets of the same MTA, so we don't have to maintainn lots of different configurations. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ LUNDY FASTNET IRISH SEA: WESTERLY OR SOUTHWESTERLY 4 OR 5, BECOMING CYCLONIC OR NORTHEASTERLY 5 TO 7, PERHAPS GALE 8 LATER. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
participants (8)
-
Frank Bulk -
Jeff Kinz -
Keith Medcalf -
Mark Foster -
Mikael Abrahamsson -
Robert E. Seastrom -
Simon Waters -
Tony Finch