On Sun, Oct 26, 2008 at 06:55:53PM -0500, Kevin Kinsey wrote: > Hello, > > Quick thanks to Andrew Clark, Jeremy Chadwick, Tim Kellers, > Jeff Goldberg, and anyone whose reply I've not seen re: > this issue. > > Isn't hard, as several pointed out. Now I've sendmail listening > on any port I want to. Problem is, still can't touch it from > here (and you might have guessed, the base issue is a new provider > of a lower-class service who I'm guessing only allows certain > ports by default).
Most consumer ISPs in the United States block two kinds of traffic to their customers' IP blocks: 1) Incoming SMTP (e.g. someIP:* --> yourIP:25) 2) Outbound SMTP (e.g. yourIP:* --> someIP:25) #2 has become prominent in the past few years, and is applied by ISPs because they want to curb their customers sending spam out onto the Internet (usually as a result of viruses, trojans, etc.), getting their IPs blocked by DNSBLs and giving them a bad social rep. Instead, they force customers to relay outbound mail through their own SMTP servers (called a "smart host" in sendmail terms). There's absolutely no way around this; you can beg them all you want, but the chances of them adding a pass-through for you is very slim. Story time again... My setup, just to give you some idea: my home LAN has a FreeBSD box used for all kinds of purposes. The box itself does not have direct Internet access (it sits behind a Linksys WRTSL54GS NAT router, which DOES NOT have incoming port 25/587 forwarded). The BSD box listens on localhost:25,587, and bsdIP:25,587. This allows other machines on the LAN to send mail through the BSD box, and of course local utilities on the BSD box to do the same. The Linksys router has two outbound firewall rules applied to it: it only allows bsdIP on my LAN to connect to someIP:25,587 -- thus, only one machine on my LAN is allowed to speak SMTP to the world. I do this purely as a precautionary measure (in case one of my friends comes over with his/her laptop, which happens to be infected and sends spam, etc. -- it won't work, period). All this worked great until Comcast put in place outbound SMTP filters, which stopped postfix from being able to connect to someIP:25 (where someIP is some random MX/mail server on the Internet). I was forced to set up "smart relaying", causing postfix to siphon all outbound mail through comcastmailserver:25, which worked fine for a few years. A couple months ago, Comcast stirred up the ants. They blocked my ability to send mail to anyIP:25 (including to their own SMTP servers!), citing "an incident of spam from my IP address". I asked them provide timestamps, Reference IDs, or even queue IDs, and also explained my LAN setup and how what they were claiming happened simply could not happen without my knowledge of it. They refused, as in in literally "We will not provide you any of that". Abuse and I got into a very long discussion on the phone about this, and told me a lot of conflicting things (more or less just inducing me to ask more questions, because their story didn't make any sense). They did eventually tell me what *day* the spam was sent, which allowed me to go look through my logs -- over and over, and I found absolutely no sign of any illegitimate mail in my mail logs. I was told they would lift the block (which was done at the cable modem level, not at the router level) if I could "permanently guarantee no more incidents of spam". I told them that was impossible to guarantee, because there *was no incident of spam* from my IP in the first place, and they were refusing to work with me to figure out how/why they were claiming that. So we sat there on the phone, silent, basically saying nothing -- a total standstill. Eventually they stated that I could send mail through their mail servers on port 587. I quickly set this up, and found it failed -- their servers require SMTP AUTH on port 587, no exceptions (note: this is NOT mandatory by the RFC; it's OPTIONAL). This meant I had to go through the pains of dealing with Cyrus SASL2 (thankfully postfix makes this easier to deal with than sendmail), and upon configuring it all, mail once again began to flow. That's how things remain now. The reason I do not like siphoning mail through Comcast: their mail servers are known to act wonky or /dev/null mail for mysterious reasons. I've had two separate incidents of me sending mail to individuals, witnessing Comcast's servers say "OK/accepted", but the mail never reached the destination. In one case, one recipient ran his own mail server, and was able to confirm that he saw absolutely no Comcast IP connect to his server during a 24 hour period. To this day the mail has never arrived. All the anti-spam advocates praise ISPs stepping in and becoming the "middle man" for spam siphoning/filtering, spanking users like this when incidents occur -- but when their setup fails or does what I've described above, they basically turn their cheek and ignore any sort of mistake or mishap. The fact that I cannot convince my ISP that I am a responsible Netizen is disheartening -- I should not need a business class connection to justify my responsibility. I hope the experience with your ISP is better than mine. Good luck. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"