mainSavannah Administration - Support: sr #103380, [gnu.org #210909] Savannah MTA...

 
 

sr #103380: [gnu.org #210909] Savannah MTA seems to request VRFY info before accepting mail

Submitter:  Jesus M. Gonzalez-Barahona <jgb>
Submitted:  Mon 20 Sep 2004 10:21:38 PM UTC
   
 
Category:  Savannah mail server Priority:  5 - Normal
Severity:  6 - Security Status:  Wont Do
Privacy:  Public Assigned to:  corvus
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 04 Oct 2004 08:57:50 PM UTC, comment #8: 

ok. I don't see how checking VRFY helps this days to fight spam, but anyway, I also don't understand why some sites refuse to comply to VRFY queries. In any case, it is your policy, and I respect your right to maintain it. Thanks for your time and support.

Jesus M. Gonzalez-Barahona <jgb>
Mon 04 Oct 2004 08:19:51 PM UTC, comment #7: 

Reply from Jim:

The GNU.org mail servers perform verification of smtp senders before accepting mail.  This cuts down on a huge amount of spam, and also ensures that if we can't deliver the message we can at least send a DSN back to the original sender.  If you set your SMTP sender correctly your mail will get through.

Which confirms Elfyn's point.

I close this request. Sorry :/

Sylvain Beucler <Beuc>
Sat 02 Oct 2004 04:42:26 PM UTC, comment #6: 

Find below a copy of the message that got the user. Apparently, it says that 199.232.76.166 (mail.gnu.org) didn't accept the message because of a "Sender VRFY failed".

tibet.uoc.es is the MTA of the sender's organization.

============================================================================

Hi. This is the qmail-send program at tibet.uoc.es.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
199.232.76.166 does not like recipient.
Remote host said: 550 Sender verify failed
Giving up on 199.232.76.166.

--- Below this line is a copy of the message.

Return-Path:
Received: (qmail 7989 invoked by uid 10031); 6 Sep 2004 13:38:18 -0000
Received: from -email is unavailable- by tibet by uid 64011 with qmail-scanner-1.21

 (clamscan: 0.65. spamassassin: 2.60.  Clear:RC:1(213.73.40.40):.
 Processed in 0.16465 secs); 06 Sep 2004 13:38:18 -0000
X-Uoc-Spam: No
Return-Path:
Received: from unknown (HELO campus.uoc.es) (213.73.40.40)
  by tibet.uoc.es with SMTP; 6 Sep 2004 13:38:17 -0000
Received: from bermudas (bermudas [213.73.40.40])
        by campus.uoc.es (8.11.6+Sun/8.11.6) with ESMTP id i86DcGl27721;
        Mon, 6 Sep 2004 15:38:17 +0200 (MEST)
From: David Megias Jimenez
X-Uoc-From: "David Megías Jiménez <dmegias@uoc.edu>"
To: "pelegrin@labri.fr",
   "masterlibre-list@nongnu.org"
Fcc: /Missatges/Enviats
Subject: RE: Bordeaux is on its way [Re: [Masterlibre-list] University of
Bologna:        M-FOSSET]
X-Uoc-Subject: "RE: Bordeaux is on its way [Re: [Masterlibre-list]
University of Bologna:  M-FOSSET]"
Date: Mon, 06 Sep 2004 15:37:57 +0200
X-Uoc-UserType: PROFESSOR
X-Uoc-Att: 0
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="--------------UOCGENERATED031070"
Message-ID: <6859076.1094477896744.JavaMail.root@bermudas>
Comments: localhost [127.0.0.1]
X-UOC-PARENT_MAILID: 70591638
X-Uoc-Hops: 1

----------------UOCGENERATED031070
content-type: text/plain
Content-Transfer-Encoding: quoted-printable

Jesus M. Gonzalez-Barahona <jgb>
Fri 01 Oct 2004 09:52:07 PM UTC, comment #5: 

Apologizes for the delay..

James Blair replied:
"I can't find that address anywhere in the logs.  Also, we don't use VRFY.

Could you ask for a copy of a DSN message?"

jgb, can you provide this information?

Sylvain Beucler <Beuc>
Sun 26 Sep 2004 10:51:57 AM UTC, comment #4: 

Indeed, but if we open a hole for one user, we open them for all - no exceptions.  Also, there are two reasons why we wouldn't normally do such things: a) addresses can be forged, like everything else, and b) because they open the door to even more spam for thousands of people.

The latter is very important considering how many thousands of people the machines serve.

If you really want me to see if this is feasible, I will - but don't get your hopes up ;-)

Elfyn McBratney <beu>
Wed 22 Sep 2004 03:56:27 PM UTC, comment #3: 

I know it is RFC compliant, but as far as I know it is not mandatory (excuse me if I'm wrong). In any case, we have a collaborator who cannot contribute, and is not able of changing the policy of  his site. I know the reasons for them  not accepting VRFY are at the very least arguable, but it is not likely they are going to change that (I know he has already tried that way). Maybe we can be a bit flexible here,  I don't know...

Jesus M. Gonzalez-Barahona <jgb>
Wed 22 Sep 2004 02:28:39 PM UTC, comment #2: 

quick comment from the sidelines: this is RFC-compliant behaviour.  It's the MTA/MUA that's broken, if they don't respond to VRFY/VERP's properly.  Not supporting VRFY (for whatever reasons) should be avoided, IMO, and not white-listed.

Elfyn McBratney <beu>
Tue 21 Sep 2004 09:05:48 PM UTC, comment #1: 

I forwarded the request to the system administrators, who are in charge of the mail system (we don't have access there).

Sylvain Beucler <Beuc>
Mon 20 Sep 2004 10:21:38 PM UTC, original submission:  

We are having a user of our mailing lists who is trying to send mail to it, but the Savannah mail server seems to reject accepting it, apparently because it is asking for VRFY info to the user's MTA. The user's MTA dod not support VRFY for security reasons. We wonder whether this VRFY check can be avoided. This is blocking for us because the messages by that user are important for the project. The user is dmegias@uoc.edu.

Jesus M. Gonzalez-Barahona <jgb>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 7 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-10-04 Beuc StatusNone Wont Do
    Open/ClosedOpen Closed
2004-10-01 Beuc Assigned toBeuc corvus
    SummarySavannah MTA seems to request VRFY info before accepting mail [gnu.org #210909] Savannah MTA seems to request VRFY info before accepting mail
    Carbon-Copy- Added sysadmin --AT-- gnu --DOT-- org
2004-09-21 Beuc Assigned toNone Beuc
2004-09-20 jgb Carbon-Copy- Added dmegias --AT-- uoc --DOT-- edu

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code