There are several models for where the MTA lives in an ISP environment - MTA at customer, connects to destination via Port 25. - MUA at customer, MTA at ISP, connects to destination via Port 25. - MTA at customer, ISP transparently forces connection through ISP MTA, then connects to destination via 25 - MUA at customer, ISP, MTA at email service provider, connects to destination via port 25. The MUA-vs-MTA distinction and the MTA-at-ISP model are _historical_artifacts_, left over from the days of dial ISPs. - An MTA benefits from having a reliable full-time connection to the Internet, because it's going to deliver mail to a potentially unreliable destination and may need to keep trying repeatedly over a long time, while the MUA only needs to connect to the MTA long enough to pass the message. - It's also helpful for the MTA to be colocated with the sender's mailbox service, and the mailbox service and its domain names also benefit from fulltime connectivity. - While dial internet is almost dead, smartphones and wireless laptops are partially recreating the unreliably-connected computer system, but they usually use MTAs at an email service provider, not the ISP. - On the other hand, any desktop computer or laptop, most smartphones, and many wristwatches have far more computing horsepower and disk space than the VAX 11/780s that ran early sendmail systems, so they're perfectly capable of being first-class objects on the Internet and running MTAs. I've got a strong preference for ISPs to run a Block-25-by-default/Enable-when-asked. As a purist, I'd prefer to have Internet connections that are actually Internet connections, and if you want to run email on a Linux box at home or have an Arduino in your refrigerator email the grocery when you're out of milk, you should be able to, and if some meddling kid at an ISP wants to block it, they should get off your lawn. In practice, of course, somewhere between 99.9% and 99.999% of all home MTAs aren't Linux boxes or Macs, they're zombie spambots on home PCs, or occasional driveby wifi spammers or other pests, and not only should outgoing mail be blocked, but the user should be notified and the connection should probably be put into some kind of quarantined access. But that's for Port 25 - the Port 25 blocking by ISPs has largely pushed Email Service Providers to use other protocols such as 587 for mail submission from an MUA to the MTA, or webmail instead, and it's really bad practice for ISPs to interfere with that. In some cases they'll still be sending spam, but that's the MTA's job to filter out, and if they don't, they'll end up on a bunch of RBLs. (And generally they'll be trying to keep their mail clean themselves - if the MTA providers were spammers, they wouldn't need to go to the trouble of having actual residential users as customers when they could mass-produce it cheaper directly.)

For clarity it's really bad for ISPs to block ports other than 25 for the purposes of mail flow control... correct? Yes, correct. If you're using another mail submission port, you're connecting to a mail service that has the responsibility not to let spam escape, and your ISP has done its job of stopping point-source

On Mon, Oct 31, 2011 at 6:23 AM, Brian Johnson <bjohnson@drtel.com> wrote: pollution.

Bill>I've got a strong preference for ISPs to run a Bill>Block-25-by-default/Enable-when-asked.  [...]

This is, of course, exactly why this blocking is done.

My take on this is that it IS best practice to have users use the submission port (587) for mail submission from the MUA to an MTA. If you're running an MTA service, then yes. If you're running a

It looks like you're missing half my point, which is the Enable-when-asked part. There are users who are perfectly legitimately running MTAs at home, whether for reliability or privacy (e.g. so they can run SMTP-over-TLS end-to-end) or just simplicity, and ISPs shouldn't be blocking them (unless they're spammers, of course.) transport service, then not necessarily. -- ----              Thanks;     Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.