Problem sending email - A valid sender header is required in message

w1z4rd

w1z4rd

Karmic Sangoma
Joined
Jan 17, 2005
Messages
52,146
Reaction score
8,340
Location
127.0.0.1
This is the error message I am getting:

<[email protected]>: host smtp.isdsl.net[196.26.208.190] said: 550 A valid
sender header is required in message ([email protected]) (in reply to end
of DATA command)
Click to expand...

Im confused at why this error message is happening.

Basically I have a postfix mail server on site. The smarthost for the mail server is set to smtp.isdsl.net (as they use IS bandwidth).

All other users on the same network as this user can use my email server or smtp.isdsl.net fine. This user gets the same error message if he uses my server (which uses IS as a smarthost), if I try deliver the mail directly to smtp.isdsl.net.

Im not sure on what could be causing this... any ideas?

Email address has being changed...
 
Can you post of send me the whole NDR and I should be able to tell you a bit more. a 550 isa generic NDR so we would need more to troubleshoot properly
 
Try telnetting in and seeing if you get the error?
 
The problem is a corrupt user account on slapd. Problem resolved.
 
Same Error

Sry to bump this old thread. I have the same error and i am using Exchange sending to smart host.

Here is the message.


Delivery has failed to these recipients or groups:

Person ([email protected])
A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.

The following organization rejected your message: smtp04.isdsl.net.

Diagnostic information for administrators:

Generating server: MyServer.local

[email protected]
smtp04.isdsl.net #550-A valid sender header is required in message 550 ([email protected]) ##


Original message headers:

Received: from MyDomain.local ([ipv6Address]) by
MyDomain([ipv6Address]) with mapi; Thu, 18
Feb 2010 09:18:56 +0200
From: [email protected]
To: [email protected]
Subject: Subject
Thread-Topic:Subject
Thread-Index: AcqwaqiNBV51bRLaR8+oHc7GbyhRqw==
Date: Thu, 18 Feb 2010 07:19:07 +0000
Message-ID: <[email protected]>
Accept-Language: en-ZA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/related;
boundary="_004_6E8F5EDFB542A443AE708D95DE0A92FAC059MyDomain_";
type="multipart/alternative"
MIME-Version: 1.0


Any form of help will be great.
Thx
Kaboose
 
Does this user have a different email address /domain to all the rest of the users your exchange box is relaying for?
 
Has this been resolved yet? My system was working fine uptill today. Now I get this error. Google didnt help me much. Anyone no whats the problem?
 
You may want to google for a anti-spam feature IS uses (or did) on their relays called "Callout".

The IS relay actually first connects to your domains MX server to check if it is relaying for a valid address.

Of course if senders server has any greywalling or other anti-spam features of it's own - it could fail -and then IS refuses to accept the message for relay.

http://en.wikipedia.org/wiki/Callback_verification
 
Last edited:
A test using the IS relay server from [email protected] (which user does not exist) was sent to [email protected] - Logs below:
Note: Port 25 was hi-jacked so don't worry about smtp.saix.net

Yellow-mini.co.za gets a surprise connection from IS pretending to want to deliver a message to Amanda:

13:47:44.625: Connection from 196.26.208.200, Thu Nov 26 13:59:47 2009<lf>
13:47:44.640: << 220 Yellow-mini.co.za ESMTP server ready.<cr><lf>
13:47:44.687: >> HELO smtp02.isdsl.net<cr><lf>
13:47:44.687: << 250 Yellow-mini.co.za Hello, smtp02.isdsl.net.<cr><lf>
13:47:44.734: >> MAIL FROM:<><cr><lf>
13:47:44.484: << 250 Sender OK - send RCPTs.<cr><lf>
13:47:44.515: >> RCPT TO:<[email protected]><cr><lf>
13:47:44.640: << 550 Address '<[email protected]>' not known here.<cr><lf>
13:47:44.734: >> QUIT<cr><lf>
13:47:44.734: << 221 Yellow-mini.co.za Service closing channel.<cr><lf>
13:47:44.750: --- Connection closed normally at Thu Nov 26 13:59:49 2009. ---



And the message is rejected on the sending side:

