--On 24 March 2011 14:50:22 +0000 "Dave Restall - System Administrator,,,"
<[email protected]> wrote:
Hi,
I use exim to receive and process my emails - have done for years.
I also use sender callouts - have done for years. Occasionally emails
get rejected because they are sent from non-existent addresses and sender
callouts don't like that.
I'm with you on this. With the proviso that you should check SPF first.
Callouts are entirely legitimate if you get an SPF pass, but arguably
redundant. They're not required if you get an SPF fail. For softfail and
neutral, I'd avoid doing the callout on the basis that one should be nice
to people that are helping you to evaluate the legitimacy of mail from
sender addresses in their domains.
In my view, refusing bounce messages for an address that's used in the
"RETURN PATH" is contrary to RFC 5321 "The primary purpose of the
Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. "
You can parse this as reading "exactly one return path (an address to
which messages indicating non-delivery or other mail system failures
are to be sent) SHOULD be present when the message is delivered. "
And "SHOULD" means that you should be aware of the consequences of failing
to do so. For rfc5322, ignoring a recommendation means that you risk
failing to deliver email. If plusnet want to deliver their email, then they
should follow all recommendations in RFC5322.
Oh, and you don't need callouts in order to reject their email.
Recently plusnet (www.plus.net) (an ISP !!!) sent me some administrative
emails that were rejected due to sender callouts, so - I raised a support
call and asked them to fix their systems and change the envelope addresses
to something sensible - I don't care what they change it to as long as
it resolves to a valid address. After much toing and froing, I got the
following back, basically they're telling me to whitelist their broken
addresses because 'the system is currently working as it was designed'.
I realise I'm not strictly sticking to the RFC's 'be liberal in what
you accept' in this case but why should I whitelist for their brain dead
configs ?
Before I go and really bend their ear on why they shouldn't be sending
emails with invalid addresses, and that I shouldn't really have to
whitelist their addresses because how can I know what the next failing
address will be if their systems are designed to be broken and that for
an ISP to have broken systems is really unacceptable, is there anybody
on the list that works for plusnet who can point me at the right email
address for their mail admins so I can make an appeal to the right people
instead of... ? I'm resisting adjectives here because I've worked for
a lot of years in a support environment and I don't want to label the
whole plusnet team.
ISTR in one of the earlier RFC's that there was a 'should not send from a
non-existent email address' and also a 'be conservative in what you send'
but I can't find them in recent RFC's, have things changed so much that
they can configure servers this way and ignore the problems ? (I don't
assiduously read RFC's nowadays). What are the current RFC's regarding
good mail server etiquette ?
I must admit plusnet have normally been good in responding to queries
and support calls - but I'm amazed at their attitude over this and it
makes me wonder what other corners they are cutting in order to provide
their service.
We are pleased to be able to inform you that a member of our Customer
Support Centre has now escalated your Question [number 40296690 ]
for further investigation.
The following comment was added to the Question
The Question 40296690 has been released from hold in the CSC - G pool
and returned to the customer
Dear Mr Restall,
This has now been reviewed, and the system is currently working as it
was designed.
To resolve this issue, you are able to whitelist the addresses that you
have given to us previously or disable the callback verification.
Please note that Callback verification has no effect if spammers spoof
real email addresses or use the null bounce address.
Please take a look at the link below for further information on the
limitations:
http://en.wikipedia.org/wiki/Callback_verification
Kind regards,
Kevin Mawson
Read or respond to your Question -
http://portal.plus.net/my.html?action=questions
IMPORTANT: Do not reply to this email, our Support Team can only deal
with inquiries through the Help Assistant
Regards,
Customer Support
--
http://portal.plus.net
PlusNet plc
Registered Office: Internet House, 2 Tenter Street, Sheffield, S1 4BY
Registered in England no: 3279013
VAT registration number: 842254440
Sorry about the looong rant :(
Regards,
D
lists/exi,/users/2011-03-24.tx exim-users
+------------------------------------------------------------------------
----+
| Dave Restall, Computer Nerd, Cyclist, Radio Amateur G4FCU, Bodger
| | Mob +44 (0) 7973 831245 Skype: dave.restall Radio:
| G4FCU | email : [email protected] Web : Not Ready
| Yet :-( |
+------------------------------------------------------------------------
----+
| The more complex the mind, the greater the need for the simplicity
| | of play.
| | -- Kirk, "Shore Leave", stardate 3025.8 |
+------------------------------------------------------------------------
----+
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
