Re: Minuteman's Production server. your provider's email server sends a message back to the Production server.

[Tim X]

Don Saklad <dsaklad@fencepost.gnu.org> writes:

> Our management team at Minuteman Library Network failed to remedy
> difficulty with the network, would any of you kind folks out
> there have any hints, tips or pointers?...
>
>
>
> _ _ _ _ _  Cambridge Public Library http://cambridgema.gov/cpl  _ _ _ _ _
>>      The problem is when the Production server sends an email notice
>> to your provider, your provider's email server sends a message back
>> to the Production server to verify that it is a legitimate email
>> server.
>> 
>> Because this is Minuteman's Production server and is not really an
>> email server, they block those types of queries at the firewall.
>
>
>
> _ _ _ _ _  Example. Notice. Minuteman Library Network 
> http://www.mln.lib.ma.us  _ _ _ _ _
>> Mail-from: From camtel@library.minlib.net  Sat May 19 00:20:37 2007
>> camtel at library.minlib.net
>> Return-Path: <camtel@library.minlib.net>
>> camtel at library.minlib.net
>> 
>> Received: from library.minlib.net (library.minlib.net [64.69.127.2])
>> 
>> Received: (from camtel@localhost)
>> (from camtel at localhost)
>>         by library.minlib.net (8.9.3p3-20030923/8.9.1) id AAA03306
>> 
>> Message-Id: <200705190423.AAA03306@library.minlib.net>
>> <200705190423.AAA03306 at library.minlib.net>
>> 
>> Subject: Library Notice
>> Reply-To: camreturns@minlib.net
>> camreturns at minlib.net
>> 
>>     CAMBRIDGE PUBLIC LIBRARY NOW OPEN AT THE LONGFELLOW SCHOOL
>>     359 BROADWAY
>>     CAMBRIDGE MA 02139-4125                            Sat May 19 2007
>>     617-349-4040 http://www.cambridgema.gov/CPL/hours/libhours.html
>> 
>>      Requested Item(s) Ready for Pickup
>>      The item that you requested is now being held for you at the library.
>>      Bring this library card to pick up the item by the Pickup Date below.
>>      Some libraries may charge for unclaimed requested items.
>> 
>>      AUTHOR:
>>      TITLE:   The legend of 1900
>>      CALL NO: DVD LEGEND OF 190
>>      BARCODE: 34868004907812
>>      LOCATION: WATERTOWN/Audiovisual
>>      PICKUP AT: Cambridge M BY: 05-29-07
>> 
>>       3:1
>
>
>
> _ _ _ _ _   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Their test email said:
>> 
>> >  Mail-from: From camtel@library.minlib.net  Tue May  1 12:33:32 2007
>> 
>> ... which I'm assuming is going to be their envelope sender.
>> 
>> Let's get their authoritative nameservers:
>> 
>> host -t ns library.minlib.net
>> library.minlib.net name server ns3.ctccom.net.
>> library.minlib.net name server ns4.ctccom.net.
>> 
>> Alright -- now let's ask each of them who the MX is for the domain
>> library.minlib.net:
>> 
>> host -t mx library.minlib.net ns4.ctccom.net
>> Using domain server:
>> Name: ns4.ctccom.net
>> Address: 64.69.100.35#53
>> Aliases:
>> 
>> library.minlib.net mail is handled by 10 mail.library.minlib.net.
>> host -t mx library.minlib.net ns3.ctccom.net
>> Using domain server:
>> Name: ns3.ctccom.net
>> Address: 64.69.100.67#53
>> Aliases:
>> 
>> library.minlib.net mail is handled by 10 mail.library.minlib.net.
>> 
>> Great. Now what's mail.library.minlib.net?
>> 
>> host mail.library.minlib.net ns3.ctccom.net
>> Using domain server:
>> Name: ns3.ctccom.net
>> Address: 64.69.100.67#53
>> Aliases:
>> 
>> mail.library.minlib.net has address 64.69.127.2
>> 
>> Let's contact it...
>> 
>> telnet 64.69.127.2 25
>> Trying 64.69.127.2...
>> telnet: Unable to connect to remote host: Connection refused
>> 
>> That's why sender verification fails.
>
>
>
> _ _ _ _ _  webmaster@minlib.net webmaster at minlib.net  _ _ _ _ _
>> We've double checked and it appears that your email address is correctly 
>> entered in our system with no errors, spaces or other characters.  We've 
>> checked our mail logs and they indicate that mail is being successfully sent 
>> to your email address.  However, the logs also indicate that your mail 
>> server appears to be trying to validate our server by looking for a server 
>> named "mail.minlib.net".  This is not the name of our server, email is sent 
>> from the catalog from a server named "minlib.net".  So, your mail server 
>> will not be able to verify us if it keeps using that name.
>> 
>> We recommend that you contact the administrator of your mail server to look 
>> into why your server would be blocking emails from minlib.net.  If it 
>> possible for you to put minlib.net on your "whitelist" this may possibly 
>> solve this issue.
>> 
>> Alternately, you may want to use another email address as your main email 
>> contact for emails coming from MLN.  You can change your email address by 
>> going to: https://library.minlib.net/patroninfo/ and entering your barcode 
>> and PIN.  Once logged in, choose "Modify Personal Information" and update 
>> your Email address.
>> 
>> Additionally, just to make you aware of how the system handles email 
>> notices.  When your items comes to your library to be picked up the system 
>> queues an email notice to send to you (but it doesn't yet send it).  The 
>> email notice will be sent overnight.  However, if you pick up your item 
>> during that day, the system will remove your email notice from the queue.  
>> So, sometimes it may seem as if you should have been notified about items, 
>> but since you picked them up the system no longer notifies you about that 
>> item.
>> Webmaster
>> Minuteman Library Network
>> http://www.mln.lib.ma.us/

This is rather off topic for an emacs group. 

The problem here is a brain dead provider trying to reduce spam by verifying
with the originating system. Unfortunately, this is a poorly thought out
solution by the provider because -

1. At times, the sending mail server may not be available due to network
problems between the sender and recieving host

2. A host does not need to run a mail server if it only intends to send mail. A
server is only required to recieve mail or relay mail on behalf of others

3. Some sites use different mail servers for sending and recieving mail for
performance/security reasons. They will often block incomming connections from
outside networks to the sending host.

4. Some people will send mail through a server with a reply_to address that all
responses are supposed to go to. for example, I might decide to use my ISPs
mail server to send mail, but want all replies to go to my gmail account. In
this case, checking to see if the server I sent my mail from is irrelevant - it
would be better to check where I've asked responses to be sent. Of course,
spammers also use this trick to send mail via mail 'bounces' (i.e. you send
spam to a user that doesn't exist on a remote system, but have a return address
set to who you really want the mail to go to. the remote system bounces the
mail back to your intended 'victim'. I find this one particularly stupid - its
certainly not going to convince me to by viagra!

In short, it seems your provider is being too restrictive. while this approach
probably does prevent a lot of spam, it probably results in clients not
receiving legitimate mail as well. The solution is to either follow the
suggestion of putting a different return address or getting a new provider. 

Tim

-- 
tcross (at) rapttech dot com dot au