* Re: Minuteman's Production server. your provider's email server sends a message back to the Production server.
[not found] <5iejldqogb.fsf@fencepost.gnu.org>
@ 2007-05-19 7:53 ` Tim X
0 siblings, 0 replies; only message in thread
From: Tim X @ 2007-05-19 7:53 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2007-05-19 7:53 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <5iejldqogb.fsf@fencepost.gnu.org>
2007-05-19 7:53 ` Minuteman's Production server. your provider's email server sends a message back to the Production server Tim X
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.