Re: MTA on non-standard port
On Oct 26, 2008, at 7:23 PM, Jeremy Chadwick wrote: 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. If you want to do direct to MX mailing, you are going to need to negotiate that separately. At the very least you will need a static IP address. If you pay for that, then you will probably be allowed to do direct to MX mailing. On the whole, I think that Access Service Providers are right in this policy. Back in the old days of smaller ASPs, there were several that had a simple policy. You could be allowed destination:25 traffic merely by asking for it. They figured that anyone smart enough to ask for it knew what they were doing. But it was blocked by default. But keep in mind that if you don't have a static IP address, the mail hosts you try to reach are also very likely to block you. 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). Wise choice. I wish more home and business networks did that. 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). Again. I think that this is fit and proper. 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. Then pay money to a company whose business depends on doing mail right. I use fastmail.fm which I highly recommend. I hope the experience with your ISP is better than mine. Good luck. A business account (needed for a static IP address) is expensive. But don't expect to mail directly to MX (without going through some mailhub, either comcast's or a service that you pay separately for) without one. Cheers, -j ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MTA on non-standard port
On Sun, 26 Oct 2008 17:23:59 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: 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
Re: MTA on non-standard port
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). So, I'm sure to have a frustrating couple hours with their tech support sometime Real Soon Now. Meantime, Mutt on the server via SSH is OK, I guess, for me, but no one else likes it ;-) Thanks again, Kevin Kinsey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MTA on non-standard port
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
MTA on non-standard port
Hello, For various reasons, I find myself in need of an MTA accepting submission on a port other than 587 (or 25). It'd be Real Nice(tm) if sendmail could Just Do It, but I'd be willing to look at other options as well, as long as I can get a good spam solution to play nice with the server (currently I'm running dual-sendmail with Amavisd-new and spamassassin). Anyone doing such a thing, or have a few hints handy? TIA, Kevin Kinsey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MTA on non-standard port
On Fri, Oct 24, 2008 at 10:50:39AM -0500, Kevin Kinsey wrote: Hello, For various reasons, I find myself in need of an MTA accepting submission on a port other than 587 (or 25). It'd be Real Nice(tm) if sendmail could Just Do It, but I'd be willing to look at other options as well, as long as I can get a good spam solution to play nice with the server (currently I'm running dual-sendmail with Amavisd-new and spamassassin). Anyone doing such a thing, or have a few hints handy? It can do it. See the DAEMON_OPTIONS macro in your /etc/mail/hostname.mc file. (Remember: DO NOT edit sendmail.cf directly). Here's a hint: http://www.sendmail.org/~gshapiro/8.10.Training/DaemonPortOptions.html -- | Jeremy Chadwickjdc 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 | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MTA on non-standard port
On Fri 2008-10-24 10:50:39 UTC-0500, Kevin Kinsey ([EMAIL PROTECTED]) wrote: For various reasons, I find myself in need of an MTA accepting submission on a port other than 587 (or 25). From what I can tell Postfix can be configured to listen on any unused port (or multiple thereof) by editing /usr/local/etc/postfix/master.cf as per the FAQ, then running /usr/local/etc/rc.d/postfix reload. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MTA on non-standard port
Jeremy Chadwick wrote: On Fri, Oct 24, 2008 at 10:50:39AM -0500, Kevin Kinsey wrote: Hello, For various reasons, I find myself in need of an MTA accepting submission on a port other than 587 (or 25). It'd be Real Nice(tm) if sendmail could Just Do It, but I'd be willing to look at other options as well, as long as I can get a good spam solution to play nice with the server (currently I'm running dual-sendmail with Amavisd-new and spamassassin). Anyone doing such a thing, or have a few hints handy? It can do it. See the DAEMON_OPTIONS macro in your /etc/mail/hostname.mc file. (Remember: DO NOT edit sendmail.cf directly). Here's a hint: http://www.sendmail.org/~gshapiro/8.10.Training/DaemonPortOptions.html And here is a snip from a box I run sendmail on port 24.. It is from the [hostname].mc file: dnl Enable for both IPv4 and IPv6 (optional) DAEMON_OPTIONS(`Name=IPv4, Family=inet') dnl DAEMON_OPTIONS(`Name=IPv6, Family=inet6, Modifiers=O') DAEMON_OPTIONS(`Port=24, Name=MTA, M=EC') ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