Thu 2009-11-26 13:47:42: Parsing message <c:\mdaemon\queues\remote\pd50000000003.msg>
Thu 2009-11-26 13:47:42: * From: [email protected]
Thu 2009-11-26 13:47:42: * To: [email protected]
Thu 2009-11-26 13:47:42: * Subject: test
Thu 2009-11-26 13:47:42: * Size (bytes): 8755
Thu 2009-11-26 13:47:42: * Message-ID: <[email protected]>
Thu 2009-11-26 13:47:42: Attempting SMTP connection to [smtp.saix.net]
Thu 2009-11-26 13:47:42: Resolving MX records for [smtp.saix.net] (DNS Server: 172.16.0.1)...
Thu 2009-11-26 13:47:42: * Name server has no valid records of the requested type for that domain
Thu 2009-11-26 13:47:42: Attempting to send message to smart host
Thu 2009-11-26 13:47:42: Attempting SMTP connection to [smtp.saix.net:25]
Thu 2009-11-26 13:47:42: Resolving A record for [smtp.saix.net] (DNS Server: 172.16.0.1)...
Thu 2009-11-26 13:47:42: * D=smtp.saix.net TTL=(0) A=[196.43.0.142]
Thu 2009-11-26 13:47:42: Attempting SMTP connection to [196.43.0.142:25]
Thu 2009-11-26 13:47:42: Waiting for socket connection...
Thu 2009-11-26 13:47:42: * Connection established (192.168.5.32:1375 -> 196.43.0.142:25)
Thu 2009-11-26 13:47:42: Waiting for protocol to start...
Thu 2009-11-26 13:47:42: <-- 220 smtp02.isdsl.net ESMTP Exim 4.69 Thu, 26 Nov 2009 13:51:50 +0200
Thu 2009-11-26 13:47:42: --> EHLO testserver.co.za
Thu 2009-11-26 13:47:42: <-- 250-smtp02.isdsl.net Hello 196-210-179-26-wblv-esr-4.dynamic.isadsl.co.za [196.210.179.26]
Thu 2009-11-26 13:47:42: <-- 250-SIZE 104857600
Thu 2009-11-26 13:47:42: <-- 250-8BITMIME
Thu 2009-11-26 13:47:42: <-- 250-EXPN
Thu 2009-11-26 13:47:42: <-- 250 HELP
Thu 2009-11-26 13:47:42: --> MAIL From:<[email protected]> SIZE=8755
Thu 2009-11-26 13:47:42: <-- 250 OK
Thu 2009-11-26 13:47:42: --> RCPT To:<[email protected]>
Thu 2009-11-26 13:47:43: <-- 250 Accepted
Thu 2009-11-26 13:47:43: --> DATA
Thu 2009-11-26 13:47:43: <-- 354 Enter message, ending with "." on a line by itself
Thu 2009-11-26 13:47:43: Sending <c:\mdaemon\queues\remote\pd50000000003.msg> to [196.43.0.142]
Thu 2009-11-26 13:47:44: Transfer Complete
Thu 2009-11-26 13:51:44: <-- 550 A valid sender header is required in message ([email protected])
Thu 2009-11-26 13:51:44: --> QUIT
Thu 2009-11-26 13:51:44: <-- 221 smtp02.isdsl.net closing connection
Thu 2009-11-26 13:51:44: SMTP session terminated (Bytes in/out: 412/8885)
Thu 2009-11-26 13:51:44: ----------

When tested with legitimate address ([email protected]), the message goes through without a hitch but there is still the connection from IS server, although it quits before the DATA line as it's really just faking wanting to send any message.

T 20091126 140723 4b0dfe3a Connection from 196.26.208.200
T 20091126 140723 4b0dfe3a HELO smtp02.isdsl.net
T 20091126 140723 4b0dfe3a MAIL FROM:<>
T 20091126 140724 4b0dfe3a RCPT TO:<[email protected]>
T 20091126 140724 4b0dfe3a QUIT
T 20091126 140724 4b0dfe3a Connection closed with 196.26.208.200, 1 sec. elapsed.

Hope that explains / helps you a bit.
 
Last edited:
The email address does exists, but my mail server probably doesnt respond correctly when IS smtp does its thing. So maybe i have a config error somewhere
 
Some google response:
"A straightforward way to do that is a callout, doing a partial mail transaction to see if the putative sender's mail server accepts mail to that address. This approach was popular for a few years, but due to its combination of ineffectiveness and abusiveness, it's now used only by small mail systems whose managers don't know any better. What's wrong with it? The most obvious problem is that it doesn't work to verify addresses. There's lots of reasons why the naively implemented checks that callouts use can succeed for a non-existent address or fail for a good address. Many mail systems (including mine) accept all addresses at the RCPT TO, and reject the bad ones at the DATA command, giving the callout system the mistaken impression that bad addresses are good. Conversely, systems that implement techniques against spam blowback (bounces from spam forging their addresses) can often reject callouts because they look just like blowback, giving the callout system the mistaken impression that good addresses are bad."


What a mouth full
 
kaboose said:
Sry to bump this old thread.
Click to expand...

Holy crap Batman, 16-09-2008?
1114981414_fullres.jpg
 
Well if your mail is not hosted elsewhere by an isp & your MX records point strait back to the machine you sending from, it should be pretty easy.

Send a message and monitor your incoming connections for IS wanting to send a message to that user to see where the buggerup is happening.

Exchange is pretty cr@p at viewing that real time, if it is exchange, but you have the logs.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X